From owner-saag Tue Jan 4 08:46:33 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09450 Tue, 4 Jan 2000 08:45:56 -0500 (EST) Message-Id: <199912310144.MAA17794@stranger.vic.cmis.CSIRO.AU> To: jis@mit.edu, mleech@nortelnetworks.com cc: secdir@mit.edu, saag@lists.tislabs.com, Bob.Smart@cmis.CSIRO.AU Subject: building a security model for the Internet Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 Dec 1999 12:44:12 +1100 From: Bob Smart Sender: owner-saag@lists.tislabs.com Precedence: bulk The Propagate project (www.propagate.net) addressed the problem of Intellectual Property rights by first building a model of the relevant aspects of the real world. This seemed a valuable exercise that could be used to help us think about the security issues of the Internet. As a first step I've had a go at a Basic Internet Security Model in http://www.ted.cmis.csiro.au/~smart/draft-smart-sec-model-00.txt (html and xml versions are also there). I welcome comments on that document. The abstact appears below. It doesn't go as far as building an Object Model and that may not be a necessary step. Whatever the merits of that particular document I suggest that something like it will be helpful step. If others are interested we could have a BOF in Adelaide. Bob Smart CSIRO Division of Mathematical and Information Sciences ----------------------------------------------------------------------- Abstract The first step in creating a secure Internet is to build a model of the security requirements of the real world entities involved and how those real world entities act on the Internet through the agency of networked computers. This document presents a minimal model as a starting point for discussion. In this model: o The real world is composed of entities, each being: (a) an independent legal entity; or (b) a sub-entity of another entity (creating a multi-level hierarchy). o Running code is characterized by: (a) the entity that it acts on behalf of; and (b) the entity that controls the environment in which the code executes. o The environment can run on a bare unmanaged machine or it can be a virtual environment which is code controlled by another entity. Environments thus form another multi-level hierarchy. o We can model communication between machines as a sequence of requests and assertions. The security question becomes: which requests to honour. What is known about the provenance of the requests and assertions is typically crucial. o Security can take place at different network layers and security information must be passed between the layers along with the data. From owner-saag Mon Jan 24 19:19:25 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA21335 Mon, 24 Jan 2000 19:18:49 -0500 (EST) Message-Id: <4.2.1.20000124161055.00c5f2d0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 24 Jan 2000 16:24:25 -0800 To: saag@lists.tislabs.com From: Paul Hoffman / IMC Subject: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt In-Reply-To: <4.2.0.58.19990825090659.00bc3160@mail.imc.org> References: <19990824022532.E14A141F16@SIGABA.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-saag@lists.tislabs.com Precedence: bulk Jeff's draft on the AES ciphers is still alive, even if this thread died many months ago. I'd like to toss in a few comments to get the discussion going again. A few people from NIST said that NIST is considering coming out with two (not one) AES cipher. If they do this, protocol writers must then decide between mandating implementation of: - Just AES 1 - Just AES 2 - Just TripleDES - AES 1 and AES 2 - AES 1 and TripleDES - AES 2 and TripleDES - All three In protocols where there is no online negotiation such as S/MIME and OpenPGP, this is a mess. I think we should also be thinking about why we would want to mandate two ciphers. The argument that was heard in Oslo (and is apparently the argument that NIST is using in its thinking) is that we need a quickly-usable fallback algorithm if one is broken. This is good in theory but we need to do more work than we have to date to make it usable. Imagine the future where Alg1 and Alg2 are required, and Alg1 is the preferred algorithm. Alg1 turns out to be breakable. At that moment, everyone should be able to turn off Alg1 and turn on Alg2. In order to keep communications flowing, every initiator/sender who switches to Alg2 must be able to assume that the responder/recipient has implemented Alg2. This is quite different than today's protocols where there is one mandatory algorithm and a bunch of optional ones. With the new export laws in the US, it is reasonable to assume that most software will have TripleDES natively by the time that the AES is finished later this year. But that still doesn't solve our problem. Do we pick one of the two AES candidates plus TripleDES? Do we mandate all three algorithms? Which do we pick as the preferred algorithm for initiators/senders to start with? It would be good if we had an action plan in place before the customers start asking. --Paul Hoffman, Director --Internet Mail Consortium From owner-saag Tue Jan 25 11:16:16 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24618 Tue, 25 Jan 2000 11:16:04 -0500 (EST) Date: Tue, 25 Jan 2000 11:20:38 -0500 (EST) From: der Mouse Message-Id: <200001251620.LAA19973@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: saag@lists.tislabs.com Subject: Re: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt Sender: owner-saag@lists.tislabs.com Precedence: bulk > A few people from NIST said that NIST is considering coming out with > two (not one) AES cipher. If they do this, protocol writers must > then decide between mandating implementation of: [the seven > possibilities] > I think we should also be thinking about why we would want to mandate > two ciphers. The argument that was heard in Oslo (and is apparently > the argument that NIST is using in its thinking) is that we need a > quickly-usable fallback algorithm if one is broken. > Do we pick one of the two AES candidates plus TripleDES? Do we > mandate all three algorithms? Which do we pick as the preferred > algorithm for initiators/senders to start with? It seems to me that the answers to these questions depend, at least in part, on the protocol in question. In particular, which algorithm is preferred will - or at least should - depend on protocol-specific tradeoffs. (And note also that whether a break of an algorithm renders it useless depends on the protocol and the break - though it certainly would not be unreasonable to shy away from an algorithm that's been broken at all even if the publicly known breaks don't affect the particular use contemplated.) der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-saag Tue Jan 25 11:28:40 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24670 Tue, 25 Jan 2000 11:28:38 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Paul Hoffman / IMC Cc: saag@lists.tislabs.com Subject: Re: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Jan 2000 11:33:25 -0500 Message-Id: <20000125163330.6E9D441F16@SIGABA.research.att.com> Sender: owner-saag@lists.tislabs.com Precedence: bulk In message <4.2.1.20000124161055.00c5f2d0@mail.imc.org>, Paul Hoffman / IMC wri tes: > Jeff's draft on the AES ciphers is still alive, even if this thread died > many months ago. I'd like to toss in a few comments to get the discussion > going again. > > A few people from NIST said that NIST is considering coming out with two > (not one) AES cipher. If they do this, protocol writers must then decide > between mandating implementation of: I don't think there's much point in abstract speculation here. At the very least, we should wait until April, when the next AES conference is held. We'll know a lot more then about which candidates still look strong, and (perhaps) about what NIST is thinking. --Steve Bellovin From owner-saag Tue Jan 25 12:04:09 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24785 Tue, 25 Jan 2000 12:04:08 -0500 (EST) Message-Id: <3.0.6.32.20000125090734.03ad3100@216.240.42.209> X-Sender: rodney@216.240.42.209 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 25 Jan 2000 09:07:34 -0800 To: rodney@tillerman.to From: Rodney Thayer Subject: Re: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt Cc: saag@lists.tislabs.com, rodney@sj.counterpane.com In-Reply-To: <20000125163330.6E9D441F16@SIGABA.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-saag@lists.tislabs.com Precedence: bulk I disagree. The form of the logic is valid, today. What ciphers we use to 'fill in the blanks' is, essentially, irrelevant. We all KNOW that the AES proces isn't going to choose 3DES, so we KNOW we're going to have another algorithm. And all the arguments about needing more than one algorithm are valid even without the AES process. And besides, this seems to be a hard problem, so putting it off doesn't make it any better. If some high school kid from Europe wrote a 2 line Perl script that broke 3DES, we'd have this problem, even if AES didn't exist. We'd simply be having the same conversation, but about different algorithms. This is not about AES. This is about whether or not our security architecture needs multiple algorithms, in general. At 11:33 AM 1/25/00 -0500, Steven M. Bellovin wrote: >In message <4.2.1.20000124161055.00c5f2d0@mail.imc.org>, Paul Hoffman / IMC wri >tes: >> Jeff's draft on the AES ciphers is still alive, even if this thread died >> many months ago. I'd like to toss in a few comments to get the discussion >> going again. >> >> A few people from NIST said that NIST is considering coming out with two >> (not one) AES cipher. If they do this, protocol writers must then decide >> between mandating implementation of: > >I don't think there's much point in abstract speculation here. At the very >least, we should wait until April, when the next AES conference is held. >We'll know a lot more then about which candidates still look strong, and >(perhaps) about what NIST is thinking. > > --Steve Bellovin > > From owner-saag Tue Jan 25 12:38:34 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24932 Tue, 25 Jan 2000 12:38:31 -0500 (EST) Message-Id: <4.2.1.20000125093847.00a5def0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Tue, 25 Jan 2000 09:44:23 -0800 To: saag@lists.tislabs.com From: Paul Hoffman / IMC Subject: Re: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt In-Reply-To: <3.0.6.32.20000125090734.03ad3100@216.240.42.209> References: <20000125163330.6E9D441F16@SIGABA.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-saag@lists.tislabs.com Precedence: bulk At 09:07 AM 1/25/00 -0800, Rodney Thayer wrote: >This is not about AES. This is about whether or not our security >architecture needs multiple algorithms, in general. It's also about what we say in the protocols about multiple algorithms. If we mandate implementing both TripleDES and SomeStrongAlg, should there also be a mandate of "unless told otherwise, emit TripleDES"? Again, protocols like S/MIME and OpenPGP don't get to negotiate like IPsec and TLS do. Or, should we as the security directorate not worry about this and let each WG guess on its own? Maybe that's best, but I don't really think so. --Paul Hoffman, Director --Internet Mail Consortium From owner-saag Wed Jan 26 09:19:10 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28956 Wed, 26 Jan 2000 09:18:52 -0500 (EST) Message-ID: From: "Hughes, James P. (SNBG)" To: saag@lists.tislabs.com Subject: RE: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt Date: Tue, 25 Jan 2000 18:19:43 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-saag@lists.tislabs.com Precedence: bulk Let me put this into a long term context, even longer than S/MIME and OpenPGP. If you assume that your communications must be protected for a long time, then you must assume your adversary is storing your ciphertext. Stated differently, negotiating a new algorithm is irrelevant to past data. If I have 30 years of data under 3DES and 3DES is broken, all is lost regardless of the other options available. As the standards mature, I believe we must suggest the most conservative default at that time. Let other algorithms be optional. Specifying a minimal set of algorithms is OK, but one has to be the default. If the SAAG asks the experts, then the SAAG should make the recommendation to the WGs for the default algorithm. If you do not ask the experts, then I believe a recommendation should not be attempted. The downside will be that the algorithm du jour will prevail. Frankly, I am saddened that NIST process does not seem to be coming to a valuable conclusion. I am worried that if they choose 2 algorithms for AES, then 3DES may become the default, and I believe that a 25+ year old algorithm is not a good choice. We will have the same issues for public key and key management algorithms. http://www.ntru.com http://www.arithmetica.com . Maybe there should be a standing working group on algorithms that can entice objective experts to contribute. The other working groups can liaision with this instead of doing this in the SAAG or doing it ad hoc in the working groups? Jim -----Original Message----- From: Paul Hoffman / IMC [mailto:phoffman@imc.org] Sent: Tuesday, January 25, 2000 11:44 AM To: saag@lists.tislabs.com Subject: Re: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt At 09:07 AM 1/25/00 -0800, Rodney Thayer wrote: >This is not about AES. This is about whether or not our security >architecture needs multiple algorithms, in general. It's also about what we say in the protocols about multiple algorithms. If we mandate implementing both TripleDES and SomeStrongAlg, should there also be a mandate of "unless told otherwise, emit TripleDES"? Again, protocols like S/MIME and OpenPGP don't get to negotiate like IPsec and TLS do. Or, should we as the security directorate not worry about this and let each WG guess on its own? Maybe that's best, but I don't really think so. --Paul Hoffman, Director --Internet Mail Consortium From owner-saag Wed Jan 26 17:53:04 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00878 Wed, 26 Jan 2000 17:52:57 -0500 (EST) Message-Id: <4.2.1.20000126143927.00c37240@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 26 Jan 2000 14:56:46 -0800 To: saag@lists.tislabs.com From: Paul Hoffman / IMC Subject: Re: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt In-Reply-To: References: <4.2.1.20000125093847.00a5def0@mail.imc.org> <20000125163330.6E9D441F16@SIGABA.research.att.com> <4.2.1.20000125093847.00a5def0@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-saag@lists.tislabs.com Precedence: bulk At 12:03 PM 1/26/00 -0500, Stephen Kent wrote: >If we mandate multiple algorithms, then a sender in OPGP or S/MIME is free >to choose any one, as the receiver MUST implement all of them. Quite right. > Since it is the sender's data that is at risk, this is not an > unreasonable way to allow the choice to be made. I disagree that it is only the sender's data that is at risk. The risk could easily be equal for both parties. In protocols with negotiation, even if there are multiple required algorithms, one side can say "nope, not good enough" to a required algorithm. In non-negotiated protocols like S/MIME and OpenPGP, if the receiver believes that one of the mandated algorithms is broken, there is no way to say "I won't take messages with the broken algorithm". I'm not saying that this is worse than where we are now. Both S/MIME and OpenPGP have one mandatory encryption cipher; if it is broken, the recipient is worse off than if there were two. At least S/MIME has the capabilities attribute so that someone can say "here's what I accept" and if only a subset of the mandatory algorithms is on that list, the sender should assume there is a good reason. OpenPGP doesn't have this, however. Further, the S/MIME capabilities is only useful for senders who bother to look them up before sending, which is a SHOULD and not a MUST. --Paul Hoffman, Director --Internet Mail Consortium From owner-saag Wed Jan 26 20:17:22 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01248 Wed, 26 Jan 2000 20:17:16 -0500 (EST) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <4.2.1.20000125093847.00a5def0@mail.imc.org> References: <20000125163330.6E9D441F16@SIGABA.research.att.com> <4.2.1.20000125093847.00a5def0@mail.imc.org> Date: Wed, 26 Jan 2000 16:12:01 -0800 To: Paul Hoffman / IMC , saag@lists.tislabs.com From: Jon Callas Subject: Re: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt Content-Type: text/plain; charset="us-ascii" Sender: owner-saag@lists.tislabs.com Precedence: bulk At 9:44 AM -0800 1/25/00, Paul Hoffman / IMC wrote: >At 09:07 AM 1/25/00 -0800, Rodney Thayer wrote: >>This is not about AES. This is about whether or not our security >>architecture needs multiple algorithms, in general. > >It's also about what we say in the protocols about multiple algorithms. If >we mandate implementing both TripleDES and SomeStrongAlg, should there also >be a mandate of "unless told otherwise, emit TripleDES"? Again, protocols >like S/MIME and OpenPGP don't get to negotiate like IPsec and TLS do. > There is, however, a negotiation protocol in OpenPGP, and I agree with Rodney that this is merely a discussion about multiple algorithms. I'd like to clear up this misunderstanding about OpenPGP. In OpenPGP, there is an algorithm preference list in the receiver's certificate (a.k.a. key). In this self-signed list is an identifier for each algorithm the receiver will accept. The sender of a message MUST pick an algorithm from this list. See RFC 2440 for details and hints, but that's pretty much all there is to it. This isn't substantially different from either TLS or IPsec. In all these protocols, each side has a set of allowable algorithms, and they pick one out of the intersection of these. None of them allows a partner to say, "wait a minute, I lied last time when I said I only spoke algorithm X, I suppose I can speak algorithm Y, if that's all you have." I thought that S/MIME's mechanism required a message to be sent -- the algorithms aren't written into a certificate. That's certainly a handicap for S/MIME, but as far as OpenPGP is concerned, we can handle this fine -- as easily and robustly as a real-time protocol. We don't need any special features. We already have multiple algorithm support. But thanks for thinking of us. Jon From owner-saag Wed Jan 26 21:51:42 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01468 Wed, 26 Jan 2000 21:51:31 -0500 (EST) Message-Id: <4.2.1.20000126182132.00b30600@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 26 Jan 2000 18:57:02 -0800 To: saag@lists.tislabs.com From: Paul Hoffman / IMC Subject: Re: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt In-Reply-To: References: <4.2.1.20000125093847.00a5def0@mail.imc.org> <20000125163330.6E9D441F16@SIGABA.research.att.com> <4.2.1.20000125093847.00a5def0@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-saag@lists.tislabs.com Precedence: bulk At 04:12 PM 1/26/00 -0800, Jon Callas wrote: >In OpenPGP, there is an algorithm preference list in the receiver's >certificate (a.k.a. key). Whoops, you're right. I thought it was there, but couldn't find it when looking before. >This isn't substantially different from either TLS or IPsec. I'll disagree there. Again, assume that a OpenPGP recipient has created a signature that says "you can use either Alg1 or Alg2". Later, Alg1 is broken, so he doesn't want anyone to send it. Any sender might still see the preference for either. In TLS or IPsec, you not only remove Alg1 from the algorithms offered in the negotiation, you also refuse to accept it as an offer from the other party. In other words, you don't negotiate in OpenPGP or S/MIME: you state preferences that a sender later uses. >I thought that S/MIME's mechanism required a message to be sent -- the >algorithms aren't written into a certificate. There is a document in WG last call that lets you put the preferences it in a cert. --Paul Hoffman, Director --Internet Mail Consortium From owner-saag Thu Jan 27 09:06:13 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03333 Thu, 27 Jan 2000 09:06:11 -0500 (EST) Message-ID: From: "Balenson, David" To: Paul Hoffman / IMC Cc: saag@lists.tislabs.com Subject: RE: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt Date: Thu, 27 Jan 2000 04:07:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-saag@lists.tislabs.com Precedence: bulk > Imagine the future where Alg1 and Alg2 are required, and Alg1 is the > preferred algorithm. Alg1 turns out to be breakable. At that moment, > everyone should be able to turn off Alg1 and turn on Alg2. In order to keep > communications flowing, every initiator/sender who switches to Alg2 must be > able to assume that the responder/recipient has implemented Alg2. This is > quite different than today's protocols where there is one mandatory > algorithm and a bunch of optional ones. If both are required, then everyone *will* be able to switch, and *will* be able to assume ... -DB From owner-saag Thu Jan 27 09:07:13 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03361 Thu, 27 Jan 2000 09:07:11 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <4.2.1.20000125093847.00a5def0@mail.imc.org> References: <20000125163330.6E9D441F16@SIGABA.research.att.com> <4.2.1.20000125093847.00a5def0@mail.imc.org> Date: Wed, 26 Jan 2000 12:03:56 -0500 To: Paul Hoffman / IMC From: Stephen Kent Subject: Re: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt Cc: saag@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-saag@lists.tislabs.com Precedence: bulk Paul, If we mandate multiple algorithms, then a sender in OPGP or S/MIME is free to choose any one, as the receiver MUST implement all of them. Since it is the sender's data that is at risk, this is not an unreasonable way to allow the choice to be made. Steve From owner-saag Thu Jan 27 09:07:13 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03362 Thu, 27 Jan 2000 09:07:12 -0500 (EST) Message-ID: From: "Balenson, David" To: Rodney Thayer Cc: saag@lists.tislabs.com, rodney@sj.counterpane.com Subject: RE: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt Date: Thu, 27 Jan 2000 04:07:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-saag@lists.tislabs.com Precedence: bulk Strongly agreed. This is an important general issue, on which the security directorate should provide general guidance (for implementation by WGs within their specific protocols) sooner, rather than later. -DB > -----Original Message----- > From: Rodney Thayer [mailto:rodney@tillerman.to] > Sent: Tuesday, January 25, 2000 12:08 PM > To: rodney@tillerman.to > Cc: saag@lists.tislabs.com; rodney@sj.counterpane.com > Subject: Re: Reviving the discussion of > draft-ietf-saag-aes-ciph-00.txt > > > I disagree. The form of the logic is valid, today. What > ciphers we use > to 'fill in the blanks' is, essentially, irrelevant. We all KNOW > that the AES proces isn't going to choose 3DES, so we KNOW we're going > to have another algorithm. And all the arguments about needing > more than one algorithm are valid even without the AES process. > > And besides, this seems to be a hard problem, so putting it off > doesn't make it any better. > > If some high school kid from Europe wrote a 2 line Perl script that > broke 3DES, we'd have this problem, even if AES didn't exist. We'd > simply be having the same conversation, but about different > algorithms. > > This is not about AES. This is about whether or not our security > architecture needs multiple algorithms, in general. > From owner-saag Thu Jan 27 09:08:12 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03386 Thu, 27 Jan 2000 09:08:11 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.2.1.20000126143927.00c37240@mail.imc.org> References: <4.2.1.20000125093847.00a5def0@mail.imc.org> <20000125163330.6E9D441F16@SIGABA.research.att.com> <4.2.1.20000125093847.00a5def0@mail.imc.org> <4.2.1.20000126143927.00c37240@mail.imc.org> Date: Wed, 26 Jan 2000 18:41:38 -0500 To: Paul Hoffman / IMC From: Stephen Kent Subject: Re: Reviving the discussion of draft-ietf-saag-aes-ciph-00.txt Cc: saag@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-saag@lists.tislabs.com Precedence: bulk Paul, As a recipient of a message, perhaps one addressed to multiple recipients, I really have limited say in selecting the algorithm use to encipher the message, since it must be the same for everyone if the originator is to send but one copy. So I don't think it is unreasonable to say that this it is soley the decision of the sender to choose among multiple, mandatory algorithms in such contexts. Steve From owner-saag Mon Feb 7 14:35:54 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00041 Mon, 7 Feb 2000 14:35:21 -0500 (EST) Message-Id: <4.2.1.20000207113906.00aba220@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 07 Feb 2000 11:40:56 -0800 To: saag@lists.tislabs.com From: Paul Hoffman / IMC Subject: Fwd: I-D ACTION:draft-orman-public-key-lengths-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-saag@lists.tislabs.com Precedence: bulk Hilarie Orman and I put together a draft with some calculations on the size of public keys you may want to use in key exchanges. The saag list may be a good place to discuss the draft and make comments so we can revise it. >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-orman-public-key-lengths-00.txt >Date: Mon, 07 Feb 2000 06:36:21 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Determining Strengths For Public Keys Used For > Exchanging Symmetric Keys > Author(s) : H. Orman, P. Hoffman > Filename : draft-orman-public-key-lengths-00.txt > Pages : > Date : 04-Feb-00 > >Implementors of systems that use public key cryptography to exchange >symmetric keys need to make the public keys resistant to some >predetermined level of attack. That level of attack resistance is the >strength of the system, and the symmetric keys that are exchanged must >be at least as strong as the system strength requirements. The three >quantities, system strength, symmetric key strength, and public key >strength, must be consistently matched for any network protocol usage. > >While it is fairly easy to express the system strength requirements in >terms of a symmetric key length and to choose a cipher that has a key >length equal to or exceeding that requirement, it is harder to choose a >public key that has a cryptographic strength meeting a symmetric key >strength requirement. This document explains how to determine the >length of an asymmetric key as a function of the length of a symmetric >key. Some rules of thumb for estimating equivalent resistance to >large-scale attacks on various algorithms are given. The document also >addresses how changing the sizes of the underlying large integers >(moduli, group sizes, exponents, and so on) changes the time to use the >algorithms for key exchange. > >The authors benefited greatly from discussions with Arjen Lenstra, >Eric Verheul, Andrew Odlyzko, and Richard Schroeppel in preparing >this material. Gratitude for their help does not in any way >implicate them in errors that might exist in this document. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-orman-public-key-lengths-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-orman-public-key-lengths-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-orman-public-key-lengths-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20000204120838.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-orman-public-key-lengths-00.txt > > From owner-saag Fri Jun 9 11:17:56 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12472 Fri, 9 Jun 2000 11:16:50 -0400 (EDT) Prev-Resent-Date: Thu, 8 Jun 2000 11:01:57 -0700 (PDT) Message-Id: <200006081801.LAA17838@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2829 on Authentication Methods for LDAP Cc: rfc-ed@isi.edu, ietf-ldapext@netscape.com Mime-Version: 1.0 Date: Thu, 08 Jun 2000 11:01:10 -0700 From: RFC Editor Prev-Resent-Message-ID: <"FwMRlC.A.wQ.u99P5"@glacier> Prev-Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Prev-Resent-Sender: ietf-ldapext-request@netscape.com Content-Type: Multipart/Mixed; Boundary=NextPart Sender: owner-saag@lists.tislabs.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2829 Title: Authentication Methods for LDAP Author(s): M. Wahl, H. Alvestrand, J. Hodges, R. Morgan Status: Standards Track Date: May 2000 Mailbox: Mark.Wahl@innosoft.com, Harald.Alvestrand@maxware.no, Jeff.Hodges@Stanford.edu, Bob.Morgan@Stanford.edu Pages: 16 Characters: 33471 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ldapext-authmeth-04.txt URL: ftp://ftp.isi.edu/in-notes/rfc2829.txt This document specifies particular combinations of security mechanisms which are required and recommended in LDAP [1] implementations. This document is a product of the LDAP Extension Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000608105902.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2829 --OtherAccess Content-Type: Message/External-body; name="rfc2829.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000608105902.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-saag Fri Jun 9 11:17:57 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12482 Fri, 9 Jun 2000 11:17:49 -0400 (EDT) Message-Id: <200006081807.LAA18853@boreas.isi.edu> To: rfc-dist@isi.edu Subject: RFC 2831 on Digest SASL Mechanism Cc: rfc-ed@isi.edu Mime-Version: 1.0 Date: Thu, 08 Jun 2000 11:07:36 -0700 From: RFC Editor Content-Type: Multipart/Mixed; Boundary=NextPart Sender: owner-saag@lists.tislabs.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2831 Title: Using Digest Authentication as a SASL Mechanism Author(s): P. Leach, C. Newman Status: Standards Track Date: May 2000 Mailbox: paulle@microsoft.com, chris.newman@innosoft.com Pages: 27 Characters: 58124 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-leach-digest-sasl-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2831.txt This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. This document is a product of the LDAP Extension Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000608110522.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2831 --OtherAccess Content-Type: Message/External-body; name="rfc2831.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000608110522.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-saag Fri Jun 9 11:40:53 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12693 Fri, 9 Jun 2000 11:40:52 -0400 (EDT) Message-Id: <200006081804.LAA18461@boreas.isi.edu> To: rfc-dist@isi.edu Subject: RFC 2830 on LDAPv3: Extension for Transport Layer Security Cc: rfc-ed@isi.edu Mime-Version: 1.0 Date: Thu, 08 Jun 2000 11:04:13 -0700 From: RFC Editor Content-Type: Multipart/Mixed; Boundary=NextPart Sender: owner-saag@lists.tislabs.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2830 Title: Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security Author(s): J. Hodges, R. Morgan, M. Wahl Status: Standards Track Date: May 2000 Mailbox: JHodges@oblix.com, rlmorgan@washington.edu, Mark.Wahl@innosoft.com Pages: 12 Characters: 24469 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ldapext-ldapv3-tls-06.txt URL: ftp://ftp.isi.edu/in-notes/rfc2830.txt This document defines the "Start Transport Layer Security (TLS) Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS establishment in an LDAP association and is defined in terms of an LDAP extended request. This document is a product of the LDAP Extension Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000608110154.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2830 --OtherAccess Content-Type: Message/External-body; name="rfc2830.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000608110154.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-saag Fri Jul 14 08:52:24 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04622 Fri, 14 Jul 2000 08:51:34 -0400 (EDT) From: timothy.wright@vf.vodafone.co.uk Message-Id: To: saag@lists.tislabs.com, jis@mit.edu, mleech@nortelnetworks.com Subject: Request for slot at SAAG plenary Date: Fri, 14 Jul 2000 10:14:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-saag@lists.tislabs.com Precedence: bulk Jeff, Marcus, SAAG, I would like a slot at the open SAAG meeting on Thursday afternoon to talk about some developments in the WAP forum's Security group (WSG) please. I am WSG chair but am of course just speaking as me at the IETF. The WAP forum has a major project for re-integration with IETF standards called WAP-Next Generation, or WAP-NG, or WAP version 2.0. And not before time, some would say. Their plan is for http-ng, TCP/IP (possibly with the use of PEP's to begin with, but long term, that TCP will contain wireless friendly options) and TLS to the handset, instead of the current WAP variants of these protocols. WSG's role is TLS to the handset and we want to do that in co-operation with (which means partly within) the IETF. We have a rough program for the work to be done: wireless profile of TLS 1.0; profile for certs; investigation into use of the WIM (wireless identity module, a PKCS15 based interface into a tamper-resistant device for storage of crypto parameters) for use in TLS to the handset; and a wireless-friendly version of TLS, 1.1. I'd like to present this program, and maybe talk a bit about wireless constraints, and take questions. As the WSG are having an ad hoc in Pittsburgh during the IETF (Thurs, Friday and Saturday), there will be other members of the WSG around to take questions too. Some of these people are regular IETF attendees already. Look forward to hearing from you, Tim Wright From owner-saag Wed Jul 26 19:50:38 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24763 Wed, 26 Jul 2000 19:50:10 -0400 (EDT) Message-ID: <397F7B6C.88249706@mit.edu> Date: Wed, 26 Jul 2000 19:59:40 -0400 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 4.61C- [en] (X11; U; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: timothy.wright@vf.vodafone.co.uk CC: saag@lists.tislabs.com, mleech@nortelnetworks.com Subject: Re: Request for slot at SAAG plenary References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-saag@lists.tislabs.com Precedence: bulk Sounds fine to me. Remind me when we get to Pittsburgh. -Jeff timothy.wright@vf.vodafone.co.uk wrote: > Jeff, Marcus, SAAG, I would like a slot at the open SAAG meeting on Thursday > afternoon to talk about some developments in the WAP forum's Security group > (WSG) please. I am WSG chair but am of course just speaking as me at the > IETF. > > The WAP forum has a major project for re-integration with IETF standards > called WAP-Next Generation, or WAP-NG, or WAP version 2.0. And not before > time, some would say. Their plan is for http-ng, TCP/IP (possibly with the > use of PEP's to begin with, but long term, that TCP will contain wireless > friendly options) and TLS to the handset, instead of the current WAP > variants of these protocols. > > WSG's role is TLS to the handset and we want to do that in co-operation with > (which means partly within) the IETF. We have a rough program for the work > to be done: wireless profile of TLS 1.0; profile for certs; investigation > into use of the WIM (wireless identity module, a PKCS15 based interface into > a tamper-resistant device for storage of crypto parameters) for use in TLS > to the handset; and a wireless-friendly version of TLS, 1.1. > > I'd like to present this program, and maybe talk a bit about wireless > constraints, and take questions. As the WSG are having an ad hoc in > Pittsburgh during the IETF (Thurs, Friday and Saturday), there will be other > members of the WSG around to take questions too. Some of these people are > regular IETF attendees already. > > Look forward to hearing from you, Tim Wright From owner-saag Wed Aug 30 14:52:32 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28065 Wed, 30 Aug 2000 14:51:33 -0400 (EDT) Message-ID: <002201c012a8$f953d380$e001a8c0@oficina.cert.fnmt.es> From: "=?iso-8859-1?B?TWlndWVsIMFuZ2VsIFBl8WEgUGnx824=?=" To: Subject: About the PEM Working Group Date: Wed, 30 Aug 2000 19:37:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-saag@lists.tislabs.com Precedence: bulk Dear Sirs, First of all please let me apologize for emailing to this address since I am not sure if this is the proper place where I have to write to make my question. My name is Miguel Ángel Peña from Madrid, Spain and I am both, a worker and a student. I am doing a study about the way of including non-repudiation services in electronic mail and, for the moment, I am looking for solutions for integrating public key utilities into email. I have known that the Open PGP and S/MIME WGs are doing their work about this, that is to say, to ways of implementing secure e-mail are to use PGP and to use S/MIME. But I also know that some time ago there was the PEM working group that also worked about this matter and published the PEM recommendations that are reflected in RFCs from 1421 to 1424. Using some Internet finders, I have arrived at the following link: http://www.ietf.org/proceedings/94jul/charters/pem-charter.html which is obsoleted information about the PEM WG. My question is, therefore, about the PEM WG: what has happend to it? I mean, I am working for a Spanish PKI so I know some implementations of secure e-mail and, as I have known, there is no any implementations that uses PEM. Nevertheless, in that link I have found that some drafts (which did not become a RFC, it seems) were issued talking about PEM and MIME, so I could understand that, although PEM was initially designed for text mails, it could also be used to protect any MIME Content-Type, so PEM could be a good secure e-mail solution as well. What has happened to PEM then?, Why is not used in implementations? Why did the Working Group dissapear? I would be very grateful if you could tell me something about this since I would like to include some reflexion in my study about PEM. Thank you very much for your time. Yours faithfully, Miguel Ángel Peña From owner-saag Thu Aug 31 07:31:27 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA00701 Thu, 31 Aug 2000 07:31:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <002201c012a8$f953d380$e001a8c0@oficina.cert.fnmt.es> References: <002201c012a8$f953d380$e001a8c0@oficina.cert.fnmt.es> Date: Wed, 30 Aug 2000 18:55:50 -0400 To: =?iso-8859-1?Q?=22Miguel_=C1ngel_Pe=F1a_Pi=F1=F3n=22?= From: Stephen Kent Subject: Re: About the PEM Working Group Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-saag@lists.tislabs.com Precedence: bulk Miguel, >My question is, therefore, about the PEM WG: what has happend to it? I mean, >I am working for a Spanish PKI so I know some implementations of secure >e-mail and, as I have known, there is no any implementations that uses PEM. >Nevertheless, in that link I have found that some drafts (which did not >become a RFC, it seems) were issued talking about PEM and MIME, so I could >understand that, although PEM was initially designed for text mails, it >could also be used to protect any MIME Content-Type, so PEM could be a good >secure e-mail solution as well. > >What has happened to PEM then?, Why is not used in implementations? Why did >the Working Group dissapear? PEM was the first Internet standard for secure e-mail. It has largely been supplanted by OPGP and S/MIME. PEM never dealt with MIME messages very cleanly, despite some efforts along those lines. The PEM WG ceased operation a few years ago, as we focused efforts on e-mail security technology that is consistent with MIME. Thus the WGs you cited above, for OPGP and S/MIME, have superceded the PEM WG. I was the chair of the PEM WG. Steve From owner-saag Thu Aug 31 09:00:15 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01020 Thu, 31 Aug 2000 09:00:10 -0400 (EDT) Message-ID: <39AE51FA.DAA6D51F@cisco.com> Date: Thu, 31 Aug 2000 18:09:22 +0530 From: Nicholas Basker X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: dbh@enterasys.com CC: snmpv3@lists.tislabs.com, rrohit@cisco.com Subject: Re: [Fwd: sysORTabel entries] References: <39AE4EE0.1AEB7164@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-saag@lists.tislabs.com Precedence: bulk Hello: I have done the following implementation. sysORID.3 = yyyAgentCapability.112 sysORID.4 = yyyAgentCapability.106 sysORDescr.3 = Agent capabilities for BGP4-MIB LAST-UPDATED 9408180000Z Bgp4CapabilityV10R02 AGENT-CAPABILITIES SUPPORTS BGP4-MIB File name: BGP4-CAPABILITY.my sysORDescr.4 = Agent capabilities for the BRIDGE-MIB LAST-UPDATED 9408180000Z BridgeCapabilityV10R02 AGENT-CAPABILITIES SUPPORTS BRIDGE-MIB File name: BRIDGE-CAPABILITY.my HTH, Nicholas. > Hi, > > A question has come up about sysORIDs and I'm interested in other > people's interpretations, and more importantly, their implementations. > > In the sysORTable, an entry contains a descriptive string and a unique > sysORID. > I have an A-C statement for my *whole* agent that is identified by > (using shorthand) xx.123. > The A-C statement contains details for if MIB, USM MIB, VACM MIB, SNMP > MIB, system MIB, etc. > > Is it legal to implement two columns of the sysORTable as > "if MIB" xx.123 > "USM MIB" xx.123 > "VACM MIB" xx.123 > "SNMP MIB" xx.123 > "system MIB" xx.123 > > Have others implemented this way? > Do those who are application vendors like or dislike this approach? or > not care? > > Thanks, > dbh > > -- > --- > David Harrington Network Management Standards Architect > dbh@enterasys.com Office of the CTO > +1 603 337 2614 - voice Enterasys Networks > +1 603 332 1524 - fax Rochester NH, USA From owner-saag Wed Sep 6 13:51:33 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13081 Wed, 6 Sep 2000 13:50:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Wed, 6 Sep 2000 11:01:17 -0700 To: saag@lists.tislabs.com From: Paul Hoffman / IMC Subject: RSA algorithm now in public domain Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-saag@lists.tislabs.com Precedence: bulk Unless RSA Security's web site has been hacked, the RSA license is already available now. See . I think they just wanted to prevent all the parties on September 20th from making fun of them. . . . RSA Security Releases RSA Encryption Algorithm into Public Domain "c = me mod n" Made Available Two Weeks Early BEDFORD, Mass., September 6, 2000 -- RSA® Security Inc. (NASDAQ: RSAS) today announced it has released the RSA public key encryption algorithm into the public domain, allowing anyone to create products that incorporate their own implementation of the algorithm. This means that RSA Security has waived its rights to enforce the patent for any development activities that include the RSA algorithm occurring after September 6, 2000. . . . --Paul Hoffman, Director --Internet Mail Consortium From owner-saag Fri Sep 8 14:57:51 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24232 Fri, 8 Sep 2000 14:56:26 -0400 (EDT) Message-Id: <4.2.2.20000908120342.03c181b0@mail.mbl.edu> X-Sender: crocker@mail.mbl.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 08 Sep 2000 12:16:59 -0400 To: Stephen Kent From: Steve Crocker Subject: Re: About the PEM Working Group Cc: In-Reply-To: References: <002201c012a8$f953d380$e001a8c0@oficina.cert.fnmt.es> <002201c012a8$f953d380$e001a8c0@oficina.cert.fnmt.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-saag@lists.tislabs.com Precedence: bulk Steve, With respect to your comment about PEM never dealing with MIME messages very cleanly, a handful of us spent considerable time working on this and developed the MOSS specification. The design was harder than one might have expected it to be because the combination of (1) the underlying mail protocol, (2) PEM and (3) MIME all imposed constraints which came from different traditions. I would characterize the result as "clean" in the sense that it was complete and consistent, but I would agree it wasn't elegant. Unfortunately there was little wiggle room. Steve At 06:55 PM 8/30/00 , Stephen Kent wrote: >Miguel, > > >My question is, therefore, about the PEM WG: what has happend to it? I mean, > >I am working for a Spanish PKI so I know some implementations of secure > >e-mail and, as I have known, there is no any implementations that uses PEM. > >Nevertheless, in that link I have found that some drafts (which did not > >become a RFC, it seems) were issued talking about PEM and MIME, so I could > >understand that, although PEM was initially designed for text mails, it > >could also be used to protect any MIME Content-Type, so PEM could be a good > >secure e-mail solution as well. > > > >What has happened to PEM then?, Why is not used in implementations? Why did > >the Working Group dissapear? > >PEM was the first Internet standard for secure e-mail. It has largely been >supplanted by OPGP and S/MIME. PEM never dealt with MIME messages very >cleanly, despite some efforts along those lines. The PEM WG ceased >operation a few years ago, as we focused efforts on e-mail security >technology that is consistent with MIME. Thus the WGs you cited above, >for OPGP and S/MIME, have superceded the PEM WG. > >I was the chair of the PEM WG. > >Steve > ---------------------------------- Steve Crocker Associates, LLC Bus: +1 301 654 4707 5110 Edgemoor Lane Fax: +1 202 478 0458 Bethesda, MD 20814 steve@stevecrocker.com From owner-saag Mon Sep 11 07:51:18 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA19379 Mon, 11 Sep 2000 07:49:45 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.2.2.20000908120342.03c181b0@mail.mbl.edu> References: <002201c012a8$f953d380$e001a8c0@oficina.cert.fnmt.es> <002201c012a8$f953d380$e001a8c0@oficina.cert.fnmt.es> <4.2.2.20000908120342.03c181b0@mail.mbl.edu> Date: Fri, 8 Sep 2000 15:33:07 -0400 To: Steve Crocker From: Stephen Kent Subject: Re: About the PEM Working Group Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-saag@lists.tislabs.com Precedence: bulk Steve, >Steve, > >With respect to your comment about PEM never dealing with MIME >messages very cleanly, a handful of us spent considerable time >working on this and developed the MOSS specification. The design >was harder than one might have expected it to be because the >combination of (1) the underlying mail protocol, (2) PEM and (3) >MIME all imposed constraints which came from different traditions. >I would characterize the result as "clean" in the sense that it was >complete and consistent, but I would agree it wasn't elegant. >Unfortunately there was little wiggle room. Yes, MOSS tried to address the problem of accommodating MIME in PEM. However, because of the constraints imposed by MIME, and because MOSS provided a pair of generic MIME encryption and signature mechanisms, rather than mechanisms focused more narrowly on the mail application per se, MOSS was not well received. One of the two MOSS base constructs lives on in S/MIME, as a means of providing signature services, but S/MIME uses it at a low level and provides a lot of mail-specific context for this construct. Steve From owner-saag Wed Oct 25 06:32:09 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA18473 Wed, 25 Oct 2000 06:31:30 -0400 (EDT) Message-Id: <200010251016.GAA23219@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, ietf-tls@lists.certicom.com, saag@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-krovetz-umac-01.txt Date: Wed, 25 Oct 2000 06:16:02 -0400 Sender: owner-saag@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : UMAC: Message Authentication Code using Universal Hashing Author(s) : T. Krovetz et al. Filename : draft-krovetz-umac-01.txt Pages : 39 Date : 24-Oct-00 This specification describes how to generate an authentication tag (also called a 'MAC') using the UMAC message authentication code. UMAC is designed to be very fast to compute, in software, on contemporary processors. Measured speeds are as low as 1.0 cycles per byte. The heart of UMAC is a universal hash function, UHASH, which relies on addition and multiplication of 16-bit, 32-bit, or 64-bit numbers, operations well-supported by contemporary machines. To generate the authentication tag on a given message, UHASH is applied to the message and key to produce a short, fixed-length, hash value, and this hash value is then XOR-ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis and its only 'cryptographic' use is a block cipher, AES, to generate the pseudorandom pads and internal key material. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krovetz-umac-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-krovetz-umac-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-krovetz-umac-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001024110923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-krovetz-umac-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-krovetz-umac-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001024110923.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-saag Wed Oct 25 14:30:15 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20291 Wed, 25 Oct 2000 14:30:03 -0400 (EDT) Message-Id: <200010251842.LAA00957@breakaway.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: fyi: FC: FBI agent reportedly gives public demo of Carnivore To: saag@lists.tislabs.com Reply-to: saag@lists.tislabs.com From: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Oct 2000 11:42:01 -0700 Sender: owner-saag@lists.tislabs.com Precedence: bulk ------- Forwarded Message Date: Tue, 24 Oct 2000 23:56:30 -0400 To: politech@politechbot.com From: Declan McCullagh Subject: FC: FBI agent reportedly gives public demo of Carnivore Cc: mthomas@fbi.gov Reply-To: declan@well.com X-URL: Politech is at http://www.politechbot.com/ [NANOG is the North American Network Operators Group; their most recent meeting was October 22 through October 24. --Declan] ******** Date: Tue, 24 Oct 2000 19:31:43 -0400 From: An Metet Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at . To: cypherpunks@einstein.ssz.com Subject: CDR: Public Demo of Carnivore and Friends FBI agent Marcus C. Thomas (who is mentioned in the EPIC FOIA documents) made a very interesting presentation at NANOG 20 yesterday morning, discussing Carnivore. Agent Thomas gave a demonstration of both Carnivore 1.34 (the currently deployed version) and Carnivore 2.0 (the development version) as well as some of the other DragonWare tools. Most of this information isn't new, but it demonstrates that the DragonWare tools can be used to massively analyze all network traffic accessible to a Carnivore box. The configuration screen of Carnivore shows that protocol information can be captured in 3 different modes: Full, Pen, and None. There are check boxes for TCP, UDP, and ICMP. Carnivore can be used to capture all data sent to or from a given IP address, or range of IP addresses. It can be used to search on information in the traffic, doing matching against text entered in the "Data Text Strings" box. This, the agent assured us, was so that web mail could be identified and captured, but other browsing could be excluded. It can be used to automatically capture telnet, pop3, and FTP logins with the click of a check box. It can monitor mail to and/or from specific email addresses. It can be configured to monitor based on IP address, RADIUS username, MAC address, or network adaptor. IPs can be manually added to a running Carnivore session for monitoring. Carnivore allows for monitoring of specific TCP or UDP ports and port ranges (with drop down boxes for the most common protocols). Carnivore 2.0 is much the same, but the configuration menu is cleaner, and it allows Boolean statements for exclusion filter creation. - -- The Packeteer program takes raw network traffic dumps, reconstructs the packets, and writes them to browsable files. CoolMiner is the post-processor session browser. The demo was version 1.2SP4. CoolMiner has the ability to replay a victim's steps while web browsing, chatting on ICQ, Yahoo Messenger, AIM, IRC. It can step through telnet sessions, AOL account usage, and Netmeeting. It can display information sent to a network printer. It can process netbios data. CoolMiner displays summary usage, broken down by origination and destination IP addresses, which can be selectively viewed. Carnivore usually runs on Windows NT Workstation, but could run on Windows 2000. Some choice quotes from Agent Thomas: "Non-relevant data is sealed from disclosure." "Carnivore has no active interaction with any devices on the network." "In most cases Carnivore is only used with a Title III. The FBI will deploy Carnivore without a warrant in cases where the victim is willing to allow a Carnivore box to monitor his communication." "We rely on the ISP's security [for the security of the Carnivore box]." "We aren't concerned about the ISP's security." When asked how Carnivore boxes were protected from attack, he said that the only way they were accessible was through dialup or ISDN. "We could take measures all the way up to encryption if we thought it was necessary." While it doesn't appear that Carnivore uses a dial-back system to prevent unauthorized access, Thomas mentioned that the FBI sometimes "uses a firmware device to prevent unauthorized calls." When asked to address the concerns that FBI agents could modify Carnivore data to plant evidence, Thomas reported that Carnivore logs FBI agents' access attempts. The FBI agent access logs for the Carnivore box become part of the court records. When asked the question "It's often common practice to write back doors into [software programs]. How do we know you aren't doing that?", Thomas replied "I agree 100%. You're absolutely right." When asked why the FBI would not release source, he said: "We don't sell guns, even though we have them." When asked: "What do you do in cases where the subject is using encryption?" Thomas replied, "This suite of devices can't handle that." I guess they hand it off to the NSA. He further stated that about 10% of the FBI's Carnivore cases are thwarted by the use of encryption, and that it is "more common to find encryption when we seize static data, such as on hard drives." 80% of Carnivore cases have involved national security. - -- Also of interest was a network diagram that looked very similar to the one in the EPIC FOIA document at http://www.epic.org/privacy/carnivore/omnivorecapabilities1.html , except that there was no redaction of captions. - -- Marcus Thomas can be contacted for questions at mthomas@fbi.gov or at (730) 632-6091. He is "usually at his desk." - ------------------------------------------------------------------------- POLITECH -- the moderated mailing list of politics and technology You may redistribute this message freely if it remains intact. To subscribe, visit http://www.politechbot.com/info/subscribe.html This message is archived at http://www.politechbot.com/ - ------------------------------------------------------------------------- ------- End of Forwarded Message From owner-saag Thu Oct 26 11:43:08 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23807 Thu, 26 Oct 2000 11:42:46 -0400 (EDT) Date: Thu, 26 Oct 2000 17:53:34 +0200 (IST) From: Hugo Krawczyk To: ipsec list , TLS list , saag@lists.tislabs.com Subject: Re: I-D ACTION:draft-krovetz-umac-01.txt In-Reply-To: <200010251016.GAA23219@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-saag@lists.tislabs.com Precedence: bulk As recently announced, the draft draft-krovetz-umac-01.txt is available from the Internet-Drafts directory. This document contains a full specification of the "UMAC" Message Authentication Code (i.e a function that provides data integrity verification for entities that share a key). This is the result of a three-year project involving several researchers. A paper describing the mathematical foundations of the algorithm was published more than a year ago in CRYPTO '99 [1]. UMAC was designed to provide strong authenticity guarantees while being flexible, provably secure, and **as fast as possible** on modern (and emerging) processors. Experiments show that UMAC achieves software speeds that are many times the speed of HMAC-SHA1. A quite unique feature of UMAC is that it lets you easily trade performance and security: from weak authentication against Denial of Service at GigaByte/second to the strongest authentication for the real paranoids at 100's of MegaBytes/second. For the most speed-demanding applications, as they emerge, I believe that UMAC provides a solution that is superior to current algorithms based on cryptographic hash functions (e.g. HMAC) or block ciphers (e.g. CBC-MAC). See the the UMAC homepage, http://www.cs.ucdavis.edu/~rogaway/umac, for additional information, including some performance details. Hugo PS: A word about UMAC's security. UMAC's security analysis is based on two factors: 1) The 20-year old methodology (due to Carter and Wegman) for building MAC functions on the basis of universal hashing. 2) The availability of a strong cipher (e.g. AES). The result of this analysis is that the only way that the proven security bounds for UMAC could fail is by breaking the underlying cipher (say Rijndael). As long as this cipher is unbroken so is UMAC. In this sense, UMAC does not need to be subject to cryptanalytical scrutiny before it can be used; you just need to believe that the underlying block cipher is secure. (See more information in [1] and in the draft's Security Considerations) [1] J. Black, S. Halevi, H. Krawczyk, T. Krovetz, and P. Rogaway. "UMAC: Fast and secure message authentication". Advances in Cryptology - CRYPTO '99. Lecture Notes in Computer Science, vol. 1666, Springer-Verlag, 1999, pp. 216-233. From owner-saag Fri Nov 10 16:21:18 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28280 Fri, 10 Nov 2000 16:20:47 -0500 (EST) From: aaron@panamsat.com Message-ID: <0703A3E1D430D411866100508BDFCF33191836@CTOEXCH1> To: saag@lists.tislabs.com Cc: spencer.dawkins@fnc.fujitsu.com, border@hns.com, jgriner@lerc.nasa.gov, gab@sun.com, kojo@cs.Helsinki.FI, zach.shelby@vtt.fi Subject: FW: PEP version 04 now available for WG Last Call Date: Fri, 10 Nov 2000 13:42:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-saag@lists.tislabs.com Precedence: bulk The PILC working group is in last call on a document describing mechanisms and issues surrounding Performance Enhancing Proxies. PEPs include devices that do things like splitting TCP connections, generating ACKs from the middle of a connection, adjusting ACK spacing and other layer violations. The intent of this document is to illustrate a) the mechanisms involved, b) why network operators feel the need to use these mechanisms, and c) the associated risks and pitfalls. Since a major criticism of PEPs is that they are incompatible with some Internet security mechisms, this work would be greatly enhanced via some review from the folks on this list. Please forward comments to the authors and/or the PILC list. Thanks, --aaron -----Original Message----- From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com] Sent: Monday, October 30, 2000 6:25 PM To: 'PILC Mailing List' Subject: PEP version 04 now available for WG Last Call Version 04 of the Performance Enhancing Proxies Internet-Draft is now available at http://www.ietf.org/internet-drafts/draft-ietf-pilc-pep-04.txt. The full document details are: Title : Performance Enhancing Proxies Author(s) : J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby Filename : draft-ietf-pilc-pep-04.txt Pages : 45 Date : 23-Oct-00 This draft is a PILC work item, and is slotted as an Informational RFC. It has not been through a previous working group last call. We would like to hold a two-week working group last-call on this document, ending on Tuesday, November 14. Please review this document as appropriate, and send questions or comments to the PILC mailing list. "Yes, it's done" is also an acceptable - in fact, welcome - comment. Spencer, for Spencer, Mark, and Aaron From owner-saag Fri Nov 17 16:09:39 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00744 Fri, 17 Nov 2000 16:09:18 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Fri, 17 Nov 2000 12:08:17 -0800 To: saag@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Fwd: 49th IETF-Security Tutorial Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-saag@lists.tislabs.com Precedence: bulk I would imagine that some of the folks here would be interested in this, and are possibly giving the tutorial... >To: IETF-Announce: ; >From: agenda@ietf.org >Subject: 49th IETF-Security Tutorial >Date: Fri, 17 Nov 2000 11:45:48 -0500 >Sender: mbeaulie@cnri.reston.va.us > >There will be a Security Tutorital given at the 49th IETF >meeting, anyone registered for the IETF meeting is invited >to attend. > >============================================================== > > The 1st IETF Security Tutorial: > How to Secure a Protocol > >Date: Sunday, 10 December 2000 >Time: 1:00pm - 3:00pm >Location: Sheraton San Diego Hotel & Marina, Grand Ballroom A > >Internet users expect the net to be secure. However without >secure protocols it is hard to develop secure systems. Yet what >does it mean to produce "secure" protocols? > >This session will discuss what the problem is, and the several >approaches that exist to deal with it. We will discuss existing >secure protocols in the RFC suite (TLS, IPSec) with an eye >toward the problems that they can solve. We will also discuss >when they are not appropriate and what one can do in such a >situation. > >The emphasis will be on practical solutions that can be deployed >in protocols today. From owner-saag Mon Nov 20 08:24:30 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09479 Mon, 20 Nov 2000 08:24:14 -0500 (EST) X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Fri, 17 Nov 2000 17:22:51 -0800 (PST) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: Paul Hoffman / VPNC cc: saag@lists.tislabs.com Subject: Re: Fwd: 49th IETF-Security Tutorial In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-saag@lists.tislabs.com Precedence: bulk > I would imagine that some of the folks here would be interested in > this, and are possibly giving the tutorial... It would indeed be interesting to know *who* will be doing the tutoring. (I also can't help but think that it's a short step from tutorials to vendor demonstrations and hospitality booths, but that's a different topic.) - RL "Bob" From owner-saag Mon Nov 20 11:53:45 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10142 Mon, 20 Nov 2000 11:53:37 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "RL 'Bob' Morgan" Cc: Paul Hoffman / VPNC , saag@lists.tislabs.com Subject: Re: Fwd: 49th IETF-Security Tutorial Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Nov 2000 11:54:41 -0500 Message-Id: <20001120165442.883CA35DC2@smb.research.att.com> Sender: owner-saag@lists.tislabs.com Precedence: bulk In message , "RL 'Bob' Morgan" writes: > >(I also can't help but think that it's a short step from tutorials to >vendor demonstrations and hospitality booths, but that's a different >topic.) Strong disagreement. Here's the problem: we've learned that security is necessary, and anyone in the security area will tell you that it has to be designed in from the start, not added on. But there are too few security folks to attach to every WG; besides, in an organization like the IETF, how do you "assign" someone to a WG? The idea of this tutorial is to provide a sufficient introduction that folks who aren't security geeks can start to understand the problems, the solution classes, and how to recognize when the waters are getting too deep. --Steve Bellovin From owner-saag Tue Nov 21 09:08:48 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16342 Tue, 21 Nov 2000 09:08:07 -0500 (EST) From: "Perry E. Metzger" To: "Steven M. Bellovin" Cc: "RL 'Bob' Morgan" , Paul Hoffman / VPNC , saag@lists.tislabs.com Subject: Re: Fwd: 49th IETF-Security Tutorial References: <20001120165442.883CA35DC2@smb.research.att.com> Date: 20 Nov 2000 15:02:44 -0500 In-Reply-To: "Steven M. Bellovin"'s message of "Mon, 20 Nov 2000 11:54:41 -0500" Message-ID: <87n1euxvh7.fsf@snark.piermont.com> Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.6 Sender: owner-saag@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" writes: > The idea of this tutorial is to provide a sufficient introduction that > folks who aren't security geeks can start to understand the problems, > the solution classes, and how to recognize when the waters are getting > too deep. Very true and very important. Most of the IETF can't tell you the difference between object security and transport security, let alone what the tools we have available are and how to pick between them. If they don't grok the basics there is no way to get them to pick the right tool for the job. -- Perry E. Metzger perry@wasabisystems.com -- Quality NetBSD Sales, Support & Service. http://www.wasabisystems.com/ From owner-saag Tue Nov 21 13:03:03 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17627 Tue, 21 Nov 2000 13:02:54 -0500 (EST) Message-Id: <5.0.0.25.2.20001121095918.02a08700@limbo.net> X-Sender: rodney@limbo.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 21 Nov 2000 10:02:18 -0800 To: jis@mit.edu, mleech@nortelnetworks.com From: Rodney Thayer Subject: Re: Fwd: 49th IETF-Security Tutorial Cc: saag@lists.tislabs.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-saag@lists.tislabs.com Precedence: bulk so who's doing it? p.s. I didn't see it on the web site, which was my first choice where to answer this. I didn't go back through the IETF lists to see if it was discussed, if so, sorry. I do think it's a good idea. At 05:22 PM 11/17/00 -0800, RL 'Bob' Morgan wrote: > > I would imagine that some of the folks here would be interested in > > this, and are possibly giving the tutorial... > >It would indeed be interesting to know *who* will be doing the tutoring. From owner-saag Mon Nov 27 00:58:25 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA05135 Mon, 27 Nov 2000 00:58:03 -0500 (EST) Message-ID: <3A21F73C.2FBE7626@mit.edu> Date: Mon, 27 Nov 2000 00:55:08 -0500 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 4.61C- [en] (X11; U; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: Rodney Thayer CC: mleech@nortelnetworks.com, saag@lists.tislabs.com Subject: Re: Fwd: 49th IETF-Security Tutorial References: <5.0.0.25.2.20001121095918.02a08700@limbo.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-saag@lists.tislabs.com Precedence: bulk I'm the stuckee on this. I'll be working on the presentation this week (and maybe into the weekend) and will send out a note when I have the slides up for comment. -Jeff Rodney Thayer wrote: > so who's doing it? > > p.s. I didn't see it on the web site, which was my first > choice where to answer this. I didn't go back through the IETF > lists to see if it was discussed, if so, sorry. > > I do think it's a good idea. > > At 05:22 PM 11/17/00 -0800, RL 'Bob' Morgan wrote: > > > > I would imagine that some of the folks here would be interested in > > > this, and are possibly giving the tutorial... > > > >It would indeed be interesting to know *who* will be doing the tutoring. From owner-saag Mon Nov 27 10:37:01 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07231 Mon, 27 Nov 2000 10:36:56 -0500 (EST) X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Mon, 27 Nov 2000 01:22:29 -0800 (PST) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: "Steven M. Bellovin" cc: saag@lists.tislabs.com Subject: Re: Fwd: 49th IETF-Security Tutorial In-Reply-To: <20001120165442.883CA35DC2@smb.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-saag@lists.tislabs.com Precedence: bulk > >(I also can't help but think that it's a short step from tutorials to > >vendor demonstrations and hospitality booths, but that's a different > >topic.) > > Strong disagreement. > > Here's the problem: we've learned that security is necessary, and > anyone in the security area will tell you that it has to be designed in > from the start, not added on. But there are too few security folks to > attach to every WG; besides, in an organization like the IETF, how do > you "assign" someone to a WG? > > The idea of this tutorial is to provide a sufficient introduction that > folks who aren't security geeks can start to understand the problems, > the solution classes, and how to recognize when the waters are getting > too deep. I agree completely that this problem is important and urgent. That's why I helped write the text in RFC 2829 that describes and justifies LDAPv3's security design, text that has been re-used for other protocols. That's why I gave a talk at the BXXP BoF in Adelaide that describes how these same methods were applied to BXXP (http://staff.washington.edu/rlmorgan/talk/blocks.sasl.2000.03/). And let me be the first to thank Jeff and whoever else for organizing the upcoming event. I'll be there and I hope it succeeds (though I fear the ratio of security-geek to plain-old-geek will be high). But, upon further thought, I remain skeptical about the value of adding "Sunday tutorial" to the set of IETF communication methods. We already have Standard, Informational, Experimental, FYI, and BCP RFCs; Internet drafts; Working Groups and BoFs; plenary talks; IAB and IESG plenaries; and the pantheon of bar-bofs, working lunches, and hallway politicking. If the intent of a tutorial is to do "real IETF work" (as this one seems to be, ie documenting best current practice for protocol design) then why shouldn't it fit in to the regular week's activities in one of our existing familiar formats? If the tutorial isn't doing real IETF work, then I claim it indeed adds to the growing list of sideshow events to IETF week, a growth that eventually leads to Comdexification (or perhaps Interopportunism). I think a weekend full of tutorials prior to IETF week is a real possibility, and I view it with alarm. - RL "Bob" From owner-saag Mon Nov 27 13:14:07 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08101 Mon, 27 Nov 2000 13:13:35 -0500 (EST) Message-Id: <5.0.2.1.0.20001127130305.02eba0e0@mail.mbl.edu> X-Sender: crocker@mail.mbl.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 27 Nov 2000 13:15:10 -0500 To: "RL 'Bob' Morgan" From: Steve Crocker Subject: Re: Fwd: 49th IETF-Security Tutorial Cc: "Steven M. Bellovin" , saag@lists.tislabs.com In-Reply-To: References: <20001120165442.883CA35DC2@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-saag@lists.tislabs.com Precedence: bulk Bob, et al, Let me weigh in with a different point of view. The IETF meetings serve multiple purposes. When I was active on the IESG, 38% of IETF attendees were first-timers. I don't know what the current stats are, but I imagine there is still a high degree of turnover and influx. The veterans and the people actively engaged in developing specs within the working groups are often annoyed with the newbies, but I think the open nature of the meetings is actually one of the strengths of the IETF. The security area has always had a special challenge because very little of its work stands in isolation. A large fraction of the security protocol work is done in conjunction with working groups in other areas. As we all know, there is only a limited number of people with experience and sophistication with respect to security issues, so there's a real challenge for us in the security area to communicate and collaborate efficiently and effectively. A tutorial is likely to be useful to veterans in other areas and not just to newbies. But even if only newbies attended, the newbies of today are the working group chairs of tomorrow. If this were a paid tutorial, aimed at maximizing revenue, I might share your reaction. But as an honest attempt to communicate to colleagues and improve the effectiveness of the security community, I can only applaud. Steve At 01:22 AM 11/27/2000 -0800, RL 'Bob' Morgan wrote: > > >(I also can't help but think that it's a short step from tutorials to > > >vendor demonstrations and hospitality booths, but that's a different > > >topic.) > > > > Strong disagreement. > > > > Here's the problem: we've learned that security is necessary, and > > anyone in the security area will tell you that it has to be designed in > > from the start, not added on. But there are too few security folks to > > attach to every WG; besides, in an organization like the IETF, how do > > you "assign" someone to a WG? > > > > The idea of this tutorial is to provide a sufficient introduction that > > folks who aren't security geeks can start to understand the problems, > > the solution classes, and how to recognize when the waters are getting > > too deep. > >I agree completely that this problem is important and urgent. That's why >I helped write the text in RFC 2829 that describes and justifies LDAPv3's >security design, text that has been re-used for other protocols. That's >why I gave a talk at the BXXP BoF in Adelaide that describes how these >same methods were applied to BXXP >(http://staff.washington.edu/rlmorgan/talk/blocks.sasl.2000.03/). And let >me be the first to thank Jeff and whoever else for organizing the upcoming >event. I'll be there and I hope it succeeds (though I fear the ratio of >security-geek to plain-old-geek will be high). > >But, upon further thought, I remain skeptical about the value of adding >"Sunday tutorial" to the set of IETF communication methods. We already >have Standard, Informational, Experimental, FYI, and BCP RFCs; Internet >drafts; Working Groups and BoFs; plenary talks; IAB and IESG plenaries; >and the pantheon of bar-bofs, working lunches, and hallway politicking. >If the intent of a tutorial is to do "real IETF work" (as this one seems >to be, ie documenting best current practice for protocol design) then why >shouldn't it fit in to the regular week's activities in one of our >existing familiar formats? If the tutorial isn't doing real IETF work, >then I claim it indeed adds to the growing list of sideshow events to IETF >week, a growth that eventually leads to Comdexification (or perhaps >Interopportunism). I think a weekend full of tutorials prior to IETF week >is a real possibility, and I view it with alarm. > > - RL "Bob" From owner-saag Thu Nov 30 02:22:55 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA18928 Thu, 30 Nov 2000 02:22:29 -0500 (EST) Message-Id: <200011300723.XAA07934@breakaway.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: Re: Fwd: 49th IETF-Security Tutorial To: saag@lists.tislabs.com In-reply-to: Steve Crocker 's message of Mon, 27 Nov 2000 13:15:10 -0500 Reply-to: saag@lists.tislabs.com From: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Nov 2000 23:23:53 -0800 Sender: owner-saag@lists.tislabs.com Precedence: bulk It seems to me that what RLBob was more pointing out is that a key aspect to the IETF's work product, namely documents, is they are peer-reviewed, subject to a process pipeline and review cycle, change-controlled, and so on. crocker@mbl.edu then said: > A large fraction of the security protocol work is done in conjunction > with working groups in other areas. As we all know, there is only a > limited number of people with experience and sophistication with > respect to security issues, so there's a real challenge for us in the > security area to communicate and collaborate efficiently and > effectively. So, perhaps what RLBob's pointing out is that if we're going to address this problem, we should use our peer-reviewed document-producing process to produce this "tutorial". It would be, after all, yet another document in a very similar sense to many other existing docs -- e.g. Site Security Handbook (FYI8), Connecting to the Internet - What Connecting Institutions Should Anticipate (FYI16). Internet Users' Glossary (FYI18), K-12 Internetworking Guidelines (FYI26), et al. There's a concern that if we do do a somewhat ad-hoc critical-component tutorial, such as "security in protocol design", and it's created from one or just a few people's perspectives, that down the road, after our techniques have evolved some more, we'll get into situations where we're examining some new foo-protocol's security considerations, and asking.. "why'd you do this part of it this way?" ..and the answer might be.. "well, I was at the IETF security tutorial in Dec 2000 and that's the way so-and-so said we do things like this.." ..and so then we, or some subset of we, might well say.. "We're doing that this other way now.." ..But who's "we"? And where's this stuff written down in a peer-reviewed doc that's embedded in our overall doc-producing and doc-distributing process that we all apparently believe in? Also, an intersecting facet of all this is having a place where folks can go to ask "protocol design security considerations" questions, rather than trying to figure out precisely which security area working group wherein it's applicable. I'd somewhat thought that's what "saag@lists.tislabs.com" might be used for when I stumbled across it on the Security Area page a while back (buried as a "mailto:" link entitled only "Security Area Advisory Group. (SAAG)"), but it's turned out to be one of the very quietest "still nominally alive" lists I'm on. I also note that it hasn't (according to my personal archives) been mentioned on the IETF list (or essentially any other IETF lists) in the past 3+ years. Plus I don't see it mentioned in any of my SAAG meeting notes from the past several years (I haven't been able to make all the IETFs tho). Perhaps in addition to any tutorial/document that the Security Area develops for helping folks out, we oughta also either advertise the SAAG list as a place to go ask overall "protocol design security considerations" questions, or create and advertise a list for that purpose. JeffH From owner-saag Thu Nov 30 09:26:20 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19877 Thu, 30 Nov 2000 09:25:49 -0500 (EST) To: saag@lists.tislabs.com Subject: Re: Fwd: 49th IETF-Security Tutorial References: <200011300723.XAA07934@breakaway.Stanford.EDU> From: "Perry E. Metzger" Date: 30 Nov 2000 09:27:08 -0500 In-Reply-To: Jeff.Hodges@KingsMountain.com's message of "Wed, 29 Nov 2000 23:23:53 -0800" Message-ID: <87g0k9tu0z.fsf@snark.piermont.com> Lines: 13 X-Mailer: Gnus v5.7/Emacs 20.6 Sender: owner-saag@lists.tislabs.com Precedence: bulk Jeff.Hodges@KingsMountain.com writes: > So, perhaps what RLBob's pointing out is that if we're going to address this > problem, we should use our peer-reviewed document-producing process > to produce this "tutorial". That would take about sixteen years. By which time we wouldn't want it any more. I think I'm comfortable with the current process. If we don't trust Jeff to give a tutorial, why have we trusted him to serve on the IESG? .pm From owner-saag Wed Dec 20 00:44:33 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA00655 Wed, 20 Dec 2000 00:44:10 -0500 (EST) Date: Wed, 20 Dec 2000 00:46:00 -0500 Message-Id: <200012200546.eBK5k0I17984@snap.thunk.org> To: saag@lists.tislabs.com cc: fair@clock.org Subject: Should we laugh, or cry....? From: tytso@mit.edu Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-saag@lists.tislabs.com Precedence: bulk >From Apple's web page concerning the Airport, http://www.apple.com/education/k12/networking/faq/ "When transmitting data, AirPort uses 40-bit encryption to scramble information - that's higher than military-strength encryption!" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - Ted From owner-saag Tue Dec 26 09:50:22 2000 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17154 Tue, 26 Dec 2000 09:49:50 -0500 (EST) From: "Perry E. Metzger" To: tytso@mit.edu Cc: saag@lists.tislabs.com, fair@clock.org Subject: Re: Should we laugh, or cry....? References: <200012200546.eBK5k0I17984@snap.thunk.org> Date: 22 Dec 2000 17:51:34 -0500 In-Reply-To: tytso@mit.edu's message of "Wed, 20 Dec 2000 00:46:00 -0500" Message-ID: <87n1dom5mx.fsf@snark.piermont.com> Lines: 21 X-Mailer: Gnus v5.7/Emacs 20.6 Sender: owner-saag@lists.tislabs.com Precedence: bulk We should inform our contacts at Apple that it would be useful to fix this misperception. tytso@mit.edu writes: > >From Apple's web page concerning the Airport, > > http://www.apple.com/education/k12/networking/faq/ > > "When transmitting data, AirPort uses 40-bit encryption to scramble > information - that's higher than military-strength encryption!" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > - Ted > -- Perry E. Metzger perry@wasabisystems.com -- Quality NetBSD CDs, Support & Service. http://www.wasabisystems.com/