From owner-ietf-ppp@merit.edu Thu Nov 1 17:33:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02166 for ; Thu, 1 Nov 2001 17:33:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 829C8912E9; Thu, 1 Nov 2001 17:32:40 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50013912EA; Thu, 1 Nov 2001 17:32:40 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4022F912E9 for ; Thu, 1 Nov 2001 17:32:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id E803A5E132; Thu, 1 Nov 2001 17:32:33 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by segue.merit.edu (Postfix) with SMTP id 19B845E121 for ; Thu, 1 Nov 2001 17:32:29 -0500 (EST) Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Thu, 01 Nov 2001 17:32:13 -0500 Message-Id: <5.1.0.14.2.20011101130653.02573de0@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 01 Nov 2001 13:51:23 -0500 To: ietf-ppp@merit.edu From: Robert Moskowitz Subject: Key derivation for SRP In-Reply-To: References: <5.1.0.14.2.20011016124202.02644638@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Section 3.1 in RFC 2945 presents a KEYMAT derivation method that is new to me. I have discussed this with a couple people in the crypto community and I have not found anyone that says this is a GOOD method and has any value over more common methods like that used in IKE or ANSI 9.42. the NIST Key Management Workshop ( that I am attending right now) has a modified 9.42 key derivation algortihm (see http://csrc.nist.gov/encryption/kms/workshop2-page.html and the "key establishment schemes document" tag, sec 6.3). Basically it is interate: Hash(sharedkey||counter||U||V||[Sharedinfo]) IKE does HMAC and in iteration 2 - N feeds the prior hash in instead of sharedkey. Both of these methods have considerable text on their use. Is there similar for the key interleave? I would recommend we specify a key derivation method more consistant with recognized methods. From owner-ietf-ppp@merit.edu Sun Nov 4 12:45:19 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14707 for ; Sun, 4 Nov 2001 12:45:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EB92191277; Sun, 4 Nov 2001 12:41:55 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6187391278; Sun, 4 Nov 2001 12:41:54 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E9A6D91271 for ; Sun, 4 Nov 2001 12:40:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF47E5DDCE; Sun, 4 Nov 2001 12:40:37 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by segue.merit.edu (Postfix) with SMTP id 6DA375DD91 for ; Sun, 4 Nov 2001 12:40:37 -0500 (EST) Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Sun, 04 Nov 2001 12:40:36 -0500 Message-Id: <5.1.0.14.2.20011104082627.0263c500@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 04 Nov 2001 08:53:02 -0500 To: ietf-ppp@merit.edu From: Robert Moskowitz Subject: More on key derivation for SRP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I was at the Key management workshop at NIST last week (www.nist.gov/kms). This workshop is moving toward KM schemes that will be acceptable for US gov stuff. Although the basis for this work is ANSI x9.42 and 9.63, they have developed a scheme expression that can represent the 2 ephemeral, 1 static DH key exchange method. However, section 6.3 deals with key derivation. IMHO, it needs some work. IKE's method is VERY close. The key derivation in sec 5 of rfc 2409 pretty much fits (different order), and appendix B is a bit different (no counter and HMAC instead of HASH). 2409's method is not even in the ball park and is unlikely to be accepted by NIST as a good key deriviation method. Thus I would recommend that following be used: First NIST may end up REQUIRING key derivation from a master key. So given: S is the computed master key. the derived key is: K1 = SHA1( S || 1 || clientname || servername ) K2 = SHA1( S || 2 || K1 ) K3 = SHA1( S || 3 || K2 ) . . and K = K1 || K2 || K3 || .... This method will most likely be added as a result of last week's meeting. BTW, the only current 'approved' method (from 9.42) would be: K1 = SHA1( S || 1 || clientname || servername ) K2 = SHA1( S || 2 || clientname || servername || K1 ) K3 = SHA1( S || 3 || clientname || servername || K2 ) where K1 K2 etc within the hash is 'shareddata'. Oh, and Hugo Kracyzk would say that HMAC is better to use in all of this over SHA1. So it is possible that key macs will be allowed in place of a hash. From owner-ietf-ppp@merit.edu Sun Nov 4 13:20:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14888 for ; Sun, 4 Nov 2001 13:20:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1D5B191270; Sun, 4 Nov 2001 13:20:10 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB3CE91271; Sun, 4 Nov 2001 13:20:09 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BECA591270 for ; Sun, 4 Nov 2001 13:20:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id A07465DDCE; Sun, 4 Nov 2001 13:20:08 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B50EE5DD95 for ; Sun, 4 Nov 2001 13:20:07 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA50111; Sun, 4 Nov 2001 10:10:51 -0800 (PST) (envelope-from aboba@internaut.com) Date: Sun, 4 Nov 2001 10:10:50 -0800 (PST) From: Bernard Aboba To: Robert Moskowitz Cc: ietf-ppp@merit.edu, dansimon@microsoft.com Subject: Re: More on key derivation for SRP In-Reply-To: <5.1.0.14.2.20011104082627.0263c500@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The problem of session key derivation from a master key is more general than just SRP. In my opinion, there should be a standard way of deriving session keys from master keys, that should apply to *all* EAP methods. That way, each EAP method doesn't need its own individual session key derivation algorithm. Note that there are issues with applying the algorithm below as a general EAP key derivation mechanism. The algorithm assumes that the master key is accessible and that operations can be directly performed on it. This is not the case for all EAP methods. For example, TLS and GSS-API implementations typically do not enable direct access to the master key. However, operations can be performed using functions of the master key, such as GSS_Wrap(), and GSS_GetMIC(). So to make this more general, it would appear necessary to derive another quantity S', which would then be plugged into the formulas below in place of S. S' would be a function of S, derived via operations that are permitted on the master key. On Sun, 4 Nov 2001, Robert Moskowitz wrote: > I was at the Key management workshop at NIST last week (www.nist.gov/kms). > > This workshop is moving toward KM schemes that will be acceptable for US > gov stuff. Although the basis for this work is ANSI x9.42 and 9.63, they > have developed a scheme expression that can represent the 2 ephemeral, 1 > static DH key exchange method. > > However, section 6.3 deals with key derivation. IMHO, it needs some > work. IKE's method is VERY close. The key derivation in sec 5 of rfc 2409 > pretty much fits (different order), and appendix B is a bit different (no > counter and HMAC instead of HASH). > > 2409's method is not even in the ball park and is unlikely to be accepted > by NIST as a good key deriviation method. > > Thus I would recommend that following be used: > > First NIST may end up REQUIRING key derivation from a master key. So given: > > S is the computed master key. > > the derived key is: > > K1 = SHA1( S || 1 || clientname || servername ) > K2 = SHA1( S || 2 || K1 ) > K3 = SHA1( S || 3 || K2 ) > . > . > > and K = K1 || K2 || K3 || .... > > This method will most likely be added as a result of last week's meeting. > > BTW, the only current 'approved' method (from 9.42) would be: > > K1 = SHA1( S || 1 || clientname || servername ) > K2 = SHA1( S || 2 || clientname || servername || K1 ) > K3 = SHA1( S || 3 || clientname || servername || K2 ) > > where K1 K2 etc within the hash is 'shareddata'. > > Oh, and Hugo Kracyzk would say that HMAC is better to use in all of this > over SHA1. So it is possible that key macs will be allowed in place of a hash. > > From owner-ietf-ppp@merit.edu Mon Nov 5 08:10:53 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14653 for ; Mon, 5 Nov 2001 08:10:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0A78791221; Mon, 5 Nov 2001 08:10:40 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA92E9127F; Mon, 5 Nov 2001 08:10:39 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B81AD91221 for ; Mon, 5 Nov 2001 08:10:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 98E9D5DDFD; Mon, 5 Nov 2001 08:10:38 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by segue.merit.edu (Postfix) with SMTP id 0BCCE5DDA2 for ; Mon, 5 Nov 2001 08:10:38 -0500 (EST) Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Mon, 05 Nov 2001 08:10:37 -0500 Message-Id: <5.1.0.14.2.20011105080713.0240cc90@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 05 Nov 2001 08:08:17 -0500 To: ietf-ppp@merit.edu From: Robert Moskowitz Subject: Re: More on key derivation for SRP In-Reply-To: <5.1.0.14.2.20011104082627.0263c500@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 08:53 AM 11/4/2001 -0500, Robert Moskowitz wrote: oops one error. So much for writing this at the Baltimore airport, waiting for a flight. >2409's method is not even in the ball park and is unlikely to be accepted >by NIST as a good key deriviation method. that is 2945. The Interleave SHA method. From owner-ietf-ppp@merit.edu Mon Nov 5 08:26:52 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15785 for ; Mon, 5 Nov 2001 08:26:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AEFF291280; Mon, 5 Nov 2001 08:26:22 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84CBB91282; Mon, 5 Nov 2001 08:26:22 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C8BD91280 for ; Mon, 5 Nov 2001 08:26:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F0C35DDFD; Mon, 5 Nov 2001 08:26:21 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by segue.merit.edu (Postfix) with SMTP id E00D25DDA2 for ; Mon, 5 Nov 2001 08:26:20 -0500 (EST) Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Mon, 05 Nov 2001 08:25:06 -0500 Message-Id: <5.1.0.14.2.20011105082131.02415160@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 05 Nov 2001 08:24:55 -0500 To: Bernard Aboba From: Robert Moskowitz Subject: Re: More on key derivation for SRP Cc: ietf-ppp@merit.edu, dansimon@microsoft.com In-Reply-To: References: <5.1.0.14.2.20011104082627.0263c500@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 10:10 AM 11/4/2001 -0800, Bernard Aboba wrote: >Note that there are issues with applying the algorithm below as a general >EAP key derivation mechanism. > >The algorithm assumes that the master key is accessible and that >operations can be directly performed on it. > >This is not the case for all EAP methods. For example, TLS >and GSS-API implementations typically do not enable direct access to the >master key. However, operations can be performed using functions of the >master key, such as GSS_Wrap(), and GSS_GetMIC(). > >So to make this more general, it would appear necessary to derive >another quantity S', which would then be plugged into the formulas below >in place of S. S' would be a function of S, derived via operations that >are permitted on the master key. By 'Master Key' in this algorithm it refers to a key available to the two parties. Thus a method of key transport or other appropriate mechanism is first needed by MOST EAP types to get a Master Key. For example the practice of the RADIUS server to randomly create a master key and then wrap it with the EAP calculated key is one approach. From owner-ietf-ppp@merit.edu Mon Nov 5 08:47:06 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16860 for ; Mon, 5 Nov 2001 08:47:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 093C791282; Mon, 5 Nov 2001 08:46:23 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C02D691283; Mon, 5 Nov 2001 08:46:22 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 71EF991282 for ; Mon, 5 Nov 2001 08:46:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3A0B95DDFD; Mon, 5 Nov 2001 08:46:21 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by segue.merit.edu (Postfix) with SMTP id CAD185DDA2 for ; Mon, 5 Nov 2001 08:46:20 -0500 (EST) Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Mon, 05 Nov 2001 08:44:22 -0500 Message-Id: <5.1.0.14.2.20011105083804.0240cc90@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 05 Nov 2001 08:44:06 -0500 To: Bernard Aboba From: Robert Moskowitz Subject: Standardizing Key derivation for EAP Cc: ietf-ppp@merit.edu, dansimon@microsoft.com In-Reply-To: References: <5.1.0.14.2.20011104082627.0263c500@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 10:10 AM 11/4/2001 -0800, Bernard Aboba wrote: >The problem of session key derivation from a master key is more general >than just SRP. > >In my opinion, there should be a standard way of deriving session keys >from master keys, that should apply to *all* EAP methods. What userinfo is consistant across EAP types or can be made consistant for all future types. Obviously there is the client identity. Or at least I hope so. The SRP ID has the pseudo ID that can still be used. What about the servername? Is that consistant? Somehow, I don't think the Radius Client (NAS, AP, etc) name is typically known to the client, but I bet it should. The thing is, in a key derivation, the crypto people like to have some shared data to mix in with the key. It CAN be public information, like IP or MAC addresses, or synced time. But this mixing has been shown to be important. If you want a general function that can be referenced you need to have such things. Otherwise you have a general algorithm like I showed and a specific use for each type. From owner-ietf-ppp@merit.edu Mon Nov 5 10:44:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24679 for ; Mon, 5 Nov 2001 10:44:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B4E719128D; Mon, 5 Nov 2001 10:44:21 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 889619128E; Mon, 5 Nov 2001 10:44:21 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 747CB9128D for ; Mon, 5 Nov 2001 10:44:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5A3835DD8F; Mon, 5 Nov 2001 10:44:20 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by segue.merit.edu (Postfix) with ESMTP id 6BC0B5DD8C for ; Mon, 5 Nov 2001 10:44:19 -0500 (EST) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id fA5FiIf29578 for ; Mon, 5 Nov 2001 17:44:18 +0200 (EET) Received: (qmail 648 invoked from network); 5 Nov 2001 15:44:18 -0000 Received: from unknown (HELO nikita.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 5 Nov 2001 15:44:18 -0000 Received: (from ltarkkal@localhost) by nikita.hel.fi.ssh.com (8.11.0/8.11.0) id fA5Gipd25202 for ietf-ppp@merit.edu; Mon, 5 Nov 2001 18:44:51 +0200 Date: Mon, 5 Nov 2001 18:44:51 +0200 From: Lauri Tarkkala To: ietf-ppp@merit.edu Subject: EAP-SRP Challenge Message-ID: <20011105184435.A25111@nikita.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Some comments on the document "draft-ietf-pppext-eap-srp-03.txt". The document defines that the client in an EAP SRP exchange verify the group and generator are sufficient for providing protection for the secret x, where x is SHA1( || SHA1( || ":" || )). The authenticator provides the prime modulus N and the generator g. The client must then check that "N" is prime and then it must attempt to ensure that "g" is a generator of the group and not of a sub-group of N. This can be done easily IF "N" is a safe prime (s.t. N=2p+1 and p is prime), in which case the order (q) of g must be either N-1, 2 or (N-1)/2. I assume that this is the intended meaning of the specification, but I would like to see it stated explicitly that the modulus must be a safe prime (RFC2945 states that N should be a safe prime (note "should" is used instead of the designated "SHOULD" keyword)). This would prevent sloppily written implementations from failing to interoperate with clients which actually attempt to verify that "g" is a generator of group Z_N. Since discovering the order of an element in a group is a hard problem I see no reason for providing the "additional" generality by assuming that the client can use some arbitrary algorithm for deciding whether a group is ok or not. > The authenticatee MUST validate that the specified generator value is > indeed a generator modulo N, as described in the SRP documentation > [SRP]. In many cases, an efficient method to do this is to keep a > list of known-good values, and compare against this list. Since the > full validation procedure is complex, the authenticator SHOULD use a > longer timeout value if the default generator and modulus are not > used; at least 30 seconds is RECOMMENDED. This is insufficient. Assuming that N is a safe-prime, then the client must perform two primality checks for integers of e.g. 2048 bits. If the authenticator is using either the Rabin-Miller or the Solovay-Strassen tests, this can take upto several minutes on a client with "limited computational resources" (depending obviously on the certainity one desires). I would recommend raising the proposed limit to at least 150 seconds. Lauri -- Lauri Tarkkala SSH Communications Security Corp From owner-ietf-ppp@merit.edu Mon Nov 5 11:57:37 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28184 for ; Mon, 5 Nov 2001 11:57:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A48AF91294; Mon, 5 Nov 2001 11:57:03 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7639F91295; Mon, 5 Nov 2001 11:57:03 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7050391294 for ; Mon, 5 Nov 2001 11:57:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 532B15DE16; Mon, 5 Nov 2001 11:57:02 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A25595DE0C for ; Mon, 5 Nov 2001 11:57:01 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA51968; Mon, 5 Nov 2001 08:47:39 -0800 (PST) (envelope-from aboba@internaut.com) Date: Mon, 5 Nov 2001 08:47:39 -0800 (PST) From: Bernard Aboba To: Robert Moskowitz Cc: ietf-ppp@merit.edu, dansimon@microsoft.com Subject: Re: Standardizing Key derivation for EAP In-Reply-To: <5.1.0.14.2.20011105083804.0240cc90@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > At 10:10 AM 11/4/2001 -0800, Bernard Aboba wrote: > >The problem of session key derivation from a master key is more general > >than just SRP. > > > >In my opinion, there should be a standard way of deriving session keys > >from master keys, that should apply to *all* EAP methods. > > What userinfo is consistant across EAP types or can be made consistant for > all future types. > > Obviously there is the client identity. Or at least I hope so. Some sort of client identity is always available. This may be garnered from the EAP-Response/Identity, but this is not required; in some cases it may be presumed from the calling-station-id. > The SRP ID > has the pseudo ID that can still be used. What about the servername? Is > that consistant? Somehow, I don't think the Radius Client (NAS, AP, etc) > name is typically known to the client, but I bet it should. The identity of the authenticator is not always known. The question is whether it is likely to be known for mutually authenticating methods that derive keys: a. It is known in EAP TLS. b. It *may* be known for EAP GSS, depending on the GSS-API method selected. > > The thing is, in a key derivation, the crypto people like to have some > shared data to mix in with the key. It CAN be public information, like IP > or MAC addresses, or synced time. But this mixing has been shown to be > important. > > If you want a general function that can be referenced you need to have such > things. > > Otherwise you have a general algorithm like I showed and a specific use for > each type. Even if it is necessary to have "classes" of algorithms and a standard key derivation method for each class, this is better than having a custom algorithm for each EAP method. From owner-ietf-ppp@merit.edu Mon Nov 5 12:27:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00139 for ; Mon, 5 Nov 2001 12:27:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CF57891297; Mon, 5 Nov 2001 12:27:23 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B0CC91298; Mon, 5 Nov 2001 12:27:22 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD23891297 for ; Mon, 5 Nov 2001 12:27:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id B4AB65DE17; Mon, 5 Nov 2001 12:27:20 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by segue.merit.edu (Postfix) with SMTP id 1F9E45DE16 for ; Mon, 5 Nov 2001 12:27:20 -0500 (EST) Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Mon, 05 Nov 2001 12:25:44 -0500 Message-Id: <5.1.0.14.2.20011105122203.0263c500@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 05 Nov 2001 12:23:16 -0500 To: Bernard Aboba From: Robert Moskowitz Subject: Re: Standardizing Key derivation for EAP Cc: ietf-ppp@merit.edu, dansimon@microsoft.com In-Reply-To: References: <5.1.0.14.2.20011105083804.0240cc90@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 08:47 AM 11/5/2001 -0800, Bernard Aboba wrote: >Even if it is necessary to have "classes" of algorithms and a standard key >derivation method for each class, this is better than having a custom >algorithm for each EAP method. Want to whip up a draft? I probably can get some help from Russ Housley (he was also at the meeting), and a NIST person or two. Tim Polk was also there and has worked on this doc. I suggest you go to www.nist.gov/kms and pull down the schemes workshop doc. Section 6.3 is set up as a function call.... From owner-ietf-ppp@merit.edu Tue Nov 6 09:27:28 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14081 for ; Tue, 6 Nov 2001 09:27:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C44A91224; Tue, 6 Nov 2001 09:27:15 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E42089122A; Tue, 6 Nov 2001 09:27:14 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB24E91224 for ; Tue, 6 Nov 2001 09:27:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 806A65DE00; Tue, 6 Nov 2001 09:27:13 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by segue.merit.edu (Postfix) with SMTP id E0ABC5DDD2 for ; Tue, 6 Nov 2001 09:27:12 -0500 (EST) Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Tue, 06 Nov 2001 09:27:11 -0500 Message-Id: <5.1.0.14.2.20011106091901.02448ea8@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 Nov 2001 09:26:59 -0500 To: ietf-ppp@merit.edu From: Robert Moskowitz Subject: One 'minor' security risk for SRP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Back in May, an improved password-guessing attack was described on sci.crypt. Basically it cuts the round trips for password-guessing by a rogue server by 50%. http://groups.google.com/groups?q=srp+attack&hl=en&rnum=1&selm=23LI6.211291%24lj4.6039965%40news6.giganews.com gets you there. David Jablon pointed this out to me at the NIST key management schemes meeting. He is active in IEEE p1363 where there is work to standardize on some strong password exchanges that SRP embodies. David had the following about this attack: Yeah, the thing I'm most "impressed" with is that I and other's didn't see this so much earlier. A quick fix, which I think both Tom and I saw immediately, is to use something like hash(V) instead of V as the obfuscator to break the symmetry. Not so sure if this helps or hurts any proof, but the difficulty of computing the discrete log base g of hash(V) certainly seems to stop this particular threat. We at least should add words about this attack, and perferably work with Tom on changes to 2945. From owner-ietf-ppp@merit.edu Tue Nov 6 11:25:38 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20047 for ; Tue, 6 Nov 2001 11:25:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 59AD69122E; Tue, 6 Nov 2001 11:25:22 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27BB3912A9; Tue, 6 Nov 2001 11:25:22 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA6279122E for ; Tue, 6 Nov 2001 11:25:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id A4C855DDE5; Tue, 6 Nov 2001 11:25:20 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by segue.merit.edu (Postfix) with SMTP id 3BDF85DDD9 for ; Tue, 6 Nov 2001 11:25:20 -0500 (EST) Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Tue, 06 Nov 2001 11:24:10 -0500 Message-Id: <5.1.0.14.2.20011106111757.0261bdf8@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 Nov 2001 11:23:59 -0500 To: Bernard Aboba From: Robert Moskowitz Subject: Re: Standardizing Key derivation for EAP Cc: ietf-ppp@merit.edu, dansimon@microsoft.com In-Reply-To: <5.1.0.14.2.20011105083804.0240cc90@localhost> References: <5.1.0.14.2.20011104082627.0263c500@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA20047 For those of you that have not gotten around to looking at the NIST schemes document, I was sent it in editable format (as they are expecting comments from me!), and here is section 6.3: Function call: kdf(Z,OtherInput), where OtherInput is U, V, keydatalen, hashlen, [SharedInfo]. Input description: 1. A bit string Z that is the shared secret. 2. Bit strings U and V that denote the identities of the participating parties, where U is the party that initiated the key establishment process, and V is the responder in the key establishment process. 3. An integer keydatalen that is the length in bits of the keying material to be generated. keydatalen must be less than hashlen ? (232-1). 4. An integer hashlen that is the length in bits of the hash function to be used to derive the keying material. 5. An optional bit string SharedInfo that consists of data shared by parties U and V. Process: a. Initiate a 32-bit, big-endian bit string counter as 0000000116. b. For i=1 to i= , do the following: Compute Hashi = H(Z||counter||U||V||[SharedInfo]) Increment counter Increment i. c. Let Hhashj denote Hashj if keydatalen/hashlen is an integer, and let it denote the (keydatalen-(hashlen (j-1))) leftmost bits of Hashj otherwise. d. Set DerivedKeyingMaterial = Hash1||Hash2||…||Hashj-1||Hhashj. Output: The bit string DerivedKeyingMaterial of keydatalen bits. [Question: Since both parties need to compute the same derived keying material, does the necessity to provide U and V create a problem? For example, can all applications determine who the initiator and responder are so that they would know in what order to place the identities? Or would it be better to alphabetize the identities? Rather than using “U||V”, would it be better to use a function of the two entities, such as “(U OR V)||(U AND V)”, where “OR” and “AND” are bit-wise logical operators?] The derived keying material may be parsed into one or more keys or other cryptographic keying material (e.g., IVs). Any scheme attempting to call the key derivation function for a bit string of length greater than or equal to hashlen (232-1) bits must output “invalid” and stop. Note: The security provided by the derived keying material is limited by the cryptographic strength of the key establishment scheme. For example, if an elliptic curve scheme is used with a 160 bit private key, a strength of roughly 80 bits is provided to the derived keying material, i.e., a 128 bit AES key derived from such a scheme provides no more than 80 bits of security to the information it protects, not the 128 bits of security that might be expected when using AES with a truly random key. Note: This technique differs from the key derivation functions defined in ANSI X9.42 and X9.63. In this workshop document, the identities of the initiating party (U) and the recipient (V) are included in the data that is hashed. In ANSI X9.42 and X9.63, these identities could be considered a part of the SharedInfo, which is optional and not defined. ANSI X9.42 also includes a second key derivation function that is based on ASN.1 DER encoding. In the meeting, Russ Housley pointed out that actually 9.42 uses DER encoding to sort the order of U and V and thus eliminating the difference and potential interop problem between an inititator and responder. Also RFC 2407 uses HMAC instead of HASH and feeds the result of HASHi into HASH(i+1). From owner-ietf-ppp@merit.edu Tue Nov 6 14:27:59 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28711 for ; Tue, 6 Nov 2001 14:27:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 15FA19121A; Tue, 6 Nov 2001 14:27:45 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC23491220; Tue, 6 Nov 2001 14:27:44 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB4A49121A for ; Tue, 6 Nov 2001 14:27:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 856655DD8D; Tue, 6 Nov 2001 14:27:43 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by segue.merit.edu (Postfix) with ESMTP id 140AD5DDE5 for ; Tue, 6 Nov 2001 14:27:16 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA26384 for ; Tue, 6 Nov 2001 13:24:38 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA6JREN179668 for ; Tue, 6 Nov 2001 14:27:14 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.9.3) with ESMTP id OAA06712 for ; Tue, 6 Nov 2001 14:26:51 -0500 Message-Id: <200111061926.OAA06712@rotala.raleigh.ibm.com> To: ietf-ppp@merit.edu Subject: Re: PPP over AAL2 to Proposed Standard In-Reply-To: Message of "Tue, 30 Oct 2001 08:14:11 EST." <4.3.2.7.2.20011030081115.0597ab80@pop-server.columbus.rr.com> Date: Tue, 06 Nov 2001 14:26:51 -0500 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Karl Fox writes: > The PPPEXT Working Group recommends that PPP over AAL2 > (draft-ietf-pppext-ppp-over-aal2-01.txt) be advanced to Proposed Standard. In reviewing this document, I don't have any major issues. One question: > This proposal uses two UUI code-points as follows: > > UUI Code-point Packet Content > ++++++++++++++ ++++++++++++++ > > 27 non-final packet. > > 26 final packet. Does the use of these code-point/values need approval from anyone, or are these codes defined by the applications using AAL2? Also, > ITU-T I.366.1 and I.366.2 define Service Specific Convergence Sub- Would be good to have a pointer into the reference section for this > I.363.2. This layer specifies packet formats and procedures to encode Ditto Finally, the document needs a security considerations section. Thomas From owner-ietf-ppp@merit.edu Tue Nov 6 14:31:30 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29055 for ; Tue, 6 Nov 2001 14:31:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EB7A591220; Tue, 6 Nov 2001 14:30:18 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B986091227; Tue, 6 Nov 2001 14:30:18 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 47A2891220 for ; Tue, 6 Nov 2001 14:30:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F0145DDDF; Tue, 6 Nov 2001 14:30:17 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by segue.merit.edu (Postfix) with ESMTP id 5B16F5DD8D for ; Tue, 6 Nov 2001 14:30:15 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA39996 for ; Tue, 6 Nov 2001 13:27:37 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA6JUDN46668 for ; Tue, 6 Nov 2001 14:30:14 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.9.3) with ESMTP id OAA06734 for ; Tue, 6 Nov 2001 14:29:51 -0500 Message-Id: <200111061929.OAA06734@rotala.raleigh.ibm.com> To: ietf-ppp@merit.edu Subject: Re: Class Extensions for PPP over AAL2 to Proposed Standard In-Reply-To: Message of "Tue, 30 Oct 2001 08:16:32 EST." <4.3.2.7.2.20011030081445.00affa70@pop-server.columbus.rr.com> Date: Tue, 06 Nov 2001 14:29:51 -0500 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Karl Fox writes: > The PPPEXT Working Group recommends that Class Extensions for PPP over AAL2 > (draft-ietf-pppext-ppp-over-aal2-class-00.txt) be advanced to Proposed > Standard. Question: using the techniques described in this document, isn't it possible that packets can be reordered while traversing the link? Does this have implications for PPP when it is running over such a mode? The document doesn't say anything about this. Should it? Also, > weighted fair CID scheduler. Implementations of PPP over AAL2 real time > transport extensions SHOULD implement AAL2 CPS CID schedulers the meet the s/the/that/ ? > requirements of multi-class real time applications. Finally, the document doesn't seem to have a security considerations section. Thomas From owner-ietf-ppp@merit.edu Wed Nov 7 22:29:33 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00572 for ; Wed, 7 Nov 2001 22:29:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 861C5912C7; Wed, 7 Nov 2001 22:29:19 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5790F912C8; Wed, 7 Nov 2001 22:29:19 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4BC19912C7 for ; Wed, 7 Nov 2001 22:29:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1DF665DDAA; Wed, 7 Nov 2001 22:29:18 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by segue.merit.edu (Postfix) with ESMTP id 8C4E15DD96 for ; Wed, 7 Nov 2001 22:29:17 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fA83TGn01371; Wed, 7 Nov 2001 19:29:16 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id fA83TcW27468; Wed, 7 Nov 2001 19:29:38 -0800 (PST) Received: from BRUCET-W2K.cisco.com (dhcp-128-107-166-83.cisco.com [128.107.166.83]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id TAA00019; Wed, 7 Nov 2001 19:29:13 -0800 (PST) Message-Id: <4.3.2.7.2.20011107193255.02397ab0@mira-sjcm-2.cisco.com> X-Sender: brucet@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Nov 2001 19:35:42 -0800 To: Thomas Narten , ietf-ppp@merit.edu From: Bruce A Thompson Subject: Re: PPP over AAL2 to Proposed Standard In-Reply-To: <200111061926.OAA06712@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 02:26 PM 11/6/2001 -0500, Thomas Narten wrote: >Karl Fox writes: > >> The PPPEXT Working Group recommends that PPP over AAL2 >> (draft-ietf-pppext-ppp-over-aal2-01.txt) be advanced to Proposed Standard. > >In reviewing this document, I don't have any major issues. One >question: > >> This proposal uses two UUI code-points as follows: >> >> UUI Code-point Packet Content >> ++++++++++++++ ++++++++++++++ >> >> 27 non-final packet. >> >> 26 final packet. > >Does the use of these code-point/values need approval from anyone, or >are these codes defined by the applications using AAL2? The use of these code points in our draft is the same as what has already been defined in the SSSAR sub layer of I.366.1, so there is no approval required. >Also, > >> ITU-T I.366.1 and I.366.2 define Service Specific Convergence Sub- > >Would be good to have a pointer into the reference section for this > >> I.363.2. This layer specifies packet formats and procedures to encode > >Ditto This paragraph is referring to these standards as a whole, not specific sections of these standards. There is one statement below this paragraph that refers to a specific section of I.366.1. It's this statement: >This proposal uses the SSSAR sublayer of I.366.1 for transport. We'll add the section reference for this statement. >Finally, the document needs a security considerations section. We will add it. Bruce T >Thomas Bruce Thompson Cisco Systems email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp@merit.edu Thu Nov 8 15:09:26 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05649 for ; Thu, 8 Nov 2001 15:09:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D99C391255; Thu, 8 Nov 2001 15:09:11 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A761D91256; Thu, 8 Nov 2001 15:09:11 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BBB5B91255 for ; Thu, 8 Nov 2001 15:09:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 990815DDB9; Thu, 8 Nov 2001 15:09:10 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 1CCDD5DDB1 for ; Thu, 8 Nov 2001 15:09:10 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fA8K6sx25285; Thu, 8 Nov 2001 12:06:54 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id fA8K6IW28432; Thu, 8 Nov 2001 12:06:18 -0800 (PST) Received: from BRUCET-W2K.cisco.com (dhcp-128-107-166-83.cisco.com [128.107.166.83]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id MAA06032; Thu, 8 Nov 2001 12:06:16 -0800 (PST) Message-Id: <4.3.2.7.2.20011108120128.03f7ce90@mira-sjcm-2.cisco.com> X-Sender: brucet@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Nov 2001 12:12:45 -0800 To: Thomas Narten , ietf-ppp@merit.edu From: Bruce A Thompson Subject: Re: Class Extensions for PPP over AAL2 to Proposed Standard In-Reply-To: <200111061929.OAA06734@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 02:29 PM 11/6/2001 -0500, Thomas Narten wrote: >Karl Fox writes: > >> The PPPEXT Working Group recommends that Class Extensions for PPP over AAL2 >> (draft-ietf-pppext-ppp-over-aal2-class-00.txt) be advanced to Proposed >> Standard. > >Question: using the techniques described in this document, isn't it >possible that packets can be reordered while traversing the link? Does >this have implications for PPP when it is running over such a mode? >The document doesn't say anything about this. Should it? There is only one point in the hierarchy between PPP and the ATM transmission layer where reordering can occur when the Class Extensions for PPP over AAL2 are implemented. When an AAL2 capable node implements the Class Extensions for PPP over AAL2 there will be reordering between classes / AAL2 CIDs at the I.363.2 CPS layer. This reordering is the same as the what occurs at the MLPPP Multi-link layer as the result of an implementation of RFC 2686 (The Multi-Class Extension to Multi-Link PPP). I could not find anything in RFC 2686 that talked about the implications of reordering between classes of packets belonging to the same PPP session. Draft-ietf-pppext-ppp-over-aal2-class-00.txt is an example of the queues-of-fragments approach of reducing latency referred to in RFC 2689 (Integrated Services over Low-bitrate Links). I think it's understood that when a queues-of-fragments approach is used to reduce latency for high priority packets in a PPP session, reordering will occur between classes. Reordering can not occur within an AAL2 CID at the I.363.2 layer. The I.363.2 specification does not allow reordering of AAL2 payloads within a CID. Reordering also can not occur between cells of a VC at the ATM transmission layer (I.361). Again, the I.361 specification does not allow reordering of ATM cells within a virtual circuit. >Also, > >> weighted fair CID scheduler. Implementations of PPP over AAL2 real time >> transport extensions SHOULD implement AAL2 CPS CID schedulers the meet the > >s/the/that/ ? Yes. We'll change it. >> requirements of multi-class real time applications. > >Finally, the document doesn't seem to have a security considerations >section. We'll add this. Bruce T >Thomas Bruce Thompson Cisco Systems email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp@merit.edu Thu Nov 8 23:50:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17626 for ; Thu, 8 Nov 2001 23:50:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E7F9291260; Thu, 8 Nov 2001 23:50:29 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5BEF91261; Thu, 8 Nov 2001 23:50:29 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BDE0591260 for ; Thu, 8 Nov 2001 23:50:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id A3FE65DDBA; Thu, 8 Nov 2001 23:50:28 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B71675DD8F; Thu, 8 Nov 2001 23:50:27 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id UAA58956; Thu, 8 Nov 2001 20:40:47 -0800 (PST) (envelope-from aboba@internaut.com) Date: Thu, 8 Nov 2001 20:40:47 -0800 (PST) From: Bernard Aboba To: Glen Zorn Cc: ljb@merit.edu, ietf-ppp@merit.edu, aboba@internaut.com, "John R. Vollbrecht" Subject: Re: comments on draft-ietf-pppext-rfc2284bis-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Thu, 8 Nov 2001, Glen Zorn wrote: > First page headers > Change "Updates: RFC 2284" to "Obsoletes: RFC 2284" > > > Section 1 > I would really like to see the inclusion of some text allowing the > encapsulation of EAP packets within EAP packets (a la PEAP), maybe after the > paragraphs on sequential authentication. My take on this is that PEAP is just another EAP method, so I'm not sure what additional text would be required. > > > Section 2 > Paragraph 5 > Suggest changing "However, an initial Identity Request is not required, and > MAY be bypassed in cases where the identity is presumed (leased lines, > dedicated switch or dial-up ports, authentication via calling station > identity or MAC address, etc.)." to "However, an initial Identity Request is > not required, and MAY be bypassed in cases where the identity is presumed > (leased lines, dedicated switch or dial-up ports, etc.) or obtained in > another fashion (via calling station identity or MAC address, in the Name > field of the MD5-Challenge Response, etc.)." > Sounds reasonable. > > Sections 2.1 & 2.2 > I think that it would be a good idea to follow the l2tpext WG's lead and > separate the PPP and 802.1 applications of EAP from the base protocol. > Although the use of EAP with PPP is pretty well understood, 802.1X is still > evolving. Furthermore, I think it likely that EAP will be used in other L2 > contexts and I would like to avoid rewriting the EAP RFC again. > You are probably right. Apparently Hiperlan2 and Bluetooth are now looking at EAP support... > > Section 3.1 > In the paragraph on "Type", I find the sentence "Only one Type MUST be > specified per EAP Request or Response." a little ambivalent. If only one > Type MUST be specified, does that mean that more than one Type MAY be > specified? I don't think so ;-). Suggest replacing with "A single Type > MUST be specified for each EAP Request or Response." Sounds reasonable. > > > Section 4. > Paragraph 1 > Since the term "authentication Type code" has not been defined above, > suggest changing "The Nak Type MUST only be sent in response to a Request > which uses an authentication Type code." to "The Nak Type MUST only be sent > in response to a Request which uses an authentication Type code (i.e., Type > > 3)." Ok with me. > > Paragraph 2 > Why bother w/forward references to another I-D? Suggest changing "All EAP > implementations MUST support Types 1-4, which are defined in this document. > Types 5 and 6 are defined in [4]. Follow-on RFCs will define additional EAP > Types." to "All EAP implementations MUST support Types 1-4, which are > defined in this document. Follow-on RFCs MAY define additional EAP Types." > and deleting types 5 and 6 from the following list. > Good suggestion. > > Section 4.3 > Would it break backward compatability too badly to allow a list of single > octet authentication types in a Nak? > I think it might because clients would typically not expect it. > > Section 4.4 > This section points to RFC 1994 for details on how to do MD5-Challenge > authentication. However, the specification of the use of the Identifier > field in RFC 1994 is differentthat that described in this draft. For > example, EAP allows for retransmission of MD5-Challenge Request packets > while RFC 1994 states that both the Identifier and Challenge fields MUST > change each time a Challenge (the CHAP equivalent of the MD5-Challenge > Request packet) is sent. I think that a little clarifying text might be in > order here. Care to draft that text? (You should have known that was coming...) From owner-ietf-ppp@merit.edu Mon Nov 12 15:07:58 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16860 for ; Mon, 12 Nov 2001 15:07:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF43A91241; Mon, 12 Nov 2001 15:07:45 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C10C691242; Mon, 12 Nov 2001 15:07:44 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D977191241 for ; Mon, 12 Nov 2001 15:07:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id AF2ED5DDC3; Mon, 12 Nov 2001 15:07:43 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 888B65DD8F for ; Mon, 12 Nov 2001 15:07:42 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id LAA67095; Mon, 12 Nov 2001 11:57:45 -0800 (PST) (envelope-from aboba@internaut.com) Date: Mon, 12 Nov 2001 11:57:45 -0800 (PST) From: Bernard Aboba To: ietf-ppp@merit.edu Cc: gwz@cisco.com, handersson@rsasecurity.com Subject: comments on draft-josefsson-pppext-eap-tls-eap-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Section 3.1, second paragraph "Accordingly, it should not be used instead of the peer identity sent inside the TLS channel later on." From this sentence, it is not clear exactly what it "should not be used" for. In practice, the EAP-Identity/Response is put into the RADIUS User-Name attribute in the Access-Request and used in routing requests to the correct backend server. So if there is no Identity exchange, then termination of the EAP conversation must occur at the proxy. I don't think you want to require this. With EAP TLS, we required that the identity returned in the EAP Response be the same as the identity claimed in TLS, if both are present. In practice, if they were not the same, there is the possibility that authentication has been routed to the wrong backend server, so you wouldn't want to continue. Within PEAP, it would appear that there is the potential for multiple identities: the initial EAP Response Identity, possibly another EAP Response Identity inside the TLS channel, and possibly another identity included within an EAP exchange (e.g. EAP TLS has this). So you need to be clear on how these identities are to be processed and compared. Some thoughts: 1. The first EAP Response/Identity is typically placed inside the RADIUS User-Name attribute, and used to route the exchange to the backend authentication server. In PEAP, this identity is not authenticated, so you have no way of verifying it. 2. The second EAP Response/Identity inside the TLS channel is authenticated by the tunneled EAP method. I would recommend that this be checked against the first EAP Response/Identity, and if they don't match, then the authentication should be aborted. 3. Subsequent EAP authentications may occur within the tunnel. These may authenticate alternate identities (e.g. machine auth vs. user auth), and so those subsequent identities may not match the first two. Section 3.1, bullet 5. change "must NOT send any certificate request" to "MUST NOT send any certificate request." Section 3.1, paragraph after bullet 8. "Note that it is not until now that we deviate from the TLS EAP specifiation." Actually, the deviation occurs in bullet 5 -- in EAP TLS the authenticator SHOULD send a certificate request, and here it MUST NOT. Section 3.1, second paragraph after bullet 8 "This concludes the mutual authentication and upon success both authenticator and peer may generate any amount of new key material to be forwarded to the underlying transport." Actually, PEAP constitutes two one-way auths, not a single mutual authentication. In the TLS exchange, the Authenticator is authenticated via its certificate; in the second EAP method the client is authenticated (at a minimum). The statement about "new key material" is somewhat vague. Does this refer to the TLS master key? If so, this was derived prior to the tunneled EAP exchange. Or does it refer to the TLS session keys which are derived from the TLS master key? Or does it refer to an additional key generated within the tunneled EAP method? It is not clear which key is to be used here, and that could cause interoperability problems. The distinction is quite important, I think. If the key is the initial TLS master key, then posession of this key by a client (as proved in session resumption) does not prove the client was previously authenticated. It would be possible to obtain such a key after failing the tunneled authentication. If it represents the key derived in the tunneled EAP method, then only EAP methods deriving keys could be used with PEAP, which seems like an unnecessary restriction. So it seems that the term "new key" is not really appropriate here. Section 3.1, last paragraph. "It remains to be described what happens upon failures. In case the TLS negotiation has failed fatally (after the proper TLS Alert messages have been sent), an EAP-Failure message is transmitted within the TLS channel, in the second EAP handshake, after any EAP-Success and EAP-Failure messages has been successfully sent, the same type of packet should be send in the outer EAP channel as well." I would advocate that the same error strategy be used as in RFC 2716. Note that sending two EAP Failure or Success messages may not be feasible, since client state machines will terminate on the first Failure/Success message and these messages are not ACK'd. So how do you send the second message? There is may be no way to continue the EAP conversation after that point! In practice, this may be a case where you send the Success/Failure inside of the TLS tunnel, get a response of an EAP PEAP "start" message with null body, then have the backend server send a RADIUS Access Accept/Reject with an EAP-Message Success/Failure attribute inside. This lengthens the conversation by a round-trip, so it would be great to get around this somehow, but I can't see how off the top of my head right now. Section 6. I think you need to talk about the security issues involved in TLS session resumption. TLS resumption can occur based on the Authenticator's TLS session cache, which has no relationship to successful tunneled EAP auth. So if a PEAP client successfully resumes a session, this is NOT sufficient to allow access without another tunneled authentication. The client could have obtained a TLS master key, and then flunked subsequent tunneled EAP auth -- but would still be able to resume the TLS session, based on proving posession of the master key! So it seems to me that tunneled EAP needs to be done whether the TLS session was resumed or not. Also, because the TLS master key is derived between the endpoints and typically cannot be recovered from the TLS channel layer via an appropriate API call, resumption must occur by forwarding the authentication to the original backend authentication server. A proxy located nearby cannot handle the resumption unless was the endpoint in the original TLS conversation as well. From owner-ietf-ppp@merit.edu Tue Nov 13 12:50:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08266 for ; Tue, 13 Nov 2001 12:50:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B9800912A7; Tue, 13 Nov 2001 12:50:24 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EF7A912A8; Tue, 13 Nov 2001 12:50:24 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 72F23912A7 for ; Tue, 13 Nov 2001 12:50:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 584A65DD8F; Tue, 13 Nov 2001 12:50:23 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with SMTP id E4BA75DD8C for ; Tue, 13 Nov 2001 12:50:22 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Nov 13 12:45:06 EST 2001 Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA19368 for ; Tue, 13 Nov 2001 12:49:26 -0500 (EST) Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.11.6/8.8.7) id fADHnQA01722 for ietf-ppp@merit.edu; Tue, 13 Nov 2001 12:49:26 -0500 Date: Tue, 13 Nov 2001 12:49:26 -0500 From: Luca Salgarelli To: ietf-ppp@merit.edu Subject: draft-salgarelli-pppext-eap-ske-00.txt Message-ID: <20011113124926.C11944@bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Organization: Bell Laboratories Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi. We submitted a new ID relevant to this working group a while ago, but I haven't seen it announced on this mailing list. Since we would like to receive comments on it, here it goes. I apologize if the ID was indeed announced and I missed that e-mail. Regards Luca ID: draft-salgarelli-pppext-eap-ske-00.txt URL: http://www.ietf.org/internet-drafts/draft-salgarelli-pppext-eap-ske-00.txt Title: EAP-Shared Key Exchange (EAP-SKE): A Scheme for Authentication and Dynamic Key Exchange in 802.1X Networks Authors: L. Salgarelli, M. Buddhikot, J. Garay, S. Miller, U. Blumenthal, S. Patel, P. Dahl, D. Stanley, C. Carroll Abstract: This note describes two methods for authentication of Mobile Nodes (MN) and generation of per session, per node encryption keys, suitable for use at layer-2 in 802.1x networks (such as 802.11 wireless LANs). The methods apply to scenarios where a Mobile Node (MN) is in a foreign network such as public 802.3 network that uses Home-AAA and Foreign-AAA services. The methods assume that a pre-deployed cryptographically secure pre-shared key is present on the MN, and use of the 802.1X standard [1], Extensible Authentication Protocol (EAP) [2] messages, and RADIUS Authentication Servers. The first method offers a full set of security features, and requires the introduction of relatively minor changes to RADIUS and EAP. The second method is a simplified version of the first. It requires minimal modifications to existing RADIUS and EAP standards, but provides a lower level of security. The protocol can easily be extended to support the migration from RADIUS to DIAMETER [3]. From owner-ietf-ppp@merit.edu Wed Nov 14 21:30:23 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24485 for ; Wed, 14 Nov 2001 21:30:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C20D91272; Wed, 14 Nov 2001 21:30:00 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9F23912BA; Wed, 14 Nov 2001 21:29:59 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D1AD191272 for ; Wed, 14 Nov 2001 21:29:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id A8D5E5DDA6; Wed, 14 Nov 2001 21:29:58 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id C9B915DD91 for ; Wed, 14 Nov 2001 21:29:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id SAA71408; Wed, 14 Nov 2001 18:19:50 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 14 Nov 2001 18:19:50 -0800 (PST) From: Bernard Aboba To: ietf-ppp@merit.edu Cc: gwz@cisco.com Subject: Re: comments on draft-ietf-pppext-rfc2284bis-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Glen Zorn spake thusly: First page headers Change "Updates: RFC 2284" to "Obsoletes: RFC 2284" >>Proposed Resolution: Accept Section 1 I would really like to see the inclusion of some text allowing the encapsulation of EAP packets within EAP packets (a la PEAP), maybe after the paragraphs on sequential authentication. >>Since PEAP is just another EAP method, it would seem that no explicit language is required in the draft to enable its use. Section 2 Paragraph 5 Suggest changing "However, an initial Identity Request is not required, and MAY be bypassed in cases where the identity is presumed (leased lines, dedicated switch or dial-up ports, authentication via calling station identity or MAC address, etc.)." to "However, an initial Identity Request is not required, and MAY be bypassed in cases where the identity is presumed (leased lines, dedicated switch or dial-up ports, etc.) or obtained in another fashion (via calling station identity or MAC address, in the Name field of the MD5-Challenge Response, etc.)." >>Proposed solution: Accept Sections 2.1 & 2.2 I think that it would be a good idea to follow the l2tpext WG's lead and separate the PPP and 802.1 applications of EAP from the base protocol. Although the use of EAP with PPP is pretty well understood, 802.1X is still evolving. Furthermore, I think it likely that EAP will be used in other L2 contexts and I would like to avoid rewriting the EAP RFC again. >>It is indeed likely that EAP will be used in other L2 contexts (I am told Hiperlan2 will use EAP, and this has also been discussed in Bluetooth SIG). There are also L3 applications for EAP, such as PIC and BURP. So it seems reasonable to enable other documents to specify L2 or even may be L3 mappings for EAP. However, I don't know that this necessarily requires that this document remove the existing L2 mappings. >>Proposed resolution: discuss Section 3.1 In the paragraph on "Type", I find the sentence "Only one Type MUST be specified per EAP Request or Response." a little ambivalent. If only one Type MUST be specified, does that mean that more than one Type MAY be specified? I don't think so ;-). Suggest replacing with "A single Type MUST be specified for each EAP Request or Response." >>Proposed resolution: Accept Section 4. Paragraph 1 Since the term "authentication Type code" has not been defined above, suggest changing "The Nak Type MUST only be sent in response to a Request which uses an authentication Type code." to "The Nak Type MUST only be sent in response to a Request which uses an authentication Type code (i.e., Type > 3)." >>Proposed resolution: Accept Paragraph 2 Why bother w/forward references to another I-D? Suggest changing "All EAP implementations MUST support Types 1-4, which are defined in this document. Types 5 and 6 are defined in [4]. Follow-on RFCs will define additional EAP Types." to "All EAP implementations MUST support Types 1-4, which are defined in this document. Follow-on RFCs MAY define additional EAP Types." and deleting types 5 and 6 from the following list. >>Proposed resolution: Accept Section 4.3 Would it break backward compatability too badly to allow a list of single octet authentication types in a Nak? >>Proposed resolution: Discuss Section 4.4 This section points to RFC 1994 for details on how to do MD5-Challenge authentication. However, the specification of the use of the Identifier field in RFC 1994 is differentthat that described in this draft. For example, EAP allows for retransmission of MD5-Challenge Request packets while RFC 1994 states that both the Identifier and Challenge fields MUST change each time a Challenge (the CHAP equivalent of the MD5-Challenge Request packet) is sent. I think that a little clarifying text might be in order here. >>How about this? "The MD5-Challenge Type is analogous to the PPP CHAP protocol [3] (with MD5 as the specified algorithm). The Request contains a "challenge" message to the peer. A Response MUST be sent in reply to the Request. The Response MAY be either of Type 4 (MD5- Challenge) or Type 3 (Nak). The Nak reply indicates the peer's desired authentication mechanism Type. All EAP implementations MUST support the MD5-Challenge mechanism. Note that the use of the Identifier field in the MD5-Challenge Type is different from that described in RFC 1994 [3]. EAP allows for retransmission of MD5-Challenge Request packets while RFC 1994 states that both the Identifier and Challenge fields MUST change each time a Challenge (the CHAP equivalent of the MD5-Challenge Request packet) is sent." From owner-ietf-ppp@merit.edu Mon Nov 19 09:52:00 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02088 for ; Mon, 19 Nov 2001 09:52:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 293719125D; Mon, 19 Nov 2001 09:51:45 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB1769125E; Mon, 19 Nov 2001 09:51:44 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E71129125D for ; Mon, 19 Nov 2001 09:51:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id BFBBE5DDB8; Mon, 19 Nov 2001 09:51:43 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 118B55DDE8 for ; Mon, 19 Nov 2001 09:51:43 -0500 (EST) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAJEqNA02463 for ; Mon, 19 Nov 2001 16:52:23 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 19 Nov 2001 16:51:41 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 19 Nov 2001 16:51:41 +0200 Message-ID: From: henry.haverinen@nokia.com To: karlfox@columbus.rr.com Cc: ietf-ppp@merit.edu Subject: Request for slots in PPPEXT Salt Lake City meeting Date: Mon, 19 Nov 2001 16:51:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hello Karl, There seems to be a PPPEXT meeting in Salt Lake City..? I would like to have two presentation slots for the following drafts that have been submitted to the Internet Draft directories: 10 minutes for draft-arkko-pppext-eap-aka-01.txt Available at: http://www.piuha.net/~jarkko/publications/draft-arkko-pppext-eap-aka-01.txt Presented by Jari Arkko (Jari.Arkko@lmf.ericsson.se) or Jari Malinen (jmalinen@iprg.nokia.com) 5-10 minutes for draft-haverinen-pppext-eap-sim-02.txt Available at: http://www.cs.tut.fi/~haverinh/draft-haverinen-pppext-eap-sim-02.txt Presented by Jari Malinen Best regards, Henry Haverinen henry.haverinen@nokia.com From owner-ietf-ppp@merit.edu Wed Nov 21 06:33:10 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09276 for ; Wed, 21 Nov 2001 06:33:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E26539121F; Wed, 21 Nov 2001 06:32:47 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9BFE391269; Wed, 21 Nov 2001 06:32:47 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 754A59121F for ; Wed, 21 Nov 2001 06:32:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 49D215DDD4; Wed, 21 Nov 2001 06:32:46 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id AD71C5DDAF for ; Wed, 21 Nov 2001 06:32:45 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fALBWhC24358; Wed, 21 Nov 2001 12:32:43 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id fALBWhh09137; Wed, 21 Nov 2001 13:32:43 +0200 (EET) Message-ID: <3BFB90DB.364833B6@lmf.ericsson.se> Date: Wed, 21 Nov 2001 13:32:43 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: karlfox@columbus.rr.com Cc: henry.haverinen@nokia.com, ietf-ppp@merit.edu Subject: Re: Request for slots in PPPEXT Salt Lake City meeting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit >10 minutes for "EAP AKA Authentication" >(draft-arkko-pppext-eap-aka-01.txt) I'd like to suggest that we adopt this draft as an official item for this WG and make it a standards track RFC. AKA is expected to be quite widely available, and the backwards compatibility it has with GSM means that there are about 500M devices already that could potentially use it. Recent adoption of EAP on many fronts (IPSRA, WLAN, maybe Bluetooth, ...) would also indicate that there'd be many potential use cases among different types of devices from multiple vendors. Opinions? Jari From owner-ietf-ppp@merit.edu Wed Nov 21 07:01:30 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10125 for ; Wed, 21 Nov 2001 07:01:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AA6D891269; Wed, 21 Nov 2001 07:00:40 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 702BA91289; Wed, 21 Nov 2001 07:00:40 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4780191269 for ; Wed, 21 Nov 2001 07:00:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C91B5DDD1; Wed, 21 Nov 2001 07:00:39 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 50DA55DDAF for ; Wed, 21 Nov 2001 07:00:37 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10090; Wed, 21 Nov 2001 07:00:35 -0500 (EST) Message-Id: <200111211200.HAA10090@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-rfc2284bis-01.txt Date: Wed, 21 Nov 2001 07:00:35 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk, J. Vollbrecht, B. Aboba Filename : draft-ietf-pppext-rfc2284bis-01.txt Pages : 20 Date : 20-Nov-01 This document defines the Extensible Authentication Protocol (EAP), an authentication protocol which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery and re-transmission. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document obsoletes RFC 2284. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-pppext-rfc2284bis-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-ietf-pppext-rfc2284bis-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: <20011120151928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-rfc2284bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011120151928.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Wed Nov 21 12:51:06 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27281 for ; Wed, 21 Nov 2001 12:51:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 719AA91211; Wed, 21 Nov 2001 12:50:44 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BB6D91216; Wed, 21 Nov 2001 12:50:44 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D41FE91211 for ; Wed, 21 Nov 2001 12:50:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id B4AD55DD96; Wed, 21 Nov 2001 12:50:42 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 2B0025DD92 for ; Wed, 21 Nov 2001 12:50:42 -0500 (EST) Received: from ms.uab.ericsson.se. (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fALHoZC08120 for ; Wed, 21 Nov 2001 18:50:35 +0100 (MET) Received: from uabs31c015 (uabs31c015 [134.138.218.15]) by ms.uab.ericsson.se. (8.11.1/8.11.1/uab-3.6) with ESMTP id fALHoZ328892; Wed, 21 Nov 2001 18:50:35 +0100 (MET) Received: from uab.ericsson.se by uabs31c015 (8.9.3+Sun/client-1.3uab2) id SAA09426; Wed, 21 Nov 2001 18:50:31 +0100 (MET) Message-Id: <200111211750.SAA09426@uabs31c015> Date: Wed, 21 Nov 2001 07:00:35 -0500 From: Internet-Drafts@ietf.org Reply-To: =?iso-8859-1?Q?Mats_Bergstr=F6m?= Subject: I-D ACTION:draft-ietf-pppext-rfc2284bis-01.txt To: Mats Bergstrom Cc: ietf-ppp@merit.edu MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY="-2133890903-1691952160-1006365035=:15031" Content-Transfer-Encoding: BINARY Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu ---2133890903-1691952160-1006365035=:15031 Content-Type: TEXT/plain; charset=us-ascii A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk, J. Vollbrecht, B. Aboba Filename : draft-ietf-pppext-rfc2284bis-01.txt Pages : 20 Date : 20-Nov-01 This document defines the Extensible Authentication Protocol (EAP), an authentication protocol which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery and re-transmission. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document obsoletes RFC 2284. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-pppext-rfc2284bis-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-ietf-pppext-rfc2284bis-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. ---2133890903-1691952160-1006365035=:15031 Content-Type: APPLICATION/octet-stream; BOUNDARY=OtherAccess Content-Transfer-Encoding: BASE64 LS1PdGhlckFjY2Vzcw0KQ29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFs LWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwtc2VydmVyIjsNCglzZXJ2ZXI9 Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRleHQvcGxh aW4NCkNvbnRlbnQtSUQ6CTwyMDAxMTEyMDE1MTkyOC5JLURAaWV0Zi5vcmc+ DQoNCkVOQ09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1pZXRmLXBwcGV4dC1yZmMyMjg0YmlzLTAxLnR4dA0KDQotLU90aGVyQWNj ZXNzDQpDb250ZW50LVR5cGU6IE1lc3NhZ2UvRXh0ZXJuYWwtYm9keTsNCglu YW1lPSJkcmFmdC1pZXRmLXBwcGV4dC1yZmMyMjg0YmlzLTAxLnR4dCI7DQoJ c2l0ZT0iZnRwLmlldGYub3JnIjsNCglhY2Nlc3MtdHlwZT0iYW5vbi1mdHAi Ow0KCWRpcmVjdG9yeT0iaW50ZXJuZXQtZHJhZnRzIg0KDQpDb250ZW50LVR5 cGU6IHRleHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAxMTEyMDE1MTkyOC5J LURAaWV0Zi5vcmc+DQoNCi0tT3RoZXJBY2Nlc3MtLQ0K ---2133890903-1691952160-1006365035=:15031-- From owner-ietf-ppp@merit.edu Thu Nov 22 09:18:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15134 for ; Thu, 22 Nov 2001 09:18:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B4433912B3; Thu, 22 Nov 2001 09:18:15 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E81F912B6; Thu, 22 Nov 2001 09:18:15 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F059912B3 for ; Thu, 22 Nov 2001 09:18:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1230E5DDDC; Thu, 22 Nov 2001 09:18:14 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by segue.merit.edu (Postfix) with ESMTP id 3541E5DDD6 for ; Thu, 22 Nov 2001 09:18:13 -0500 (EST) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id fAMEI6f04352 for ; Thu, 22 Nov 2001 16:18:06 +0200 (EET) Received: (qmail 21989 invoked from network); 22 Nov 2001 14:18:05 -0000 Received: from unknown (HELO nikita.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 22 Nov 2001 14:18:05 -0000 Received: (from ltarkkal@localhost) by nikita.hel.fi.ssh.com (8.11.0/8.11.0) id fAMFJDI02507 for ietf-ppp@merit.edu; Thu, 22 Nov 2001 17:19:13 +0200 Date: Thu, 22 Nov 2001 17:19:12 +0200 From: Lauri Tarkkala To: IET pppext Subject: comments on draft-ietf-pppext-eap-srp-03.txt Message-ID: <20011122171912.A2491@nikita.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I was re-reading the draft on EAP SRP, and came across in my opinion a possibly dubious overloading of the NAK type. Below a quote from the relevant portions of the specification: >2.1. EAP SRP-SHA1 Packet Formats > > All EAP SRP-SHA1 authentication is driven by the authenticator > (server). The authenticatee (client) MUST NOT retransmit Response > messages, but SHOULD terminate the link if a Request is not received > within a reasonable time period. The authenticator SHOULD silently > ignore unexpected Response messages. The authenticatee MUST respond > using EAP Nak if any unknown Subtype or otherwise unacceptable mes- > sage is received. > > Rationale: > > Although the EAP Nak message is intended to signal only that a > given EAP Type is unknown to the authenticatee and that a > different Type should be used, its use here is still consistent > with that meaning. If the authenticator attempts to use a > subtype unknown to the authenticatee, then authentication using > EAP SRP-SHA1 is itself not possible, and another Type should be > tried. Consider now the case that the authenticatee is configured to attempt authentication using only EAP-SRP, and the authenticator is running an incompatible version and attempts to use a EAP-SRP subtype not recognized by the authenticatee. The authenticatee EAP-SRP implementation correctly recognizes the subtype as unsupported, and is going to respond with a proper "NAK" message, but as it stands, there is no way for it to inform the authenticator of this. It could send an EAP Nak with type "EAP-SRP" as the parameter, but unfortunately this would, for obvious reasons, not solve the problem. The only viable option is to let the authentication timeout, which is not IMHO desirable. The EAP protocol identifies authentication methods using only the "type" field. The protocol does not really offer any mechanisms for differentiating between incompatible versions of authentication methods. Indeed, if it did, the above scenario would not be a problem. For EAP-SRP to stay within this thinking, the trivial solution is to assign different EAP types to different versions of the EAP-SRP protocol. The trivial solutions that come to mind are: - Update the newest EAP draft to specify that a EAP NAK message of length 4 bytes (meaning that the Type-Data field is empty) represents a "I cannot authenticate with any method" signal from the authenticator. This seems to actually have been the intent, as RFC2284 states: > unacceptable to the peer. When sending a Nak in response to a > Request, the peer MAY indicate an alternative desired > authentication Type which it supports. An initial specification of Yet, later it specify the Type-Data field of the Nak-Reply message: > This field MUST contain a single octet indicating the desired > authentication type. The latest rfc2284bis drafts, have the same ambiguity. - Remove the use of the EAP Nak type from the EAP-SRP protocol, and assume that if a new revision is made, it will assume another EAP type. I feel that both "fixes" should be done. Lauri -- Lauri Tarkkala SSH Communications Security Corp From owner-ietf-ppp@merit.edu Thu Nov 22 10:35:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16732 for ; Thu, 22 Nov 2001 10:35:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 87B839122C; Thu, 22 Nov 2001 10:34:53 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BB5891231; Thu, 22 Nov 2001 10:34:53 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 558B09122C for ; Thu, 22 Nov 2001 10:34:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2ECBF5DDFA; Thu, 22 Nov 2001 10:34:52 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 57F705DDDC for ; Thu, 22 Nov 2001 10:34:51 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA87692; Thu, 22 Nov 2001 07:23:58 -0800 (PST) (envelope-from aboba@internaut.com) Date: Thu, 22 Nov 2001 07:23:58 -0800 (PST) From: Bernard Aboba To: Lauri Tarkkala Cc: IET pppext Subject: Re: comments on draft-ietf-pppext-eap-srp-03.txt In-Reply-To: <20011122171912.A2491@nikita.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > The trivial solutions that come to mind are: > > - Update the newest EAP draft to specify that a EAP NAK message > of length 4 bytes (meaning that the Type-Data field is empty) > represents a "I cannot authenticate with any method" signal > from the authenticator. > > This seems to actually have been the intent, as RFC2284 states: > > > unacceptable to the peer. When sending a Nak in response to a > > Request, the peer MAY indicate an alternative desired > > authentication Type which it supports. An initial specification of > > Yet, later it specify the Type-Data field of the Nak-Reply message: > > > This field MUST contain a single octet indicating the desired > > authentication type. > > The latest rfc2284bis drafts, have the same ambiguity. Yes, they do, and this should be fixed in RFC 2284bis. However, I'm not sure what is accomplished by allowing a "no types supported" message. All EAP implementations should be able to successfully negotiate at least one method - EAP-MD5. So "no types supported" would seem to be at variance with this. Wouldn't allowing a "no types supported" Nak in effect be removing the necessity of implementing MD5? Wouldn't this cause interoperability problems? Also, how would allowing a "no types supported" message address this particular problem? I'd note that this is not the only question that has arisen about the Nak Type. We have also had the suggestion that a Nak packet be able to contain multiple Type octets. > - Remove the use of the EAP Nak type from the EAP-SRP protocol, and assume > that if a new revision is made, it will assume another EAP type. I would agree with this suggestion. From owner-ietf-ppp@merit.edu Thu Nov 22 11:04:38 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17757 for ; Thu, 22 Nov 2001 11:04:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 16BAA91231; Thu, 22 Nov 2001 11:04:24 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCDC491232; Thu, 22 Nov 2001 11:04:23 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C45F591231 for ; Thu, 22 Nov 2001 11:04:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id AA2475DDEC; Thu, 22 Nov 2001 11:04:22 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by segue.merit.edu (Postfix) with ESMTP id CD4D05DDDC for ; Thu, 22 Nov 2001 11:04:21 -0500 (EST) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id fAMG4Kf05710 for ; Thu, 22 Nov 2001 18:04:20 +0200 (EET) Received: (qmail 11428 invoked from network); 22 Nov 2001 16:04:19 -0000 Received: from unknown (HELO nikita.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 22 Nov 2001 16:04:19 -0000 Received: (from ltarkkal@localhost) by nikita.hel.fi.ssh.com (8.11.0/8.11.0) id fAMH5ST02656; Thu, 22 Nov 2001 19:05:28 +0200 Date: Thu, 22 Nov 2001 19:05:27 +0200 From: Lauri Tarkkala To: Bernard Aboba Cc: IET pppext Subject: Re: comments on draft-ietf-pppext-eap-srp-03.txt Message-ID: <20011122190527.A2635@nikita.hel.fi.ssh.com> References: <20011122171912.A2491@nikita.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Thu, Nov 22, 2001 at 07:23:58AM -0800 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Thu, Nov 22, 2001 at 07:23:58AM -0800, Bernard Aboba wrote: > > Yet, later it specify the Type-Data field of the Nak-Reply message: > > > > > This field MUST contain a single octet indicating the desired > > > authentication type. > > > > The latest rfc2284bis drafts, have the same ambiguity. > > Yes, they do, and this should be fixed in RFC 2284bis. > > However, I'm not sure what is accomplished by allowing a "no types > supported" message. All EAP implementations should be able to > successfully negotiate at least one method - EAP-MD5. So "no types > supported" would seem to be at variance with this. I feel that EAP should allow an authenticatee to specify a policy for what protocols to use. If the user wishes to use only authentication protocols that provide strong protection for the authenticatee (such as EAP-SRP attempts to protect the secret passphrase) or ones that perform authenticated key-exchange, then this should be possible. I personally do think that requiring all implementations to support MD5-Challenge is a "good thing". Yet I do not think that all users will wish to use it, if better alternatives exist. > Wouldn't allowing a "no types supported" Nak in effect be removing the > necessity of implementing MD5? Wouldn't this cause interoperability > problems? Also, how would allowing a "no types supported" message address > this particular problem? The "no types supported" problem in this case arose from the fact that the authenticatee and authenticator implemented incompatible versions of a protocol with the same EAP type and the user's policy would not allow using a weaker protocol. My proposal for a "no types supported" Nak basically was for the reason that assuming that EAP authentiation types would start being incompatible (yet retain the same EAP Type values), then a mechanism for informing the server that "I do not know how to proceed", would be good, as the other option is for the client to let the authentication time out. This thinking followed from the EAP-SRP draft. The motivation for a "no types supported" Nak is, in a sense, a fatal interoperability problem. The reason for this may very well be, that the authenticatee is not complying with the spec, and has not implemented MD5, as you suggest above. The best alternative (obviously) is to keep the EAP Types unambgiuously specified, but I fear that this may not happen in practice. Lauri -- Lauri Tarkkala SSH Communications Security Corp From owner-ietf-ppp@merit.edu Thu Nov 22 12:04:21 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18921 for ; Thu, 22 Nov 2001 12:04:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DB6DB91231; Thu, 22 Nov 2001 12:03:59 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB54491233; Thu, 22 Nov 2001 12:03:59 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AF4B591231 for ; Thu, 22 Nov 2001 12:03:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 98CCB5DE03; Thu, 22 Nov 2001 12:03:58 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id DC80F5DE02 for ; Thu, 22 Nov 2001 12:03:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA87849; Thu, 22 Nov 2001 08:52:33 -0800 (PST) (envelope-from aboba@internaut.com) Date: Thu, 22 Nov 2001 08:52:33 -0800 (PST) From: Bernard Aboba To: Lauri Tarkkala Cc: IET pppext Subject: Re: comments on draft-ietf-pppext-eap-srp-03.txt In-Reply-To: <20011122190527.A2635@nikita.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > The best alternative (obviously) is to keep the EAP Types > unambgiuously specified, but I fear that this may not > happen in practice. I think that this is indeed a better alternative, and the entire "versioning" issue is best avoided by allocating new EAP Types. The one potential wrinkle with this could occur if we start nearing exhaustion of the EAP type space. From owner-ietf-ppp@merit.edu Fri Nov 23 06:07:30 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16512 for ; Fri, 23 Nov 2001 06:07:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4015A91236; Fri, 23 Nov 2001 06:07:17 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10BE691238; Fri, 23 Nov 2001 06:07:16 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2432F91236 for ; Fri, 23 Nov 2001 06:07:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF4E95DD98; Fri, 23 Nov 2001 06:07:15 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 32B495DD90 for ; Fri, 23 Nov 2001 06:07:15 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fANB79C12820; Fri, 23 Nov 2001 12:07:09 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id fANB77h24835; Fri, 23 Nov 2001 13:07:07 +0200 (EET) Message-ID: <3BFE2DDB.81307DC1@lmf.ericsson.se> Date: Fri, 23 Nov 2001 13:07:07 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: Lauri Tarkkala , IET pppext Subject: Re: comments on draft-ietf-pppext-eap-srp-03.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit >However, I'm not sure what is accomplished by allowing a "no types >supported" message. All EAP implementations should be able to >successfully negotiate at least one method - EAP-MD5. So "no types >supported" would seem to be at variance with this. Support and allowed use may be different issues. It could be that policy dictates you only allow FOOBAR, not MD5 even if you perhaps support it in the code base. Jari From owner-ietf-ppp@merit.edu Fri Nov 23 11:28:53 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19078 for ; Fri, 23 Nov 2001 11:28:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C37A29123E; Fri, 23 Nov 2001 11:28:40 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 916909123F; Fri, 23 Nov 2001 11:28:40 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A389E9123E for ; Fri, 23 Nov 2001 11:28:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A2755DE10; Fri, 23 Nov 2001 11:28:39 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B23A25DD90 for ; Fri, 23 Nov 2001 11:28:38 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA89525; Fri, 23 Nov 2001 08:17:41 -0800 (PST) (envelope-from aboba@internaut.com) Date: Fri, 23 Nov 2001 08:17:41 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: Lauri Tarkkala , IET pppext Subject: Re: comments on draft-ietf-pppext-eap-srp-03.txt In-Reply-To: <3BFE2DDB.81307DC1@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > Support and allowed use may be different issues. It > could be that policy dictates you only allow FOOBAR, > not MD5 even if you perhaps support it in the code > base. If you only allow FOOBAR -- then you can Nak and indicate that type, no? From owner-ietf-ppp@merit.edu Mon Nov 26 10:31:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03338 for ; Mon, 26 Nov 2001 10:31:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1532F91237; Mon, 26 Nov 2001 10:30:43 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D745F91241; Mon, 26 Nov 2001 10:30:42 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC82791237 for ; Mon, 26 Nov 2001 10:30:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E1A15DDA9; Mon, 26 Nov 2001 10:30:41 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with SMTP id D5EC45DD91 for ; Mon, 26 Nov 2001 10:30:40 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Nov 26 10:25:42 EST 2001 Received: from valjean.dnrc.bell-labs.com (valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA18492; Mon, 26 Nov 2001 10:30:12 -0500 (EST) Subject: PPPEXT agenda? From: Luca Salgarelli To: Karl Fox Cc: ietf-ppp@merit.edu Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.2 (Preview Release) Date: 26 Nov 2001 10:30:12 -0500 Message-Id: <1006788612.21466.0.camel@valjean> Mime-Version: 1.0 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hello Karl. I was wondering if PPPEXT is going to meet in Salt Lake City. If so, I would like to request a 10 minutes slot to present draft-salgarelli-pppext-eap-ske-00.txt http://www.ietf.org/internet-drafts/draft-salgarelli-pppext-eap-ske-00.txt Is there a draft agenda we can refer to? Thanks Luca From owner-ietf-ppp@merit.edu Tue Nov 27 06:02:01 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18757 for ; Tue, 27 Nov 2001 06:02:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 208CD91229; Tue, 27 Nov 2001 06:01:36 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE8D491255; Tue, 27 Nov 2001 06:01:35 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8468491229 for ; Tue, 27 Nov 2001 06:01:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9859E5DDBD; Tue, 27 Nov 2001 06:01:32 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 2DB195DD96 for ; Tue, 27 Nov 2001 06:01:32 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18665; Tue, 27 Nov 2001 06:01:28 -0500 (EST) Message-Id: <200111271101.GAA18665@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-ppp-over-aal2-class-01.txt Date: Tue, 27 Nov 2001 06:01:28 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Class Extensions for PPP over AAL2 Author(s) : B. Thompson, B. Buffam, T. Koren Filename : draft-ietf-pppext-ppp-over-aal2-class-01.txt Pages : Date : 26-Nov-01 PPP over AAL2 [1] defines the encapsulation that allows a PPP session to be transported over an ATM virtual circuit using the AAL2 adaptation layer. Using AAL2 as an adaptation layer for PPP transport over ATM provides a bandwidth efficient transport for IP applications that generate small packets. An example IP application that generates small packets is RTP encapsulated voice (Voice over IP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-ppp-over-aal2-class-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-pppext-ppp-over-aal2-class-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-ietf-pppext-ppp-over-aal2-class-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: <20011126102012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-class-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-ppp-over-aal2-class-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011126102012.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Tue Nov 27 06:02:33 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18898 for ; Tue, 27 Nov 2001 06:02:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 91B0691260; Tue, 27 Nov 2001 06:01:58 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF49891258; Tue, 27 Nov 2001 06:01:49 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 37F0791255 for ; Tue, 27 Nov 2001 06:01:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E3F55DDBD; Tue, 27 Nov 2001 06:01:42 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id A77145DD96 for ; Tue, 27 Nov 2001 06:01:41 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18691; Tue, 27 Nov 2001 06:01:37 -0500 (EST) Message-Id: <200111271101.GAA18691@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-ppp-over-aal2-02.txt Date: Tue, 27 Nov 2001 06:01:37 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP over AAL2 Author(s) : B. Thompson, B. Buffam, T. Koren Filename : draft-ietf-pppext-ppp-over-aal2-02.txt Pages : Date : 26-Nov-01 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Adaptation Layer 2 (AAL2) for framing PPP encapsulated packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-ppp-over-aal2-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-pppext-ppp-over-aal2-02.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-ietf-pppext-ppp-over-aal2-02.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: <20011126102024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-ppp-over-aal2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011126102024.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Fri Nov 30 16:07:07 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06940 for ; Fri, 30 Nov 2001 16:07:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C24639129E; Fri, 30 Nov 2001 16:05:22 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B76F912A0; Fri, 30 Nov 2001 16:05:22 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B3ED9129E for ; Fri, 30 Nov 2001 16:05:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id E58B45DDCE; Fri, 30 Nov 2001 16:05:18 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from karl-s-laptop (dhcp93125084.columbus.rr.com [24.93.125.84]) by segue.merit.edu (Postfix) with ESMTP id 9A7845DD98 for ; Fri, 30 Nov 2001 16:05:18 -0500 (EST) Received: from [127.0.0.1] by karl-s-laptop (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Fri, 30 Nov 2001 16:04:43 -0500 Message-Id: <4.3.2.7.2.20011130101036.04b29970@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Nov 2001 16:04:38 -0500 To: ietf-ppp@merit.edu From: Karl Fox Subject: Agenda for 52nd IETF PPPEXT meeting Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Point-to-Point Protocol Extensions Working Group (PPPEXT) TUESDAY, December 11 at 1700-1800 ================================= CHAIR: Karl Fox AGENDA: Extensible Authentication Protocol (EAP) Bernard Aboba [10 minutes] Protected Extensible Authentication Protocol (PEAP) Glen Zorn [5 minutes] EAP-Shared Key Exchange (EAP-SKE): A Scheme for Authentication and Dynamic Key Exchange in 802.1X Networks Luca Salgarelli [10 minutes] EAP AKA Authentication Jari Arkko Jari Malinen [10 minutes] EAP SIM Authentication Jari Malinen [5 minutes] IP Header Compression over PPP Tmima Koren [5 minutes] EAP Tunneled TLS Authentication Protocol (EAP-TTLS) Paul Funk [15 minutes]