From eap-admin@frascone.com Mon Sep 1 04:58:14 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02423 for ; Mon, 1 Sep 2003 04:58:13 -0400 (EDT) Received: (qmail 24159 invoked by uid 507); 1 Sep 2003 08:57:07 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 1 Sep 2003 08:57:06 -0000 Delivered-To: eap@frascone.com Received: (qmail 24068 invoked by uid 507); 1 Sep 2003 08:56:10 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 1 Sep 2003 08:56:08 -0000 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 01 Sep 2003 02:07:05 -0700 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h818tdCb026599; Mon, 1 Sep 2003 01:55:39 -0700 (PDT) Received: from gwzw2k (sjc-vpn3-678.cisco.com [10.21.66.166]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id BAA15292; Mon, 1 Sep 2003 01:55:38 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Bernard Aboba'" , Subject: RE: [eap] Proposed resolution to Issue 167: Cleartext Passwords Organization: Cisco Systems Message-ID: <060501c37066$ce764b60$909c4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Importance: Normal Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 1 Sep 2003 01:55:04 -0700 X-Virus-Scanned: by AMaViS 0.3.12 Content-Transfer-Encoding: 7bit Bernard Aboba writes: > The text of Issue 167 is enclosed below. The proposed resolution is > as follows: > > Proposed fix: > In Section 5.5, add to the end of the "Description" paragraph: > > "The EAP OTP method is intended for use with the One-Time Password > system only, and MUST NOT be used to provide support for cleartext > passwords." > > In Section 5.6, add to the end of the "Description" paragraph: > > "The EAP GTC method is intended for use with the Token Cards > supporting challenge/response authentication and MUST NOT be used to > provide support for cleartext passwords in the absence of a protected > tunnel with server authentication." So, is it correct to surmise that SecurID cards are not supported by EAP-GTC? > > Add Section 7.14: > > "7.14 Cleartext Passwords > > EAP does not support cleartext password authentication. This > ommission ^^^^^^^^^ omission > is intentional. Where EAP is carried over physically > insecure lower layers, including wireless LANs [IEEE80211] or the > Internet, use of cleartext passwords would allow the password to be > captured by an attacker with access to the lower layer. > > Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not > provide confidentiality, even where the lower layer is physically > secure, EAP frames may be subsequently encapsulated for transport > over the Internet where they may be captured by an attacker. > > As a result, cleartext passwords cannot be securely used > within EAP, except where encapsulated within a protected > tunnel with server authentication." I think that these three paragraphs also apply to some (if not all) token card passcodes, as well as EAP-MD5/CHAP. Of course, the passcode or hash can only be used once, but... > > --------------------------------------------------------------- > Issue 167: Cleartext Passwords in EAP > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: 8/14/2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-August/001599.html > Document: RFC2284bis Comment type: T > Priority: S > Section: 5.5, 5.6 > Rationale/Explanation of issue: > > Reading Section 5.5 and 5.6, it is not made crystal clear that the > EAP OTP and GTC methods are not intended to provide support for > cleartexst passwords. > > In Section 5.5, add to the end of the "Description" paragraph: > > "The EAP OTP method is intended for use with the One-Time Password > system only, and MUST NOT be used to provide support for cleartext > passwords." > > In Section 5.6, add to the end of the "Description" paragraph: > > "The EAP GTC method is intended for use with the Token Cards > supporting challenge/response authentication and MUST NOT be used to > provide support for cleartext passwords." > > [Pasi Eronen] > Hi, > > GTC can also be used with PEAP/TTLS to support password databases > that store a one-way hash of the password. When used this way, it's > not that insecure either (not worse than e.g. SSH). This use is > mentioned e.g. in > http://www.ilabs.interop.net/WLAN_Sec/Inner_Auth-lv03.pdf > > I think it's safe to assume that in the absence of some > other solution, people will use GTC for this with IKEv2 > as well. > > This is probably not such a bad idea in many cases, > since the alternative is to store the password (or > password-equivalent) in clear (deploying SRP or > something similar doesn't seem realistic any time soon). > > So, perhaps something like "The EAP GTC method MUST NOT > be used to provide support for cleartext passwords in the absence of > a protected tunnel with server authentication, such as PEAP or > IKEv2." would be sufficient? > > [BA] Several problems with this: > > a. On the AAA server side, protocols such as RADIUS do not mandate > confidentiality, and there is no support for "hiding" of the > EAP-Message attribute in the way that the User-Password attribute is > hidden. That means that any cleartext password sent via an EAP > method will be exposed on the wire from the NAS to the RADIUS server. > Since protocols such as EAP TTLS support "early termination" where > the tunnel is terminated on a different server (e.g. a proxy) than > the final exchange, this results in a cleartext password sent over a > portion of the path. > > [Joe Salowey] Even worse the intemediaries/NAS know the password. > However it is possible to deploy PEAP and TTLS so the protection is > all the way to the validating server. > > b. Even if the RADIUS User-Password attribute is used, this creates a > number of vulnerabilities, including known plaintext attacks. If the > Request Authenticator repeats on any NAS with the same shared secret > an attacker would potentially be able to crack the User-Password > attribute, which is encrypted with a stream cipher dependent only on > the shared secret and the RA. > > [Joe Salowey] I completely agree. > > The introduction of cleartext passwords into EAP therefore represents > a substantial security vulnerability -- and one which was > purposefully left out of RFC 2284. > > [Joe Salowey] While I would rather not see cleartext passwords, I'm > not sure that this represent a substantial security vulnerability if > deployed properly. In this case that would be in a server side > authenticated tunnel such as (TTLS/PEAP) that extends all the way to > the EAP server validating the password. This was not available when > 2284 was concieved. If you are going to advocate the use of passwords > you're protected tunel must be server authenticated and extend all > the way to the AAA that does the password validation. > Intermediaries/NASes should never see the password. Specifing that > EAP-OTP and EAP-GTC should not be used for cleartext passwords is > good because they can be used without PEAP/TTLS. > > I think it is up to PEAP/TTLS to define how and if clear text > passwords may be used within these tunnels and can define specific > mechanisms to do this. If they do allow this then they should > specify that the that the protected tunnel MUST extend all the way to > the EAP-Server that validates the passwords and authenticates this > server to the client. Tunnel client MUST NOT send a cleartext > password unless it has authenticated the EAP-Server and has > determined that it is authorized to receive the password. > _______________________________________________ eap mailing list > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From diameter-admin@frascone.com Mon Sep 1 06:10:35 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03477 for ; Mon, 1 Sep 2003 06:10:34 -0400 (EDT) Received: (qmail 28384 invoked by uid 507); 1 Sep 2003 10:03:38 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 1 Sep 2003 10:03:36 -0000 Date: Mon, 01 Sep 2003 05:03:36 -0500 Message-ID: <20030901100336.27653.23938.Mailman@wolverine> Subject: frascone.com mailing list memberships reminder From: mailman-owner@gw.frascone.com To: eap-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: diameter-admin@frascone.com Errors-To: diameter-admin@frascone.com X-BeenThere: diameter@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk X-Virus-Scanned: by AMaViS 0.3.12 This is a reminder, sent out once a month, about your frascone.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, eap-request@frascone.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@mail.frascone.com. Thanks! Passwords for eap-archive@lists.ietf.org: List Password // URL ---- -------- eap@frascone.com ohweow http://mail.frascone.com/mailman/options/eap/eap-archive%40lists.ietf.org From eap-admin@frascone.com Mon Sep 1 12:00:26 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08784 for ; Mon, 1 Sep 2003 12:00:24 -0400 (EDT) Received: (qmail 19309 invoked by uid 507); 1 Sep 2003 15:59:08 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 1 Sep 2003 15:59:06 -0000 Delivered-To: eap@frascone.com Received: (qmail 19235 invoked by uid 507); 1 Sep 2003 15:58:10 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 1 Sep 2003 15:58:08 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h81FQRa16193; Mon, 1 Sep 2003 08:26:28 -0700 From: Bernard Aboba To: Glen Zorn cc: eap@frascone.com Subject: RE: [eap] Proposed resolution to Issue 167: Cleartext Passwords In-Reply-To: <060501c37066$ce764b60$909c4104@amer.cisco.com> Message-ID: References: <060501c37066$ce764b60$909c4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 1 Sep 2003 08:26:27 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 > So, is it correct to surmise that SecurID cards are not supported by > EAP-GTC? EAP Type 15 has been assigned to "RSA Security SecurID EAP" and EAP Type 32 has been assigned to "SecurID EAP" according to: http://www.iana.org/assignments/ppp-numbers So it would appear that SecurID has two EAP Types assigned to it. > I think that these three paragraphs also apply to some (if not all) > token card passcodes, as well as EAP-MD5/CHAP. Of course, the passcode > or hash can only be used once, but... I think what distinguishes a "cleartext password" is that once obtained, it can be reused to gain subsequent access. Where the passcode or hash can only be used once, or where a response must be computed based on a random challenge it is necessary to do an offline attack to obtain the underlying long-term secret. That is indeed a risk, but I believe it's covered by including "Dictionary Attack Resistance" as one of the security claims. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 3 02:21:02 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26795 for ; Wed, 3 Sep 2003 02:20:59 -0400 (EDT) Received: (qmail 29199 invoked by uid 507); 3 Sep 2003 06:20:12 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 3 Sep 2003 06:20:08 -0000 Delivered-To: eap@frascone.com Received: (qmail 29047 invoked by uid 507); 3 Sep 2003 06:18:52 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 3 Sep 2003 06:18:50 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h835l9f17851 for ; Tue, 2 Sep 2003 22:47:09 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] [Issue] Changes to EAP methods Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 2 Sep 2003 22:47:09 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 ---------- Forwarded message ---------- Date: Wed, 3 Sep 2003 08:09:02 +0300 (IDT) From: Hugo Krawczyk To: aboba@internaut.com Subject: ipsec story Hi Bernard, a week ago I sent the attached msg to the ipsec list in rleation to the on-going discussion on whether to prohibit non-kg methods. I received no response in the list and probably rightly so since this issue belongs more to the eap wg than ipsec. Is there any reason why eap could not standarized the proposed "context" field? Or do you see any reason why this wouldn't be a simple and practical solution to the mitm problem? Your feedback would be much appreciated. Hugo ---------- Forwarded message ---------- Date: Tue, 26 Aug 2003 07:12:43 +0300 (IDT) From: Hugo Krawczyk To: Jari Arkko Cc: Theodore Ts'o , IPsec WG Subject: Re: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2 issues) On Wed, 20 Aug 2003, Jari Arkko wrote: > Theodore Ts'o wrote: > > So given this, I propose that we open a 48-hour discussion on this > > issue.Should we (a) say nothing about non-kg types, thus implicitly > > allowing them, (b) specify that vendors SHOULD NOT use non-kg EAP > > types, or (c) specify that vendors MUST NOT use non-kg EAP types? > > I'd prefer very much (c), but can live with (b). > > I think (c) is the best match to IKEv2's secure design. > Weknow the MITM problem exists, and we know how to avoid > it. According to the Bernard's method and RADIUS server > information, we don't appear to have to suffer too much > from choosing the secure approach... > > --Jari Let me suggest that kg vs. non-kg should not be the issue here. For this let me re-iterate a proposal I made in the past (in public and private forums), namely, that EAP should add a new field called "context" for all its methods. The value of "context" will be a protocol identifier (or some other IANA generated value) that will indicate the context in which the authentication method used. For example, when run as part of 802.xy the context will indicate an identifier pointing to 802.xy, when run as part of some legacy application the context will be set accordingly, and when run as part of ikev2 the context field will point to "ikev2", etc. By doing so, ANY CHALLENGE-RESPONSE EAP mechanism (either key-genrating or not) can be immunized against the type of mitm attacks we are discussing. Indeed, by including the "context" field under the information being authenticated by the EAP method the whole mitm issue is solved! This of course is not a sufficient solution for truly-legacy authentication methods (which do not include this context field) but neither are kg methods part of this "true legacy" systems. Otoh, ALL legacy methods can be trivially sanitized (against "credential abusing" mitm attacks) by simply including the context under the authentication. This is much simpler (and architecturally correct, and cryptographically sound, and much harder to misdeign!) than key-generating methods. (The only method not saved by this addition is the simple user name/passwd transmission; however for this protocol there is no way to make it right: if it's run outside a tunnel then the passwd is available to the attacker anyway) Moreover, recent msgs from the EAP experts (Jari and Bernard) suggested that truly-legacy is not an issue since most systems are upgrading to support newer methods (something they have to do anyway to enjoy the benefits of kg methods).. If that's the case, then why not standarize this "context" field as part of EAP and put this (irritating) mitm issue to rest forever? Note that if such a field existed already we could have avoided the additional AUTH fields in IKEv2-EAP. Not only this would have been a better solution in IKEv2 but a better solution for ALL situations where this mitm issues arise. I claim that resorting to key-generating protocols for solving this problems is: (1) overkill: the tunnel protocols (such as IKEv2) generate their own keys and trust those better than the "imported" keys from the underlying EAP method (2) complex and prone to design flaws: as we witnessed in IKEv2 there was a need to add the additional AUTH fields to multiple msgs since one of the peers (the initiator, I believe) cannot predict which one is the last msg in the protocol, and different methods may generate the needed key at different stages of the protocol run. Moreover, it was not really clear which key from the EAP to take for producing these additional AUTH values (and, as we learn from the recent posting to this lisr, these are not the "right keys" from the standarized EAP perspective). [This is indeed a very dangerous aspect of the "key binding" techniques suggested for EAP: you need to make absolutely sure that the key you use in the binding is NOT used for other purposes.] The "capital sin" of the proposed EAP "tunnel binding" methods is its layer violation (from which all the above defects follow): a forced (blind) marriage that may not be expected to produce happy children :) That is what the "context" method tries to avoid. Now, if I am misunderstanding the problem or the "rules of the EAP game", please correct me. Hugo PS: Key-genrating EAP methods may have other well-thought purposes (for example, establishing a secure session rather than simply authenticating the session initiation), but this does no tmean that they add any value (relative to authentication-only protocols) in the case of IKEv2 or other (well designed) tunnel methods. > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 3 09:15:59 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01614 for ; Wed, 3 Sep 2003 09:15:57 -0400 (EDT) Received: (qmail 16742 invoked by uid 507); 3 Sep 2003 13:14:06 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 3 Sep 2003 13:14:05 -0000 Delivered-To: eap@frascone.com Received: (qmail 16655 invoked by uid 507); 3 Sep 2003 13:12:53 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 3 Sep 2003 13:12:51 -0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h83DCiB25051 for ; Wed, 3 Sep 2003 16:12:46 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Sep 2003 16:12:43 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 3 Sep 2003 16:12:43 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 3 Sep 2003 16:12:43 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 3 Sep 2003 16:12:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] [Issue] Changes to EAP methods Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222DF@esebe023.ntc.nokia.com> Thread-Topic: [eap] [Issue] Changes to EAP methods Thread-Index: AcNx6W2V/eDoPqW6TnWKNPyc/ePS+wALlwEA From: To: , X-OriginalArrivalTime: 03 Sep 2003 13:12:42.0565 (UTC) FILETIME=[0EDF7750:01C3721D] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 3 Sep 2003 16:12:42 +0300 X-Virus-Scanned: by AMaViS 0.3.12 Content-Transfer-Encoding: quoted-printable Hugo, It seems that your message to the ipsec list disappeared=20 somewhere (Ted said that several messages have went missing=20 recently). At least it's not in the VPNC archives of the list. Regarding your suggestion for including a "context identifier"=20 in EAP methods: this has been suggested before (e.g. Jose=20 Puthenkulam's Internet-draft about the "binding problem").=20 Indeed, it would fix the MITM problem for methods such as=20 MD5-Challenge (CHAP). However, it's not sufficient for mutually authenticating EAP=20 methods (all of which generate keys, as far as I know). The=20 AUTH payloads (based on EAP-generated key) would still be=20 necessary to prevent a different MITM attack. Consider, for instance, EAP-AKA. With current IKEv2 spec,=20 the client can authenticate the server purely using AKA. It doesn't have to use certificates at any point (it can use the server's certificate to get some extra assurance that it's talking to the right party, though). If the=20 EAP-based AUTH payloads were removed, the server=20 authentication would be based only on the certificates, and any AKA information would be discarded (and thus we=20 would lose much of the "extensibility" of EAP). So, given that about the only EAP method helped by the "context=20 identifier" would be MD5-Challenge, I don't think it's worth=20 doing (it wouldn't solve the problems with OTP or GTC, and it's not needed for key generating methods). Best regards, Pasi ---------- Forwarded message ---------- Date: Wed, 3 Sep 2003 08:09:02 +0300 (IDT) From: Hugo Krawczyk To: aboba@internaut.com Subject: ipsec story Hi Bernard, a week ago I sent the attached msg to the ipsec list in rleation to the on-going discussion on whether to prohibit non-kg methods. I received no response in the list and probably rightly so since this issue belongs more to the eap wg than ipsec. Is there any reason why eap could not standarized the proposed "context" field? Or do you see any reason why this wouldn't be a simple and practical solution to the mitm problem? Your feedback would be much appreciated. Hugo > ---------- Forwarded message ---------- > Date: Tue, 26 Aug 2003 07:12:43 +0300 (IDT) > From: Hugo Krawczyk > To: Jari Arkko > Cc: Theodore Ts'o , IPsec WG > Subject: Re: EAP-IKEv2 MITM prevention (Was: Re: The=20 > remaining IKEv2 issues) >=20 > On Wed, 20 Aug 2003, Jari Arkko wrote: >=20 > > Theodore Ts'o wrote: >=20 > > > So given this, I propose that we open a 48-hour discussion on=20 > > > this issue.Should we (a) say nothing about non-kg types, thus=20 > > > implicitly allowing them, (b) specify that vendors SHOULD NOT=20 > > > use non-kg EAP types, or (c) specify that vendors MUST NOT=20 > > > use non-kg EAP types? > > > > I'd prefer very much (c), but can live with (b). > > > > I think (c) is the best match to IKEv2's secure design. > > Weknow the MITM problem exists, and we know how to avoid > > it. According to the Bernard's method and RADIUS server > > information, we don't appear to have to suffer too much > > from choosing the secure approach... > > > > --Jari >=20 > Let me suggest that kg vs. non-kg should not be the issue here. > > For this let me re-iterate a proposal I made in the past (in public > and private forums), namely, that EAP should add a new field called > "context" for all its methods. The value of "context" will be a > protocol identifier (or some other IANA generated value) that will > indicate the context in which the authentication method used. For > example, when run as part of 802.xy the context will indicate an > identifier pointing to 802.xy, when run as part of some legacy > application the context will be set accordingly, and when run as > part of ikev2 the context field will point to "ikev2", etc. > > By doing so, ANY CHALLENGE-RESPONSE EAP mechanism (either > key-genrating or not) can be immunized against the type of mitm > attacks we are discussing. Indeed, by including the "context" field > under the information being authenticated by the EAP method the > whole mitm issue is solved! > > This of course is not a sufficient solution for truly-legacy > authentication methods (which do not include this context field) but > neither are kg methods part of this "true legacy" systems. Otoh, > ALL legacy methods can be trivially sanitized (against "credential > abusing" mitm attacks) by simply including the context under the > authentication. This is much simpler (and architecturally correct, > and cryptographically sound, and much harder to misdeign!) than > key-generating methods. (The only method not saved by this addition > is the simple user name/passwd transmission; however for this > protocol there is no way to make it right: if it's run outside a > tunnel then the passwd is available to the attacker anyway) >=20 > Moreover, recent msgs from the EAP experts (Jari and Bernard) > suggested that truly-legacy is not an issue since most systems are > upgrading to support newer methods (something they have to do anyway > to enjoy the benefits of kg methods).. If that's the case, then why > not standarize this "context" field as part of EAP and put this > (irritating) mitm issue to rest forever? >=20 > Note that if such a field existed already we could have avoided the > additional AUTH fields in IKEv2-EAP. Not only this would have been > a better solution in IKEv2 but a better solution for ALL situations > where this mitm issues arise. I claim that resorting to > key-generating protocols for solving this problems is: > > (1) overkill: the tunnel protocols (such as IKEv2) generate their > own keys and trust those better than the "imported" keys from the > underlying EAP method >=20 > (2) complex and prone to design flaws: as we witnessed in IKEv2 > there was a need to add the additional AUTH fields to multiple msgs > since one of the peers (the initiator, I believe) cannot predict > which one is the last msg in the protocol, and different methods may > generate the needed key at different stages of the protocol > run. Moreover, it was not really clear which key from the EAP to > take for producing these additional AUTH values (and, as we learn > from the recent posting to this lisr, these are not the "right keys" > from the standarized EAP perspective). >=20 > [This is indeed a very dangerous aspect of the "key binding" > techniques suggested for EAP: you need to make absolutely sure that > the key you use in the binding is NOT used for other purposes.] >=20 > The "capital sin" of the proposed EAP "tunnel binding" methods is > its layer violation (from which all the above defects follow): a > forced (blind) marriage that may not be expected to produce happy > children :) That is what the "context" method tries to avoid. >=20 > Now, if I am misunderstanding the problem or the "rules of the EAP > game", please correct me. >=20 > Hugo >=20 > PS: Key-genrating EAP methods may have other well-thought purposes > (for example, establishing a secure session rather than simply > authenticating the session initiation), but this does no tmean that > they add any value (relative to authentication-only protocols) in > the case of IKEv2 or other (well designed) tunnel methods. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 3 13:08:35 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21937 for ; Wed, 3 Sep 2003 13:08:35 -0400 (EDT) Received: (qmail 27509 invoked by uid 507); 3 Sep 2003 17:07:06 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 3 Sep 2003 17:07:04 -0000 Delivered-To: eap@frascone.com Received: (qmail 27464 invoked by uid 507); 3 Sep 2003 17:06:10 -0000 Received: from fw2.gdm.de (193.108.184.154) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 3 Sep 2003 17:06:08 -0000 Received: by fw2.gdm.de (8.11.6p2/8.11.6) id h83H66524396 for eap@frascone.com; Wed, 3 Sep 2003 19:06:06 +0200 (CEST) Received: (from localhost) by fw2.gdm.de (MSCAN) id 2/fw2.gdm.de/smtp-gw/mscan; Wed Sep 3 19:06:06 2003 From: Hubert.Ertl@de.gi-de.com To: eap@frascone.com Message-ID: X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0.1CF1|March 04, 2003) at 03.09.2003 19:04:42 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Subject: [eap] Hubert Ertl/GDM/GuD is out of the office. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 3 Sep 2003 19:04:47 +0200 X-Virus-Scanned: by AMaViS 0.3.12 Content-Transfer-Encoding: quoted-printable Ich werde ab 02.09.2003 nicht im B=FCro sein. Ich kehre zur=FCck am 05.09.2003. I will read my email during my absence and will respond to your messag= e when I return on September 5th.= _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 5 09:03:25 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18907 for ; Fri, 5 Sep 2003 09:03:24 -0400 (EDT) Received: (qmail 32178 invoked by uid 507); 5 Sep 2003 12:53:09 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 5 Sep 2003 12:53:07 -0000 Delivered-To: eap@frascone.com Received: (qmail 31960 invoked by uid 507); 5 Sep 2003 12:51:27 -0000 Received: from mgw-x1.nokia.com (131.228.20.21) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 5 Sep 2003 12:51:26 -0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h85CpMB03179 for ; Fri, 5 Sep 2003 15:51:23 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Sep 2003 15:51:22 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 5 Sep 2003 15:51:22 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 5 Sep 2003 15:51:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] [Issue] Changes to EAP methods Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BBD5@esebe023.ntc.nokia.com> Thread-Topic: [eap] [Issue] Changes to EAP methods Thread-Index: AcNzMoID/XaRgtDfSSqDABQtfsJDIgAebRnQ From: To: Cc: X-OriginalArrivalTime: 05 Sep 2003 12:51:22.0139 (UTC) FILETIME=[688176B0:01C373AC] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 5 Sep 2003 15:51:21 +0300 X-Virus-Scanned: by AMaViS 0.3.12 Content-Transfer-Encoding: quoted-printable Hi, I agree that there is little need for EAP generated keys _if_=20 the server authentication is not extensible, only client=20 authentication. But I think this would be an unnecessary=20 limitation. After all, if the point of EAP (which is, after all,=20 the _E_xtensible Authentication Protocol) is to allow users to=20 choose an authentication method that suits their needs, why=20 should this be limited to client authentication? For instance, in the EAP-AKA case, the client already has a=20 perfectly good and secure way of authenticating the server=20 (with AKA). If using that was forbidden in e.g. IKEv2, the=20 client would be forced to use something else that's most=20 likely less secure in practise. (It would require that the=20 client gets the CA certificate and server's DN/FQDN from=20 somewhere--and I'm not even thinking about certificate revocation yet. And all of this would be totally unnecessary, and would only make the whole less secure.) So, I still think that exporting a key from EAP is the correct=20 way to bind the tunnel and EAP together. The other alternative that would also work is to import some cryptographic "context"=20 from the tunnel (IKEv2) to EAP method--but this would be something=20 like a hash of the first two IKEv2 packets (like in AUTH payloads), not just a single byte saying "IKEv2". This would require changes=20 not just to all EAP methods, but also to the AAA infrastructure=20 (to transport the context hash from IKEv2 server to backend AAA=20 server), so I think there's little reason to do that. Best regards, Pasi > -----Original Message----- > From: ext Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > Sent: Friday, September 05, 2003 1:19 AM > To: Eronen Pasi (NRC/Helsinki) > Cc: eap@frascone.com > Subject: RE: [eap] [Issue] Changes to EAP methods >=20 > The addition of the "context" field will solve the mitm problem for > ALL situations in which the tunneling application is well designed, > well implemented, and well practiced. In these cases there is no > need for the EAP-generated keys AT ALL (in particular, it is > perfectly ok if the EAP method does not generate keys). In > particular, this is the case in IKE. Of course, I am assuming that > in IKE the public key of the responder (the server in this case) is > verified by the initiator (who either has the server's PK or > verifies it against a certificate). If you run IKE without making > sure you have the right PKs (or certificates) then you deserve the > mitm attacks... > Can I "officially" request that the EAP WG consider adding the > context field? Even those that fall in love with key-generating > methods (which certainly have many merits outside the tunneled > applications), should still recognize that a "context" variable is a > good cryptographic practice in any authentication situation. >=20 > Hugo >=20 > PS: I am not subscribed to the list so if you follow up on this and > want me to see the msg please re: me. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 5 13:27:19 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07394 for ; Fri, 5 Sep 2003 13:27:18 -0400 (EDT) Received: (qmail 13810 invoked by uid 507); 5 Sep 2003 17:01:16 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 5 Sep 2003 17:01:14 -0000 Delivered-To: eap@frascone.com Received: (qmail 13653 invoked by uid 507); 5 Sep 2003 16:59:33 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 5 Sep 2003 16:59:32 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h85GRbx25115 for ; Fri, 5 Sep 2003 09:27:37 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] EAP WG last call on draft-ietf-eap-rfc2284bis-05.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 5 Sep 2003 09:27:36 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 This is to announce EAP WG last call on RFC 2284bis-05. The draft should be available on the IETF archive by Monday, September 8, 2003 at the following location: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-05.txt Until then it is available for examination here: http://www.levkowetz.com/pub/ietf/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-05.txt http://www.levkowetz.com/pub/ietf/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-05.html EAP WG last call on RFC 2284bis-05 will run until September 25, 2003. Please send comments to the EAP WG mailing list (eap@frascone.com) in the format specified in the EAP issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 5 13:40:06 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08187 for ; Fri, 5 Sep 2003 13:40:03 -0400 (EDT) Received: (qmail 16116 invoked by uid 507); 5 Sep 2003 17:37:06 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 5 Sep 2003 17:37:05 -0000 Delivered-To: eap@frascone.com Received: (qmail 16058 invoked by uid 507); 5 Sep 2003 17:36:22 -0000 Received: from h-66-167-171-107.sttnwaho.covad.net (HELO internaut.com) (66.167.171.107) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 5 Sep 2003 17:36:21 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h85H4Pb27383 for ; Fri, 5 Sep 2003 10:04:26 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Summary of Key Scoping issues (fwd) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 5 Sep 2003 10:04:25 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 ---------- Forwarded message ---------- Date: Thu, 04 Sep 2003 20:52:24 +0300 From: Jari Arkko To: key-design@internaut.com Subject: [key-design] summary of issues Here's a quick list of some question marks we've had in the mail discussion, together with some tentative answers people have given. But lets start with a reminder of documents and the problems we are solving: Here are references to relevant documents: - EAP Key Framework Document: http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-07.txt - IEEE 802.11i D5: http://grouper.ieee.org/groups/802/11/private/Draft_Standards/11i/802.11i-D5.0.doc Username: p8021, Password: go_wildcats PROBLEM STATEMENT EAP was originally designed for use in environments where keys where not needed. The current and planned use of EAP apply keys generated as a side effect of EAP authentication to e.g. link layer protection. However, there are significant security issues involved in the use of keys, particularly in environments where the authentication is performed in a distributed system involving APs and AAA servers. It becomes necessary to think about how the keys can be given to APs without damaging the system level security properties. Similarly, the use of EAP "SAs" in fast handoff scenarios makes it necessary to think about where such the keys can be reused and under what conditions. A preliminary definition of issues and a framework for key usage has been outlined in draft-aboba-pppext-key-problem-07.txt. A number of open issues is still left with the document, however, and it hasn't received enough review. The EAP Keying Design Team should complete the document. GENERAL 1. Scope of the work. It's clear that we can't provide WLAN access that is "completely secure" against access point compromise--an attacker who compromises an AP can always do bad things. Tentative answer: I don't think we should worry about "completely secure," because absolute or complete security is not a coherent idea. A reasonable goal is developing some confidence that the design protects against all known attacks. Russ' requirement was compromise of one AP should cannot lead automatically to compromise of all traffic flowing through any other AP, a property that many of the schemes to pass keys from AP to AP exhibited. (Jesse, Aug 28) 2. Is the document going to be specific for 802.11? Tentative answer: 802.11i should only be used as an (Pasi, Aug 28) The document should not be 802.11 centric, but 802.11i is one very good test case for it, both because it is becoming widely deployed, and because it makes different enough assumptions from some of the other architectures to exhibit different issues. (Jesse, Aug 28) NAMING 1. Should EAP SAs and link layer SAs be named? Tentative answer: Yes. (Jesse, Russ, Bernard at IETF-57) 2. How should the SAs be named? Tentative answer: through the identifiers and nonces exchanged. SCOPE, ENFORCEMENT 1. Can an EAP SA have multi-machine scope? Tentative answer: I would say that it can't have multi-machine scope. However, I'd suggest that the way to avoid this is to say so explicitly -- "The peer MUST NOT provide keys produced by EAP methods to a third party." (Bernard, Aug 28) I don't think an EAP SA can have multi-machine scope, because when a symmetric key crosses machine (or even address space) boundaries, it has to be considered compromised without very special assumptions that are apparent to the (lower case) peer. (Jesse, Aug 28) 2. Can a peer do an EAP authentication on one port (Calling-Station-Id), then move to another authenticator and do a "fast resume" on another port (different Calling-Station-Id)? Tentative answer: This is the same problem we have been discussing in other guises. When the Peer can determine that the "different" ports are on the "same" machine, then this should be allowed. (Jesse, Aug 28) 3. Can a NAS with multiple Called-Station-Ids share AAA-keys between ports with different Called-Station-Ids? For example, can an EAP peer call in on one Called-Station-Id, then call back on another one, demonstrate knowledge of the AAA-Key and continue where it left off? Tentative answer: The problem with this is the peer cannot distinguish this situation from a case where the key has been compromised. While it is desirable, we need some way to bind the same NAS identifier onto all of its interfaces, and then find some way to securely convey this information to the peer. (Jesse, Aug 28) 4. What is the scope of the AAA Key sent from the home server to the access point? Tentative answer: Called-Station-Id and Calling- Station-Id included in the AAA Request (Bernard, Aug 28) 5. Once we decide what the scope of the AAA-Key is, the next question is "do we enforce this scope?" Putting MSK into the AAA-Key doesn't "bind" it to the endpoint identifiers. Computing the AAA-Key from a hash of the MSK and the scope identifiers would accomplish this. Doing this would require that the EAP peer, the authenticator and the AAA server all agree on the endpoint identifiers of the EAP peer and authenticator. It would also require changes to the currently used AAA Key Attributes (e.g. RFC 2548). For example, if we use Called-Station-Id and Calling-Station-Id (e.g. AP MAC address and STA MAC address) as the identifiers, and we "bind" the AAA-Key to those identifiers by using them in the computation of the AAA-Key, then if the AP were to broadcast a different BSSID to the station than it uses in the Called-Station-Id sent to the authentication server, then the AAA-Key the AP obtains from the AAA-server would not agree with the key computed by the station. Similarly, the AP could not lie about the station's identity by sending a forged Calling-Station-Id to the authentication server. Of course, doing this would require changes to AAA key attributes. For example: AAA-Key = PRF (MSK or EMSK, EAP peer id, EAP auth id) (Bernard, Aug 28) 6. How are the authorizations given for the user related to the AAA Key? Tentative answer: The AAA-Key SA includes all the authorizations included in the AAA Accept message (Bernard, Aug 28) [Not sure I understand what "SA includes" technically means. Does it mean that the AP remembers the particular authorization, even if there was a fast handoff or similar? But the AP is trusted to honor these?] 7. One point to clarify is whether the Called-Station-Id includes the SSID for this purpose. Tentative answer: My recommendation would be that it not include the SSID. This would imply that a AAA-Key could be used within the NAS for any SSID, as long as the Called-Station-Id does not change. (Bernard, Aug 28) This is how I think about this issue as well, but numerous commenters on the 802.11i D5.0 letter ballot disagree. I do not understand their position yet, so it is probably premature to close this issue. (Jesse, Aug 28) BACKWARDS COMPATIBILITY 1. Will the new design with scoping etc. be backwards compatible with WPA and other uses of EAP where keys are derived? Tentative answer: Not fully. If the AAA Keys are different in the new scheme, the access point will use a different key than an old peer expects. On the other hand, we can negotiate support for this, so backwards compatibility can be retained (but see next question). (Jari, Aug 30) 2. Will there be bidding down attacks based on the above? Tentative answer: Yes. For an old client, the AP needs the MSK, and can't use the scoped MSK. (Jari, Aug 30) But if the AP includes a "I-support- scoped-keys" bit (or something) in the RSN IE (Beacon frame), then an MitM attacker can't downgrade it, since the RSN IE is already protected in WPA. Additional attacks from a compromised AP can be avoid if the scoped AAA key is derived from EMSK instead of MSK. (Pasi, Aug 31) --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 5 15:45:59 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15334 for ; Fri, 5 Sep 2003 15:45:58 -0400 (EDT) Received: (qmail 23889 invoked by uid 507); 5 Sep 2003 19:44:07 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 5 Sep 2003 19:44:06 -0000 Delivered-To: eap@frascone.com Received: (qmail 23789 invoked by uid 507); 5 Sep 2003 19:42:26 -0000 Received: from p2.piuha.net (131.160.192.2) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 5 Sep 2003 19:42:25 -0000 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0553C6A901 for ; Fri, 5 Sep 2003 22:42:23 +0300 (EEST) Message-ID: <3F58E669.2080800@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] (fwd) notes from the keying framework design team call Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 05 Sep 2003 22:39:21 +0300 X-Virus-Scanned: by AMaViS 0.3.12 Content-Transfer-Encoding: 7bit Notes from the first meeting of the EAP keying framework design team, September 4th, 2003. Participants: Bernard Aboba, Jesse Walker, Jari Arkko, Bob Moskowitz, Uri Blumenthal, Pasi Eronen, Dave Nelson (and two others, did not catch who -Jari) Notes: Jesse Walker ADMINISTRATIVE ============== 1. We will arrange a conference call every week with the same number and passcode. 2. Deadline: One deadline is the proposed joint meeting Oct 15 in Herndon. Need to issue new document version to resolve issues. Need progress in next three weeks to make this feasible. 3. Questions on practicalities. Henrik Levkowetz will be the editor also for the keying framework document. TECHNICAL DISCUSSION ==================== What are implications of scope enforcement? Jesse: If we want to enforce scope, do we need to publish the NAS identity in the EAP/Request-Identity. We can only enforce using authenticated identities Uri: Concur Bernard: Important to under that EAP authentication is not done every time. If not being used and need the functionality, then we need to put it somewhere else. Uri: There is an issue overlooked. EAP used to be a two-party protocol, but later RADIUS was introduced to make it a 3-party protocol. Bob M: EAP is still a 2-party protocol. Jesse: Yes. Keying is a 3-party protocol. Bob: But this is a 4-party protocol. Jesse: What is the 4th party? Bob: Assume supplicant owns its authentication capability. Uri: don't consider things like CA fourth party. Jari: The next AP could be a 4th party. Jesse: But its still 3 parties at a time. Bob: Two bridges authenticating over some media, and how the two bridges form the authentication. Each has its own authentication server. Jesse: If 802.1X wants to solve that problem, let them, because we already know we won't understand what we are doing. Don't want to work on unsolvable problems. Uri: Want to limit it to 3-party. One party has to know the identity of the other two. NAS identity: what is it? Pasi: each party must have an identity. But a client may not be able to distinguish identity from random bit string. Jesse: The requirement is the EAP server asserts that the identity of the party the EAP peer is talking to is an authenticated identity. Bernard: The issue is there is no binding between the different identifiers. If your proxy does not check, the EAP messages can be laundered. Uri: Right. That is why one needs authenticated identities. Bernard: But is authenticated if the proxy checks. Uri: When there are hundreds of APs, chance of one compromised is very high. Bernard: Not outlandish to assume an access point is compromised. Uri: Right. APs must therefore have an identity known to the EAP server, so it can verify the identity. Bernard: Many identity attributes sent to the RADIUS server. There may or may not be that binding on the RADIUS server. If the AP's identity is an FQDN, then RADIUS server can do a reverse lookup, but it doesn't have to be FQDN. Saying NAS must assert the same name. Jesse: The NAS and RADIUS server must set up their own authenticated session to solve this problem. Bernard: Something like this is done today. Need binding of IP address to NAS id. Jari: Three identities: NAS identifier, called station id, and NAS IP address. Must link all of them. Jesse: Well, we can declare RADIUS server must do this or it is not secure. Bernard: We can say that right attributes have to be sent. Uri: What do we do with NAS Identity? Having an octet string good enough? Or do we need an FQDN? Pasi: If some party authenticates this identity, then it doesn't help unless octet string is meaningful. Must check that it is the "right" string that is used by authentication. Bernard: If just a string, can be configured automatically. But some sort of manual entry required. Need same name in RADIUS server. Jari: Why are we talking about NAS identifier? Why not called station id? Bernard: This makes a difference. Let's go through scenarios. What scenarios to enable? Question1: AAA server gives key to an AP. It can have multiple SSIDs and BSSIDs. Similarly, NAS can have multiple phone number. If a STA has associated with one port on a distributed AP, is it ok to use same key on more than one port? Jesse: only if the client is convinced that the key is being used by the same entity. Pasi: Agree. Bernard: Virtual AP are designed to make it same physical AP looks like multiple APs. Jesse: If client can distinguish, then it's ok. Bernard: So do a "fast hand-off" across different domain. Jesse: It is not clear that hand-off across domains without authenticating to new domain has anything to do with security. Bernard: The implication is the logical identity has to be part of answer. NAS identity is not enough. Jesse: Right, but that doesn't mean the physical part won't be part of the solution. Bernard: Jesse's opinion is that crossing boundaries without authentication is not good, so using key across administrative boundaries is no good. So this seems to be a problem. Within an administrative domain, and I have a guest and corporate VLAN from the same SSID. Authenticate, fast-handoff from guest to corporate VLAN? It might be ok if context came down with key. This would prevent elevation of privilege, as long as the context didn't change. The problem in the multi-domain case was money could flow if used wrong context. If I authenticate on corp net and doing charge-back, but guest has no charging. Move to guest, then can theft of service. So context not sufficient. Pasi: How do you know user can access this or that VLAN? Uri: how is this access going to be decided? Bernard: There are access points that implement different VLANs. People do this today. Uri: The AP decides access? Bernard: No, they go back to the RADIUS server. Defining key scope will determine whether one can do hand-off. Bob: You have to control the domain of applicability of key if you hand off context. Since the group key is controlled by BSSID, you can't have one BSSID supporting multiple SSID with 802.11i. Bernard: You will have leakage in other cases, too. Dave N: What is the case? Bernard: It can be an elevation of privilege to go from one VLAN to another. Pasi: If you switch and all context transfers, then won't the behavior be the same? Bernard: Seems so. Pasi: But client would think it is on guest... Bernard: But accounting would be the same. Jari: But if everything is the same, then why bother? Dave N: If everything the same when moving between differentiated services, then why doing it? Do you need a separate SSID? Bernard: The guest network might be open, and corporate net not. So are saying if you bring ALL context, then reuse is ok. Pasi: But pointless. Why not keep using the corp account and not move? Jesse: I think there is still a security problem, because distributed state is no longer synchronized. Dave: Provisioning single BSSID with two SSIDs will lead to these problems. Bernard: Some RADIUS servers send list of authorized SSIDs. If the authorizations conflict with the SSID the client tries to use, then the AP can block it. Not clear this is useful. Next one: station with multiple ports: Hand-off to another port? Pasi: Same logic applies: if client can be convinced it is two ports on same entity, ok, otherwise not. Dave: Once you start talking about multiple user systems, this breaks apart. Bernard: Definition of "entity" is hard. Pasi: We can't enforce any definition of entity with the protocol. Bernard: AP has same problem. there are designs of distributed APs. Everything looks the same in all of these cases. What about cluster design? Jari: Pasi said in the AP case only the AAA server can assert something is one entity? Why is this? Jesse: Only AAA server is in a position to make assertion the client can believe. Jari: But if the AP is compromised, won't you see both the session keys and AAA keys, and therefore the attacker can appear as the legitimate node even towards the AAA. Jesse: Yes, but there are different ways the keys can get compromised, different attacks. Some attacks might just reveal the session keys, not the AAA keys. Bernard: There are assumptions about hygine that go into this. The administrator is trying to prevent you from doing unauthorized things. "Don't tell your password to everyone." I have 3 laptops with their own certificates, but I use same password on each. Clint: The discussion of how to limit where a key goes. There could be a rogue AP that mimics the real AP by using the same BSSID. Bernard: You can do some things to solve it. If I get complete control over AP, there are obstacles to impersonating other APs. Uri: But there might be trust relations. Bernard: One of the requirements is if one AP is compromised then we don't compromise keys on any other AP. If I move the AP address, then shared secret won't work. I can change BSSID, but if proxy is checking this, get caught. The binding will stop it. Pasi: Agree this is possible. But making tradeoff. Fast-handoffs that don't involve AAA server is no longer possible. Bernard: Disagree. Look at Bill Arbaugh's or Bob Moskowitz. Pasi: Ok, but each AP must get key from AAA server. Bob: Not true. Doesn't work this way in my scheme. Bernard: We've described several cases. People are willing to be liberal about handoff as long as you can authenticate things. Propose have some position papers. Jesse: You've asked us to contribute position papers about scenarios enabled and what the issues are in. Bernard: Yes. Volunteers: Dave N: context transfer; Clint: PMK sharing; Bernard will try to write one, too. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 5 16:37:01 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17766 for ; Fri, 5 Sep 2003 16:37:00 -0400 (EDT) Received: (qmail 27490 invoked by uid 507); 5 Sep 2003 20:35:09 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 5 Sep 2003 20:35:06 -0000 Delivered-To: eap@frascone.com Received: (qmail 27338 invoked by uid 507); 5 Sep 2003 20:33:41 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 5 Sep 2003 20:33:39 -0000 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 05 Sep 2003 13:45:35 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h85KXAdP005206; Fri, 5 Sep 2003 13:33:10 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.112.240]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Sep 2003 13:37:29 -0700 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Summary of Key Scoping issues (fwd) Message-ID: <025601c373ec$eb878870$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: X-OriginalArrivalTime: 05 Sep 2003 20:37:29.0475 (UTC) FILETIME=[86564530:01C373ED] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 5 Sep 2003 13:33:08 -0700 X-Virus-Scanned: by AMaViS 0.3.12 Content-Transfer-Encoding: 7bit I'm a bit confused by the terminology, especially EAP SA and AAA-key comments in line. Joe > SCOPE, ENFORCEMENT > > 1. Can an EAP SA have multi-machine scope? > > Tentative answer: I would say that it can't have multi-machine > scope. However, I'd suggest that the way to avoid this is to > say so explicitly -- "The peer MUST NOT provide keys > produced by EAP methods to a third party." (Bernard, > Aug 28) > > I don't think an EAP SA can have multi-machine scope, because > when a symmetric key crosses machine (or even address space) > boundaries, it has to be considered compromised without very > special assumptions that are apparent to the (lower case) peer. > (Jesse, Aug 28) > [Joe] Can you define an EAP SA? In the case where an EAP-Server/AAA server is involved there is an SA derived between the EAP-Peer and the EAP-Server, is this the SA. Keys derived from this SA are at least distributed to one other party (this might be a sun-SA). This is already a multi-machine scope. So I'm not quite sure what is meant by EAP SA. I think one difficulty here is that in general EAP is defined transparent to the existence of a AAA. When you intorduce keying security then it is hard to hide these architectural differences. > 2. Can a peer do an EAP authentication on one port > (Calling-Station-Id), > then move to another authenticator and do a "fast resume" > on another port (different Calling-Station-Id)? > > Tentative answer: This is the same problem we have been discussing > in other guises. When the Peer can determine that the "different" > ports are on the "same" machine, then this should be allowed. > (Jesse, Aug 28) [Joe] Hmmm... Is authenticaiton identitical to establishing an SA or are they two different (but related) things. > 3. Can a NAS with multiple Called-Station-Ids share AAA-keys > between ports with different Called-Station-Ids? For > example, can an EAP peer call in on one Called-Station-Id, > then call back on another one, demonstrate knowledge of the > AAA-Key and continue where it left off? > > Tentative answer: The problem with this is the peer cannot > distinguish this situation from a case where the key has been > compromised. While it is desirable, we need some way to bind > the same NAS identifier onto all of its interfaces, and then > find some way to securely convey this information to the peer. > (Jesse, Aug 28) > [Joe] Can we also define what AAA Key is? Is it a master key held by AAA? Is it a key transmitted from AAA to AP? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 8 10:09:09 2003 Received: from frascone.com (qmailr@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22243 for ; Mon, 8 Sep 2003 10:09:08 -0400 (EDT) Received: (qmail 32596 invoked by uid 507); 8 Sep 2003 14:08:12 -0000 Received: from localhost (HELO wolverine) (mailman@127.0.0.1) by localhost with SMTP; 8 Sep 2003 14:08:09 -0000 Delivered-To: eap@frascone.com Received: (qmail 31909 invoked by uid 507); 8 Sep 2003 14:06:34 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by adsl-66-137-237-100.dsl.rcsntx.swbell.net with SMTP; 8 Sep 2003 14:06:32 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21454; Mon, 8 Sep 2003 10:06:24 -0400 (EDT) Message-Id: <200309081406.KAA21454@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: eap@frascone.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [eap] I-D ACTION:draft-ietf-eap-rfc2284bis-05.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 08 Sep 2003 10:06:24 -0400 X-Virus-Scanned: by AMaViS 0.3.12 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk et al. Filename : draft-ietf-eap-rfc2284bis-05.txt Pages : 60 Date : 2003-9-8 This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as PPP or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix B. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-05.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-eap-rfc2284bis-05.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-eap-rfc2284bis-05.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: <2003-9-8083016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-rfc2284bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-rfc2284bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-8083016.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Sep 9 10:21:04 2003 Received: from wolverine (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12485 for ; Tue, 9 Sep 2003 10:21:00 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by wolverine (Postfix) with ESMTP id D5D595803AC; Tue, 9 Sep 2003 09:21:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: by wolverine (Postfix, from userid 500) id 721BF5803A5; Tue, 9 Sep 2003 09:20:43 -0500 (CDT) From: David Frascone To: eap@frascone.com Message-ID: <20030909142043.GA16895@frascone.com> Mail-Followup-To: eap@frascone.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Subject: [eap] Test, please ignore Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 9 Sep 2003 09:20:43 -0500 Testing. -- David Frascone Oxymoron: Rush hour. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 10 04:19:22 2003 Received: from wolverine (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22260 for ; Wed, 10 Sep 2003 04:19:02 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by wolverine (Postfix) with ESMTP id BEE0C5804BB; Wed, 10 Sep 2003 03:19:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by wolverine (Postfix) with ESMTP id B0C145804B9 for ; Wed, 10 Sep 2003 03:18:59 -0500 (CDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8A8ItB22874 for ; Wed, 10 Sep 2003 11:18:57 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 10 Sep 2003 11:18:54 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 10 Sep 2003 11:18:54 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 10 Sep 2003 11:18:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: comments on draft-haverinen-pppext-eap-sim-10.txt Thread-Index: AcNiZa4sxzzmZFbFSJe6v2z0JDOnOAVBwwxA From: To: X-OriginalArrivalTime: 10 Sep 2003 08:18:47.0264 (UTC) FILETIME=[284E5600:01C37774] Subject: [eap] FW: comments on draft-haverinen-pppext-eap-sim-10.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 11:18:45 +0300 Content-Transfer-Encoding: quoted-printable Please see Glen's comments on EAP SIM below. Many comments are relevant to draft-arkko-pppext-eap-aka as well. I'll post our proposed fixes in another message. Best regards, Henry -----Original Message----- From: ext Glen Zorn [mailto:gwz@cisco.com] Hi, guys. Following are my comments on the draft. I apologize in advance if I'm commenting on an outdated version; I actually reviewed the doc before the Vienna IETF but I'm just getting around to typing them up & currently I have no Internet access & so am unable to check the IETF site. =20 General Technical Comments There seems to be a huge amount of state being kept on both the client and server, raising the question of synchronization issues. Is there any way that the amount of state held can be reduced? 'Silent discard' of messages seems to me to be a major cause of interoperability problems in many protocols (most notably RADIUS), but this seems to be the standard approach to protocol errors in EAP-SIM, in many cases when there appears to be no reason to fear compromising information disclosure (the normal reason for such behavior). More on this in the specific comments. The packets seem to have the potential to get very large. Will everything fit into RADIUS messages/attributes? Specific Technical comments Sect. 3 The term "Authenticator" is used repeatedly w/o being defined. I assume that the term is used in the same way as it is used in 802.1X, but this is not clearly the case e.g. in para. 4 which says "The EAP-Request/SIM/Start packet contains the list of EAP/SIM version supported by the Authenticator in the AT_VERSION_LIST attribute." This statement is somewhat confusing, since in the 802.1X and general pass-through EAP models, the list of supported versions would come from the (logical) Authentication Server (AS). Sect. 3, Para. 5 says "The client MUST NOT reuse the NONCE_MT value from previous sessions but the client MUST choose it freshly for each EAP/SIM authentication exchange." The second constraint ("MUST choose it freshly") is easy to satisfy, but the first seems to be impossible to satisfy (barring the existence of infinite, instantaneously searchable storage on the client ;-). Also, I think that it would be a good idea to insert a reference to RFC 1750 after the last sentence in the paragraph. Sect. 3, Para. 6 says "In this document, we assume that the EAP server is implemented on the AAA server and has an interface to the GSM network, so it operates as a gateway between the Internet AAA network and the GSM authentication infrastructure." but I think that this is a poor assumption, not least because EAP itself makes no such assumption. Sect. 3, Para. 7 says "If the MAC's do not match, then the client silently ignores the EAP packet and does not send any authentication values to the network. Eventually, if another EAP-Request/SIM/Challenge packet with a valid AT_MAC is not received, the connection establishment will time out." Shouldn't the client at least log the MAC failure locally? It's not clear to me to what the words "connection establishment" are referring. Is there a hidden assumption about the underlying protocol(s)? how do you know that anything will time out? Could a bug or an attacker keep the conversation active indefinitely by just sending bogus challenges? Section 4, Para. 3 says "If AT_VERSION_LIST does not include a version that is implemented by the client and allowed in the client's security policy, then the client MUST silently ignore the EAP-Response/SIM/Start packet." Why 'MUST silently ignore'? I don't see the critical nature of the versions supported by the client. The lack of reporting would make diagnosing server configuration errors much more difficult, however. At the very least, should problems like this be logged and counted on the client-side? Section 4, Para. 4 says "...the client will detect that AT_MAC is incorrect and discard the EAP-Request/SIM/Challenge packet. The authentication procedure will time out." How and why will the procedure time out? I'm a little nervous about relying upon unspecified time out to ensure the correct operation of protocols. In particular, on one hand the server seems to be assumed to be an attacker in disguise in the case of any failure (good assumption) but it is also assumed that the rogue server will rather sheepishly abide by the rules of the protocol and just allow it to time out (seems like a poor assumption). The last paragraph of Section 5.1 says "If the client is not able to determine whether the MNC is two or three digits long, the client MAY use a 3-digit MNC." Probably just showing my ignorance, but how is it possible that the client would be unable to determine the length of the MNC? Section 5.3, Para. 6 says "The EAP server produces pseudonyms in an implementation-dependent manner." Shouldn't there be some requirement for uniqueness mentioned here? Section 5.3, Para. 9 says "If the EAP server successfully decodes the pseudonym received in the EAP-Response/Identity packet to a known client permanent identity, the authentication proceeds with the EAP-Request/SIM/Start message as usual." What does the term "decodes" mean here? =20 Section 5.3, Para. 14 says "On receipt of EAP-Request/SIM/Start that includes AT_PERMANENT_ID_REQ, the client MAY delay the processing of the message for a while in order to wait for another EAP-Request/SIM/Start without AT_PERMANENT_ID_REQ." It seems to me that just sitting & waiting is almost never a good idea... Section 6, Para. 6: It's not clear to me that the network "stores" anything, let alone that a network can store anything reliably; I also don't understand the relation between the reliability of storage media and network load. Section 6, Para. 12 says "In order to use re-authentication, the client and the server need to store the following values: Master Key, K_aut, K_encr, latest counter value and the next re-authentication identity." Doesn't the server also need to store the real identity in some form? Section 8, Para. 2 says "Because the K_encr and K_aut keys derived from the RAND challenges (as specified in Section 17) are required to process the integrity protection and encryption attributes, these attributes can only be used in the EAP-Request/SIM/Challenge message and any EAP/SIM messages sent after EAP-Requets/SIM/Challenge." But can't they also be used in the reauth messages? I have no idea what Para. 3 of Section 8.1 means. General Editorial Comments There must be a specific expiration date given for the draft, both in the "Status of this Memo" section and as the last section in the draft. -- "Expires in six months" is not good enough. In the first page header, "Point-to-Point Extensions Working Group" should be "Network Working Group". ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759=20 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 10 04:44:03 2003 Received: from wolverine (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22846 for ; Wed, 10 Sep 2003 04:43:03 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by wolverine (Postfix) with ESMTP id B9F405804BB; Wed, 10 Sep 2003 03:43:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by wolverine (Postfix) with ESMTP id DCF265804B9 for ; Wed, 10 Sep 2003 03:42:49 -0500 (CDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8A8gj424668 for ; Wed, 10 Sep 2003 11:42:48 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 10 Sep 2003 11:42:45 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 10 Sep 2003 11:42:45 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 10 Sep 2003 11:42:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: comments on draft-haverinen-pppext-eap-sim-10.txt Thread-Index: AcNiZa4sxzzmZFbFSJe6v2z0JDOnOAEf/UrwBCHapTA= From: To: X-OriginalArrivalTime: 10 Sep 2003 08:42:45.0120 (UTC) FILETIME=[8155C000:01C37777] Subject: [eap] Proposed resolutions to Glen's comments Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 11:42:44 +0300 Content-Transfer-Encoding: quoted-printable Hello, Here are our proposed resolutions to the issues Glen brought up=20 in his review of EAP SIM. Many resolutions are relevant to EAP AKA too. Any comments most welcome. > There seems to be a huge amount of state being kept on both the client > and server, raising the question of synchronization issues. Is there > any way that the amount of state held can be reduced? During a full authentication exchange, the server needs to keep=20 the triplets, NONCE_MT, client identity and version negotiation values.=20 The client has to keep the NONCE_MT and version negotiation values. Both also need to know which message they are expecting (the phase of the exchange). The state will take up roughly=20 100 bytes plus the client identity, and there doesn't seem to be any ways to reduce this state. Between EAP full authentication exchanges, the client needs to keep the pseudonym, which is a couple of dozen bytes.=20 The server needs to be able to resolve pseudonyms, but for example in the 3GPP solution the pseudonym decoding only requires the server to keep a single secret key commonly to all users. Pseudonyms are=20 resolved to IMSI by decryption. The re-authentication requires some amount of stuff to be kept, but in bytes that is not so much if you compare it to other EAP types that support session resumption. K_aut and K_encr can be derived again from the Master Key, so actually the MK, counter, next re-auth ID and the permantent ID only need to be kept. That'll be 22 bytes + the identities. The state can always be discarded, which will just=20 mean that next authentication will be "full". EAP AKA needs to keep a bit less state than EAP SIM. It should also be noted that the amount of state kept by EAP SIM is reduced if EAP SIM is used with PEAP or other tunneling lower layers. In this case, pseudonyms and re-authentication are not needed, and=20 the session resumption state is kept by the PEAP implementation rather=20 than EAP SIM. > 'Silent discard' of messages seems to me to be a major cause of > interoperability problems in many protocols (most notably RADIUS), but > this seems to be the standard approach to protocol errors in=20 > EAP-SIM, in > many cases when there appears to be no reason to fear compromising > information disclosure (the normal reason for such behavior). More on > this in the specific comments. This is a valid comment, and we're planning to specify=20 error messages and EAP Failure instead of silent discard for most of the error cases. In general, if an error occurs, the EAP exchange will be terminated. For silent discard, we should refer to 2284bis's definition which includes logging and counter=20 increments.=20 We can do this change without breaking technical compatibility to=20 previous draft versions. Implementations of the old versions will=20 silently discard the new error packets, and time out. We think the client should send an error packet in the following cases: malformed EAP request packet (incorrect length etc.), none of the server's versions in AT_VERSION_LIST are supported,=20 incorrect AT_MAC, invalid AT_RAND (e.g. insufficient number of = challenges), unrecognized non-skippable attribute, incorrect attribute types=20 (mandatory attribute missing or wrong attributes included),=20 unrecognized subtype. Upon receipt of an erroneous EAP response, the server issues EAP Failure. These error cases include malformed packets, incorrect AT_MAC, invalid AT_COUNTER, unrecognized non-skippable attribute, incorrect attribute types and unrecognized subtype. > The packets seem to have the potential to get very large. Will > everything fit into RADIUS messages/attributes? The currently specified attributes will fit into RADIUS, but as the protocol is extensible the packets could grow too large. We'll add discussion about this restriction to future extensions. If large extensions are specified in the future, then=20 a future version will need to specify fragmentation. =20 > Specific Technical comments >=20 > Sect. 3 > The term "Authenticator" is used repeatedly w/o being=20 > defined. I assume > that the term is used in the same way as it is used in=20 > 802.1X, but this > is not clearly the case e.g. in para. 4 which says "The > EAP-Request/SIM/Start packet contains the list of EAP/SIM version > supported by the Authenticator in the AT_VERSION_LIST=20 > attribute." This > statement is somewhat confusing, since in the 802.1X and general > pass-through EAP models, the list of supported versions would=20 > come from > the (logical) Authentication Server (AS). Yes, we need to change the language so that "EAP Server" is used to denote the network element that terminates EAP SIM. I don't know if we need to use the term Authenticator at all, but anyway it should be used as usual in 802.1x and EAP. The comment may apply to EAP AKA too, so we'll go it over too. > Sect. 3, Para. 5 says "The client MUST NOT reuse the NONCE_MT=20 > value from > previous sessions but the client MUST choose it freshly for=20 > each EAP/SIM > authentication exchange." The second constraint ("MUST choose it > freshly") is easy to satisfy, but the first seems to be impossible to > satisfy (barring the existence of infinite, instantaneously searchable > storage on the client ;-). Also, I think that it would be a good idea > to insert a reference to RFC 1750 after the last sentence in the > paragraph. Yes. The client must choose it freshly with a good random number generator, but it does not need to guarantee that NONCE_MT is=20 not re-used. This comment does not apply to EAP AKA. > Sect. 3, Para. 6 says "In this document, we assume that the EAP server > is implemented on the AAA server and has an interface to the GSM > network, so it operates as a gateway between the Internet AAA network > and the GSM authentication infrastructure." but I think that this is a > poor assumption, not least because EAP itself makes no such=20 > assumption. We don't need to make this assumption. :-) =20 > Sect. 3, Para. 7 says "If the MAC's do not match, then the client > silently ignores the EAP packet and does not send any authentication > values to the network. Eventually, if another=20 > EAP-Request/SIM/Challenge > packet with a valid AT_MAC is not received, the connection=20 > establishment > will time out." Shouldn't the client at least log the MAC failure > locally? It's not clear to me to what the words "connection > establishment" are referring. Is there a hidden assumption about the > underlying protocol(s)? how do you know that anything will time out? > Could a bug or an attacker keep the conversation active=20 > indefinitely by > just sending bogus challenges? Instead of "connection establishment" we should to talk about "EAP exchange". To my knowledge there is a timeout in the EAP state machine (and another in 802.1x state machine, but assuming that would be a hidden assumption). As discussed above, we're planning to specify explicit error messages instead of silent discard, so we won't need to rely on underlying timeouts. > Section 4, Para. 3 says "If AT_VERSION_LIST does not include a version > that is implemented by the client and allowed in the client's security > policy, then the client MUST silently ignore the=20 > EAP-Response/SIM/Start > packet." Why 'MUST silently ignore'? I don't see the critical nature > of the versions supported by the client. The lack of reporting would > make diagnosing server configuration errors much more difficult, > however. At the very least, should problems like this be logged and > counted on the client-side? We agree, the client should send an error message that says the client doesn't support the server's version. EAP AKA does not have version negotiation so this comment does not apply to it. > Section 4, Para. 4 says "...the client will detect that AT_MAC is > incorrect and discard the EAP-Request/SIM/Challenge packet. The > authentication procedure will time out." How and why will=20 > the procedure > time out? I'm a little nervous about relying upon=20 > unspecified time out > to ensure the correct operation of protocols. In particular, on one > hand the server seems to be assumed to be an attacker in disguise in > the case of any failure (good assumption) but it is also assumed that > the rogue server will rather sheepishly abide by the rules of the > protocol and just allow it to time out (seems like a poor assumption). We're planning to specify an error code for failed MAC, so this timeout issue will be resolved. > The last paragraph of Section 5.1 says "If the client is not able to > determine whether the MNC is two or three digits long, the client MAY > use a 3-digit MNC." Probably just showing my ignorance, but how is it > possible that the client would be unable to determine the=20 > length of the > MNC? In GSM the client doesn't need to know which digits of the IMSI belong = to=20 the MNC except in some cases where it gets help from the network's broadcast messages. So in the absense of the GSM broadcast messages, the client doens't necessarily know whether the MNC is 3 or 2 digits long. The IMSI is just a string of digits without any visible structure. > Section 5.3, Para. 6 says "The EAP server produces pseudonyms in an > implementation-dependent manner." Shouldn't there be some requirement > for uniqueness mentioned here? Yes. The pseudonyms must be unique among the servers that the client can use. In general we assume all the servers to be at home, so the home operator must ensure this. If visited network servers were used in some environment, then uniqueness would have to be=20 guaranteed in this environment for all servers. This comment applies to EAP AKA as well. > Section 5.3, Para. 9 says "If the EAP server successfully decodes the > pseudonym received in the EAP-Response/Identity packet to a=20 > known client > permanent identity, the authentication proceeds with the > EAP-Request/SIM/Start message as usual." What does the term "decodes" > mean here? =20 It means that the server recognizes the pseudonym, the server is able to map the pseudonym to a client identity.=20 This comment applies to EAP AKA as well. > Section 5.3, Para. 14 says "On receipt of EAP-Request/SIM/Start that > includes AT_PERMANENT_ID_REQ, the client MAY delay the=20 > processing of the > message for a while in order to wait for another EAP-Request/SIM/Start > without AT_PERMANENT_ID_REQ." It seems to me that just sitting & > waiting is almost never a good idea... This was changed in the latest version. In the current version the client is may silently discard the request for permanent identity in order to wait for another Start request. The client may accept a retransmission of the original request later.=20 This comment applies to EAP AKA as well. > Section 6, Para. 6: It's not clear to me that the network "stores" > anything, let alone that a network can store anything reliably; I also > don't understand the relation between the reliability of storage media > and network load. We need to rephrase this because the network really doesn't need to maintain any databases for the pseudonyms (see the discussion above about the 3GPP solution). Anyway, there are two reasons to have separate pseudonyms and re-authentication identities: 1. the client can indicate with the choice of identity whether it wants re-authentication or full authentication 2. the network can handle the re-authentication identities differently from the pseudonyms. Different servers should be able to resolve each other's pseudonyms but don't need to be able to do re-authentication if another server performed the original full authentication. This comment is relevant to EAP AKA too. > Section 6, Para. 12 says "In order to use re-authentication,=20 > the client > and the server need to store the following values: Master Key, K_aut, > K_encr, latest counter value and the next re-authentication identity." > Doesn't the server also need to store the real identity in some form? Yes. =20 > Section 8, Para. 2 says "Because the K_encr and K_aut keys=20 > derived from > the RAND challenges (as specified in Section 17) are required=20 > to process > the integrity protection and encryption attributes, these=20 > attributes can > only be used in the EAP-Request/SIM/Challenge message and any EAP/SIM > messages sent after EAP-Requets/SIM/Challenge." But can't=20 > they also be > used in the reauth messages? Yes. > I have no idea what Para. 3 of Section 8.1 means. OK, we'll clarify this.=20 The message authentication code can be calculated over=20 data that is not included in the EAP packet. If such=20 additional data is included in the calculation, then=20 there is a separate specification for each message.=20 For example, for the EAP-Request/SIM/Challenge, the MAC=20 is calculated over the EAP packet and NONCE_MT,=20 which is not included in the packet, as specified=20 in Section 11. > There must be a specific expiration date given for the draft, both in > the "Status of this Memo" section and as the last section in=20 > the draft. > -- "Expires in six months" is not good enough. OK. =20 > In the first page header, "Point-to-Point Extensions Working Group" > should be "Network Working Group". OK. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 10 12:34:15 2003 Received: from wolverine (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07038 for ; Wed, 10 Sep 2003 12:34:01 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by wolverine (Postfix) with ESMTP id 393235804CA; Wed, 10 Sep 2003 11:34:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by wolverine (Postfix) with ESMTP id 114E85804C7 for ; Wed, 10 Sep 2003 11:33:49 -0500 (CDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8AGXFd26535; Wed, 10 Sep 2003 12:33:26 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h8AGZBm10344; Wed, 10 Sep 2003 12:35:16 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h8AGWbGu009836; Wed, 10 Sep 2003 12:32:39 -0400 To: eap@frascone.com Cc: gwz@cisco.com Subject: Re: [eap] FW: comments on draft-haverinen-pppext-eap-sim-10.txt In-reply-to: Your message of "Wed, 10 Sep 2003 11:18:45 +0300." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <9835.1063211557@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 12:32:37 -0400 -----BEGIN PGP SIGNED MESSAGE----- glen> General Technical Comments glen> There seems to be a huge amount of state being kept on both the glen> client and server, raising the question of synchronization issues. glen> Is there any way that the amount of state held can be reduced? My feeling is that there isn't really that much state in the protocol, but rather that none of the state is explicit, so it seems unmanageably large. Section 5 in particular needs a complete rewrite. The sentences jump from client requirements to server requirements, without even a paragraph change. My major comment on -11 is that section 5 should document the client and the server side seperately. A clear set of states for the client and the server should be defined. glen> 'Silent discard' of messages seems to me to be a major cause of glen> interoperability problems in many protocols (most notably RADIUS), glen> but this seems to be the standard approach to protocol errors in glen> EAP-SIM, in many cases when there appears to be no reason to fear glen> compromising information disclosure (the normal reason for such glen> behavior). More on this in the specific comments. Yes, I agree. glen> The packets seem to have the potential to get very large. Will glen> everything fit into RADIUS messages/attributes? I'm not convinced that we need the potentially 1024 byte attributes there. The EAP contents can be split across multiple EAP-Message radius attribues. glen> Sect. 3, Para. 6 says "In this document, we assume that the EAP glen> server is implemented on the AAA server and has an interface to the glen> GSM network, so it operates as a gateway between the Internet AAA glen> network and the GSM authentication infrastructure." but I think glen> that this is a poor assumption, not least because EAP itself makes glen> no such assumption. It seems to me that as long as the "server" is able to get (IMSI,RAND,SRES) tuples, it doesn't matter. They may be derived directly, or taken across SS7 or whatever. What situation do think this rules out? ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP19SJIqHRg3pndX9AQHAeQQA0N+21Zd/hW4+8WXdYuH6o+1A8UxqpvRD ZBKIH7p23cib/Xa2+SfKze8ayIUybtlNi1/KNC4QMOND4monDJ8s8VDv13V7oDfU WoGduEL6FYlWDpoQ9Tw66xwza/gMcQj4IgkJ/yCC+WZwAhvqW4HlQXIX/JU4zQle pFyS+QhlL38= =Loci -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 10 13:03:03 2003 Received: from wolverine (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08195 for ; Wed, 10 Sep 2003 13:02:58 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by wolverine (Postfix) with ESMTP id 2B1E95804D8; Wed, 10 Sep 2003 12:03:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by wolverine (Postfix) with ESMTP id C16615804C7 for ; Wed, 10 Sep 2003 12:02:22 -0500 (CDT) Received: by fw1.gdm.de (8.11.6p2/8.11.6) id h8AH2KL22667 for eap@frascone.com; Wed, 10 Sep 2003 19:02:20 +0200 (CEST) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Wed Sep 10 19:02:20 2003 From: Hubert.Ertl@de.gi-de.com To: eap@frascone.com Message-ID: X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0.1CF1|March 04, 2003) at 10.09.2003 19:00:42 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by amavisd-new Subject: [eap] Hubert Ertl/GDM/GuD is out of the office. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 10 Sep 2003 19:00:47 +0200 Content-Transfer-Encoding: quoted-printable Ich werde ab 10.09.2003 nicht im B=FCro sein. Ich kehre zur=FCck am 12.09.2003. I will read my email during my absence and will respond to your messag= e when I return on September 12th.= _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 11 05:06:21 2003 Received: from wolverine (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15994 for ; Thu, 11 Sep 2003 05:06:05 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by wolverine (Postfix) with ESMTP id C82165804F2; Thu, 11 Sep 2003 04:06:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by wolverine (Postfix) with ESMTP id B6CDA5804E4 for ; Thu, 11 Sep 2003 04:04:58 -0500 (CDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8B949B21538 for ; Thu, 11 Sep 2003 12:04:46 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Sep 2003 12:04:07 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 11 Sep 2003 12:04:08 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 11 Sep 2003 12:04:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] FW: comments on draft-haverinen-pppext-eap-sim-10.txt Message-ID: Thread-Topic: [eap] FW: comments on draft-haverinen-pppext-eap-sim-10.txt Thread-Index: AcN3uYaDneizR/AGRH6gGWzluWmQRwAf8tNQ From: To: , Cc: X-OriginalArrivalTime: 11 Sep 2003 09:04:07.0062 (UTC) FILETIME=[A7D85360:01C37843] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 11 Sep 2003 12:04:05 +0300 Content-Transfer-Encoding: quoted-printable Michael, Thanks for your comments. I agree we need to clarify=20 Section 5 in the next draft version. Regarding the architectural assumptions, I agree with Glen on that this draft doesn't need to discuss the network architecture beyond the EAP server. The document should specify the EAP method only, and for the purposes of this document it should be sufficient to know that the EAP server has some mechanism to obtain triplets.=20 Regards, Henry > -----Original Message----- > From: ext Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: 10 September, 2003 19:33 > To: eap@frascone.com > Cc: gwz@cisco.com > Subject: Re: [eap] FW: comments on=20 > draft-haverinen-pppext-eap-sim-10.txt >=20 >=20 >=20 >=20 > *** PGP Signature Status: unknown > *** Signer: Unknown, Key ID =3D 0xE99DD5FD > *** Signed: 10.09.2003 7:32:36 PM > *** Verified: 11.09.2003 10:48:02 AM > *** BEGIN PGP VERIFIED MESSAGE *** >=20 >=20 > glen> General Technical Comments >=20 > glen> There seems to be a huge amount of state being kept=20 > on both the > glen> client and server, raising the question of=20 > synchronization issues. > glen> Is there any way that the amount of state held can=20 > be reduced? >=20 > My feeling is that there isn't really that much state in=20 > the protocol, > but rather that none of the state is explicit, so it seems=20 > unmanageably > large.=20 >=20 > Section 5 in particular needs a complete rewrite. The=20 > sentences jump from > client requirements to server requirements, without even a=20 > paragraph change. > =20 > My major comment on -11 is that section 5 should document=20 > the client and > the server side seperately. A clear set of states for the=20 > client and the > server should be defined. >=20 > glen> 'Silent discard' of messages seems to me to be a=20 > major cause of > glen> interoperability problems in many protocols (most=20 > notably RADIUS), > glen> but this seems to be the standard approach to=20 > protocol errors in > glen> EAP-SIM, in many cases when there appears to be no=20 > reason to fear > glen> compromising information disclosure (the normal=20 > reason for such > glen> behavior). More on this in the specific comments. >=20 > Yes, I agree. >=20 > glen> The packets seem to have the potential to get very=20 > large. Will > glen> everything fit into RADIUS messages/attributes? >=20 > I'm not convinced that we need the potentially 1024 byte=20 > attributes there. > The EAP contents can be split across multiple EAP-Message=20 > radius attribues. >=20 > glen> Sect. 3, Para. 6 says "In this document, we assume=20 > that the EAP > glen> server is implemented on the AAA server and has an=20 > interface to the > glen> GSM network, so it operates as a gateway between=20 > the Internet AAA > glen> network and the GSM authentication infrastructure."=20 > but I think > glen> that this is a poor assumption, not least because=20 > EAP itself makes > glen> no such assumption. >=20 > It seems to me that as long as the "server" is able to get=20 > (IMSI,RAND,SRES) > tuples, it doesn't matter. They may be derived directly, or=20 > taken across SS7 > or whatever. > What situation do think this rules out? >=20 > ] Out and about in Ottawa. hmmm... beer. =20 > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON =20 > |net architect[ > ] mcr@sandelman.ottawa.on.ca=20 http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security = guy"); [ *** END PGP VERIFIED MESSAGE *** _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 11 20:05:22 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19345 for ; Thu, 11 Sep 2003 20:05:12 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D0BF580641; Thu, 11 Sep 2003 19:05:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 12976580640 for ; Thu, 11 Sep 2003 19:04:50 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8BNWK204976 for ; Thu, 11 Sep 2003 16:32:21 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Issue 170: Terminology Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 11 Sep 2003 16:32:20 -0700 (PDT) Issue 170: Terminology Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 9/11/2003 Reference: Document: EAP-05 Comment type: T Priority: S Section: 1.2 Rationale/Explanation of issue: For the purposes of RFC 2284bis, it is not necessary to delve into the uses of the MSK/EMSK -- it's just enough to say that they must be produced and exported. Let's leave discussion of uses to the Key Framework document. In Section 1.2, change: " Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is used in the derivation of Transient Session Keys (TSKs) for the ciphersuite negotiated between the EAP peer and authenticator. Where a backend authentication server is present, acting as an EAP server, it will typically transport the MSK to the authenticator, so that in this case, the MSK is available to the peer, authenticator and authentication server. Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. Unlike the MSK, the EMSK is known only to the EAP peer and EAP server and is not provided to a third party. The EMSK is reserved for future uses that are not defined yet. For example, it could be used to derive additional keying material for purposes such as fast handoff, cryptographic binding, etc." To: " Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets in length. In existing implementations a AAA server acting as an EAP server transports the MSK to the authenticator. Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is reserved for future uses that are not defined yet and is not provided to a third party." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 11 20:07:10 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19426 for ; Thu, 11 Sep 2003 20:07:02 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A6BAA580449; Thu, 11 Sep 2003 19:07:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 8DB3C5803AD for ; Thu, 11 Sep 2003 19:06:15 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8BNXkJ05059 for ; Thu, 11 Sep 2003 16:33:47 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Issue 171: IKEv2 over TCP Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 11 Sep 2003 16:33:46 -0700 (PDT) Issue 171: IKEv2 over TCP Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 9/11/2003 Reference: Document: EAP-05 Comment type: T Priority: S Section: 2.2, 4.3 Rationale/Explanation of issue: IKEv2 runs over UDP, not TCP as implied in Section 2.2 and 4.3. In Section 2.2, change: "TCP [IKEv2]" to "TCP [PIC]". In Section 4.3, change: " When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as within [IKEv2]), the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. The peer may still maintain a timeout value so as to avoid waiting indefinitely for a Request." To: " When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as within [PIC]), the authenticator retransmission timer MAY be set to an artificially high value, so that retransmissions do not occur at the EAP layer. The peer may still maintain a timeout value so as to avoid waiting indefinitely for a Request." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 11 21:04:08 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21104 for ; Thu, 11 Sep 2003 21:04:00 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 930075804F9; Thu, 11 Sep 2003 20:04:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 1234D580449 for ; Thu, 11 Sep 2003 20:03:54 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8C0VP008258 for ; Thu, 11 Sep 2003 17:31:25 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Issue 172: Miscellaneous NITs Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 11 Sep 2003 17:31:25 -0700 (PDT) Issue 172: Miscellaneous NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 9/11/2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-September/001655.html Document: EAP-05 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: In Section 1.2, add: "AAA Authentication, Authorization and Accounting. AAA protocols with EAP support include RADIUS [RFC3579] and Diameter [Diam-EAP]. In this document, the terms "AAA server" and "backend authentication server are used interchangeably." In Section 2.2, Figure 1, page 11, change "Layer" to "layer" In Section 3.4, change: " To improve reliability, if a peer receives a lower layer success indication as defined in Section 7.2, it MAY conclude that a Success packet has been lost, and behave as it had actually received a Success packet. This includes choosing to ignore the Success in some circumstances as described in Section 4.2." To: " To improve reliability, if a peer receives a lower layer success indication as defined in Section 7.2, it MAY conclude that a Success packet has been lost, and behave as if it had actually received a Success packet. This includes choosing to ignore the Success in some circumstances as described in Section 4.2." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 11 21:06:12 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21146 for ; Thu, 11 Sep 2003 21:06:04 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A1A3B5804F9; Thu, 11 Sep 2003 20:06:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 02934580449 for ; Thu, 11 Sep 2003 20:05:04 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8C0WZp08331 for ; Thu, 11 Sep 2003 17:32:35 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Issue 173: Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 11 Sep 2003 17:32:34 -0700 (PDT) Issue 173: RFC 2284bis method issues Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 9/11/2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-September/001656.html Document: EAP-05 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: There are no security claims for the Identity (5.1), Notification (5.2), and NAK (legacy, 5.3.1 or expanded, 5.3.2) methods. For each of these methods, insert the following claims: Security Claims (see Section 7.2): Intended use: Physically secure lower layers; vulnerable to attack when used with wireless or over the Internet. Fragmentation: No Auth. Mechanism: None Ciphersuite Negotiation: No Mutual authentication: No Integrity protection: No Replay protection: No Confidentiality: No Key Derivation: No Key strength: N/A Dictionary attack prot: N/A Key hierarchy: N/A Fast reconnect: No Crypt. binding: N/A Acknowledged S/F: No Other than a statement in Section 3.1, there is no explicit statement about whether the methods defined in RFC 2284bis support fragmentation. This should be stated explicitly, and added as a required claim. Add: "Fragmentation: No Auth. Mechanism: None Ciphersuite Negotiation: No" to Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 Also, change "Mechanism:" To "Auth. Mechanism:" in these sections. Add the following to Section 7.2.1: "Protected Ciphersuite negotiation This refers to the ability of an EAP method to negotiate the ciphersuite used to protect the EAP conversation, as well as to integrity protect the negotiation. It does not refer to the ability to negotiate the ciphersuite used to protect data. Fragmentation This refers to whether an EAP method supports fragmentation and reassembly. As noted in Section 3.1, EAP methods should support fragmentation and reassembly if EAP packets can exceed the minimum MTU of 1020 octets." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 11 21:08:08 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21251 for ; Thu, 11 Sep 2003 21:08:00 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3ABA35804F9; Thu, 11 Sep 2003 20:08:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id AD08A580449 for ; Thu, 11 Sep 2003 20:07:23 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8C0YsW08435 for ; Thu, 11 Sep 2003 17:34:55 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Issue 174: Mandatory to Implement Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 11 Sep 2003 17:34:54 -0700 (PDT) Issue 174: Mandatory to Implement Submitter name: Dorothy Stanley Submitter email address: dstanley@agere.com Date first submitted: 9/11/2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-September/001657.html Document: EAP-05 Comment type: T Priority: S Section: 5, 5.4 Rationale/Explanation of issue: It seems wasteful to require an EAP peer to implement the EAP MD5-Challenge method, even in situations (such as IEEE 802.11i) where mutual authentication is required. Can we relax this requirement? In Section 5, change: "All EAP implementations MUST support Types 1-4, which are defined in this document, and SHOULD support Type 254. Implementations MAY support other Types defined here or in future RFCs." To: "All EAP server implementations MUST support Types 1-4, which are defined in this document, and SHOULD support Type 254. EAP peer implementations which support physically secure lower layers MUST support types 1-4, and SHOULD support Type 254. EAP Peer implementations which only support physically insecure lower layers requiring mutual authentication MAY NOT support Type 4 (EAP MD5-Challenge). An authenticator that supports only pass-through MUST allow communication with a backend authentication server that is capable of supporting Type 4 (MD5-Challenge), although the implementation need not support MD5-Challenge itself. However, if the EAP authenticator can be configured to authenticate peers locally (e.g., not operate in pass-through), then it MUST support Type 4 (MD5-Challenge). Implementations MAY support other Types defined here or in future RFCs." Delete the following from Section 5.4: "EAP peer and EAP server implementations MUST support the MD5-Challenge mechanism. An authenticator that supports only pass-through MUST allow communication with a backend authentication server that is capable of supporting MD5-Challenge, although the EAP authenticator implementation need not support MD5-Challenge itself. However, if the EAP authenticator can be configured to authenticate peers locally (e.g., not operate in pass-through), then the requirement for support of the MD5-Challenge mechanism applies." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 11 22:32:24 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22671 for ; Thu, 11 Sep 2003 22:32:04 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3A45A5804F9; Thu, 11 Sep 2003 21:32:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id A5EA0580449 for ; Thu, 11 Sep 2003 21:31:42 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8C1xD513147 for ; Thu, 11 Sep 2003 18:59:13 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Issue 175: Rewrite of Section 7.10 and 7.13 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 11 Sep 2003 18:59:13 -0700 (PDT) Issue 175: Rewrite of Sections 7.10 and 7.13 Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 9/11/2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-September/001658.html Document: EAP-05 Comment type: T Priority: S Section: 7.10, 7.13 Rationale/Explanation of issue: These sections need to be updated to avoid conflict with the Key Framework Document. Change Section 7.10 to: "7.10 Key derivation It is possible for the peer and EAP server to mutually authenticate, and derive keys. In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets. The MSK and EMSK are not used directly to protect data; however, they are of sufficient size to enable derivation of a AAA-Key subsequently used to derive Transient Session Keys (TSKs) for use with the selected ciphersuite. Each ciphersuite is responsible for specifying how to derive the TSKs from the AAA-Key. The EAP method is also responsible for the derivation of Transient EAP Keys (TEKs) used for protection of the EAP conversation itself. EAP methods provide the MSK and EMSK and not Transient Session Keys so as to allow EAP methods to be ciphersuite and media independent. Depending on the lower layer, EAP methods may run before or after ciphersuite negotiation, so that the selected ciphersuite may not be known to the EAP method. By providing keying material usable with any ciphersuite, EAP methods can used with a wide range of ciphersuites and media. Non-overlapping substrings of the MSK MUST be cryptographically separate from each other, as defined in Section 7.2.1. That is, knowledge of one substring MUST NOT help in recovering some other substring without breaking some hard cryptographic assumption. This is required because some existing ciphersuites form TSKs by simply splitting the AAA-Key to pieces of appropriate length. Likewise, non-overlapping substrings of the EMSK MUST be cryptographically separate from each other, and from substrings of the MSK. The EMSK is reserved for future use and MUST remain on the EAP peer and EAP server where it is derived; it MUST NOT be transported to, or shared with, additional parties, or used to derive any other keys. (This restriction will be relaxed in a future document that specifies how the EMSK can be used.) This specification does not provide detailed guidance on how EAP methods are to derive the MSK, EMSK and TEKs, or how the TSKs are to be derived from the AAA-Key. Key derivation is an art that is best practiced by professionals; rather than inventing new key derivation algorithms, reuse of existing algorithms such as those specified in IKE [RFC2409], or TLS [RFC2246] is recommended. Further details on EAP Key Derivation are provided within [KEYFRAME]." Change Section 7.13 to: "7.13 Separation of authenticator and backend authentication server It is possible for the EAP peer and authenticator to mutually authenticate, and derive a AAA-Key for a ciphersuite used to protect subsequent data traffic. This does not present an issue on the peer, since the peer and EAP client reside on the same machine; all that is required is for the client to derive the AAA-Key from the MSK and EMSK exported by the EAP method, and to subsequently pass a Transient Session Key (TSK) to the ciphersuite module. However, in the case where the authenticator and authentication server reside on different machines, there are several implications for security. [a] Authentication will occur between the peer and the authentication server, not between the peer and the authenticator. This means that it is not possible for the peer to validate the identity of the authenticator that it is speaking to, using EAP alone. [b] As discussed in [RFC3579], the authenticator is dependent on the AAA protocol in order to know the outcome of an authentication conversation, and does not look at the encapsulated EAP packet (if one is present) to determine the outcome. In practice this means that the AAA protocol spoken between the authenticator and authentication server MUST support per-packet authentication, integrity and replay protection. [c] Where EAP is used over lower layers which are not physically secure, subsequent to completion of the EAP conversation, a subsequent secure association protocol SHOULD be run between the peer and authentication in order to mutually authenticate the peer and authenticator; guarantee liveness of the TSKs; provide protected ciphersuite and capabilities negotiation; and provide for synchronized key usage. [d] A AAA-Key derived from the MSK and/or EMSK negotiated between the peer and authentication server MAY be transmitted to the authenticator. Therefore a mechanism needs to be provided to transmit the AAA-Key from the authentication server to the authenticator that needs it. The specification of the AAA-key derivation, transport and wrapping mechanisms is outside the scope of this document. Further details on AAA Key Derivation are provided within [KEYFRAME]." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 11 22:43:09 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22950 for ; Thu, 11 Sep 2003 22:42:59 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 323ED5804F9; Thu, 11 Sep 2003 21:43:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 2B1A3580449 for ; Thu, 11 Sep 2003 21:42:15 -0500 (CDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 990C26A903; Fri, 12 Sep 2003 05:42:12 +0300 (EEST) Message-ID: <3F6131C4.6090007@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 170: Terminology References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 12 Sep 2003 05:39:00 +0300 Content-Transfer-Encoding: 7bit Agreed. I also agree about issues 171, 172,and 173. Bernard Aboba wrote: > For the purposes of RFC 2284bis, it is not necessary to delve into the > uses of the MSK/EMSK -- it's just enough to say that they must be produced > and exported. Let's leave discussion of uses to the Key Framework > document. > > In Section 1.2, change: > > " Master Session Key (MSK) > Keying material that is derived between the EAP peer and > server and exported by the EAP method. The MSK is used in > the derivation of Transient Session Keys (TSKs) for the > ciphersuite negotiated between the EAP peer and > authenticator. Where a backend authentication server is > present, acting as an EAP server, it will typically > transport the MSK to the authenticator, so that in this > case, the MSK is available to the peer, authenticator and > authentication server. > > Extended Master Session Key (EMSK) > Additional keying material derived between the EAP client > and server that is exported by the EAP method. Unlike the > MSK, the EMSK is known only to the EAP peer and EAP server > and is not provided to a third party. The EMSK is reserved > for future uses that are not defined yet. For example, it > could be used to derive additional keying material for > purposes such as fast handoff, cryptographic binding, etc." > > To: > > " Master Session Key (MSK) > Keying material that is derived between the EAP peer and > server and exported by the EAP method. The MSK is at > least 64 octets in length. In existing implementations > a AAA server acting as an EAP server transports the MSK > to the authenticator. > > Extended Master Session Key (EMSK) > Additional keying material derived between the EAP client > and server that is exported by the EAP method. The EMSK > is at least 64 octets in length. The EMSK is reserved > for future uses that are not defined yet and is not > provided to a third party." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 12 00:15:12 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25149 for ; Fri, 12 Sep 2003 00:15:02 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9ECD35804F9; Thu, 11 Sep 2003 23:15:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id E21A4580449 for ; Thu, 11 Sep 2003 23:14:48 -0500 (CDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id h8C4Eilb002858; Fri, 12 Sep 2003 13:14:44 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id h8C4EiMD026377; Fri, 12 Sep 2003 13:14:44 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id PAA26376 ; Fri, 12 Sep 2003 13:14:44 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id NAA05630; Fri, 12 Sep 2003 13:14:43 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id NAA27125; Fri, 12 Sep 2003 13:14:43 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id h8C4EhWb000240; Fri, 12 Sep 2003 13:14:43 +0900 (JST) Received: from localhost ([159.119.168.69]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HL300CA82GGQK@tsbpo1.po.toshiba.co.jp>; Fri, 12 Sep 2003 13:14:42 +0900 (JST) From: Yoshihiro Ohba Subject: Re: [eap] Issue 171: IKEv2 over TCP In-reply-to: To: Bernard Aboba Cc: eap@frascone.com Message-id: <20030912041355.GC18316@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 46 References: Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 11 Sep 2003 21:13:55 -0700 I also found that "SHOULD" was replaced with "MAY". I like this replacement as well as the replacement of IKEv2 reference to PIC, because I think lower-layer retranmission conflicts with silent discarding of invalid messages in EAP (as I pointed out recently). Yoshihiro Ohba On Thu, Sep 11, 2003 at 04:33:46PM -0700, Bernard Aboba wrote: > Issue 171: IKEv2 over TCP > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: 9/11/2003 > Reference: > Document: EAP-05 > Comment type: T > Priority: S > Section: 2.2, 4.3 > Rationale/Explanation of issue: > > IKEv2 runs over UDP, not TCP as implied in Section 2.2 and 4.3. > > In Section 2.2, change: > > "TCP [IKEv2]" to "TCP [PIC]". > > In Section 4.3, change: > > " When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as > within [IKEv2]), the authenticator retransmission timer SHOULD be set > to an infinite value, so that retransmissions do not occur at the EAP > layer. The peer may still maintain a timeout value so as to avoid > waiting indefinitely for a Request." > > To: > > " When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as > within [PIC]), the authenticator retransmission timer MAY be set > to an artificially high value, so that retransmissions do not occur > at the EAP layer. The peer may still maintain a timeout value so > as to avoid waiting indefinitely for a Request." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 12 11:17:16 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28149 for ; Fri, 12 Sep 2003 11:17:03 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8861B5804F9; Fri, 12 Sep 2003 10:17:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 31BC1580449 for ; Fri, 12 Sep 2003 10:16:09 -0500 (CDT) Received: from cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 12 Sep 2003 08:16:08 -0700 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8CFG69F026181; Fri, 12 Sep 2003 08:16:06 -0700 (PDT) Received: from gwzw2k (sjc-vpn1-242.cisco.com [10.21.96.242]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id IAA09653; Fri, 12 Sep 2003 08:16:05 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Bernard Aboba'" Cc: Subject: RE: [eap] Issue 174: Mandatory to Implement Organization: Cisco Systems Message-ID: <01ef01c37940$c60092a0$e79e4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 12 Sep 2003 08:15:29 -0700 Content-Transfer-Encoding: 7bit > Issue 174: Mandatory to Implement > Submitter name: Dorothy Stanley > Submitter email address: dstanley@agere.com > Date first submitted: 9/11/2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-September/001657.html > Document: EAP-05 Comment type: T > Priority: S > Section: 5, 5.4 > Rationale/Explanation of issue: > > It seems wasteful to require an EAP peer to implement the > EAP MD5-Challenge method, even in situations (such as > IEEE 802.11i) where mutual authentication is required. Can > we relax this requirement? The obvious problem is that this leaves EAP as essentially an empty framework, removing the basis for any but purely formal interoperability. In addition, since AFAIK 802.11i doesn't specify any EAP method as mandatory (relying instead upon RFC 2284), it leaves them in the same boat. Is this really desirable? > > In Section 5, change: > > "All EAP implementations MUST support Types 1-4, which are defined in > this document, and SHOULD support Type 254. Implementations MAY > support other Types defined here or in future RFCs." > > To: > > "All EAP server implementations MUST support Types 1-4, which are > defined in this document, and SHOULD support Type 254. EAP peer > implementations which support physically secure lower layers MUST > support types 1-4, and SHOULD support Type 254. EAP Peer > implementations which only support physically insecure lower layers > requiring mutual authentication MAY NOT support Type 4 (EAP > MD5-Challenge). An authenticator that supports only pass-through MUST > allow communication with a backend authentication server that is > capable of supporting Type 4 (MD5-Challenge), although the > implementation need not support MD5-Challenge itself. However, if the > EAP authenticator can be configured to authenticate peers locally > (e.g., not operate in pass-through), then it MUST support Type 4 > (MD5-Challenge). Implementations MAY support other Types defined here > or in future RFCs." > > Delete the following from Section 5.4: > > "EAP peer and EAP server implementations MUST support the > MD5-Challenge mechanism. An authenticator that supports only > pass-through MUST allow communication with a backend authentication > server that is capable of supporting MD5-Challenge, although the EAP > authenticator implementation need not support MD5-Challenge itself. > However, if the EAP authenticator can be configured to authenticate > peers locally (e.g., not operate in pass-through), then the > requirement for support of the MD5-Challenge mechanism applies." > _______________________________________________ eap mailing list > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 12 13:15:07 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05447 for ; Fri, 12 Sep 2003 13:15:01 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B432D5804F9; Fri, 12 Sep 2003 12:15:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 9664A580449 for ; Fri, 12 Sep 2003 12:14:13 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8CGfb131804; Fri, 12 Sep 2003 09:41:37 -0700 From: Bernard Aboba To: Glen Zorn Cc: eap@frascone.com Subject: RE: [eap] Issue 174: Mandatory to Implement In-Reply-To: <01ef01c37940$c60092a0$e79e4104@amer.cisco.com> Message-ID: References: <01ef01c37940$c60092a0$e79e4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 12 Sep 2003 09:41:37 -0700 (PDT) > The obvious problem is that this leaves EAP as essentially an empty > framework, removing the basis for any but purely formal > interoperability. In addition, since AFAIK 802.11i doesn't specify any > EAP method as mandatory (relying instead upon RFC 2284), it leaves them > in the same boat. Is this really desirable? Since EAP MD5-Challenge is already illegal for use with IEEE 802.11i, they are already in this predicament, no? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 12 13:25:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05776 for ; Fri, 12 Sep 2003 13:24:56 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B45345804F9; Fri, 12 Sep 2003 12:25:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 2BF69580449 for ; Fri, 12 Sep 2003 12:24:13 -0500 (CDT) Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 12 Sep 2003 10:24:13 -0700 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8CHOAbs010589; Fri, 12 Sep 2003 10:24:10 -0700 (PDT) Received: from gwzw2k (sjc-vpn1-242.cisco.com [10.21.96.242]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id KAA27418; Fri, 12 Sep 2003 10:24:09 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Bernard Aboba'" Cc: Subject: RE: [eap] Issue 174: Mandatory to Implement Organization: Cisco Systems Message-ID: <020401c37952$a9a0e940$e79e4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 12 Sep 2003 10:23:33 -0700 Content-Transfer-Encoding: 7bit Bernard Aboba writes: >> The obvious problem is that this leaves EAP as essentially an empty >> framework, removing the basis for any but purely formal >> interoperability. In addition, since AFAIK 802.11i doesn't specify >> any EAP method as mandatory (relying instead upon RFC 2284), it >> leaves them in the same boat. Is this really desirable? > > Since EAP MD5-Challenge is already illegal for use with IEEE 802.11i, > they are already in this predicament, no? Is the use of EAP MD5-Challenge actually illegal or just ill-advised? ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 12 14:02:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07238 for ; Fri, 12 Sep 2003 14:01:57 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CFD55804F9; Fri, 12 Sep 2003 13:02:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 42FD5580449 for ; Fri, 12 Sep 2003 13:01:31 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8CHStS02041; Fri, 12 Sep 2003 10:28:55 -0700 From: Bernard Aboba To: Glen Zorn Cc: eap@frascone.com Subject: RE: [eap] Issue 174: Mandatory to Implement In-Reply-To: <020401c37952$a9a0e940$e79e4104@amer.cisco.com> Message-ID: References: <020401c37952$a9a0e940$e79e4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 12 Sep 2003 10:28:55 -0700 (PDT) > Is the use of EAP MD5-Challenge actually illegal or just ill-advised? I believe that it's illegal -- mutual authentication is required. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 12 14:24:11 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08775 for ; Fri, 12 Sep 2003 14:24:03 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 425435804F9; Fri, 12 Sep 2003 13:24:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id B9697580449 for ; Fri, 12 Sep 2003 13:24:00 -0500 (CDT) Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 12 Sep 2003 11:24:00 -0700 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8CINvS4005363; Fri, 12 Sep 2003 11:23:58 -0700 (PDT) Received: from gwzw2k (sjc-vpn1-242.cisco.com [10.21.96.242]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id LAA04417; Fri, 12 Sep 2003 11:23:57 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Bernard Aboba'" Cc: Subject: RE: [eap] Issue 174: Mandatory to Implement Organization: Cisco Systems Message-ID: <021501c3795b$044bfee0$e79e4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 12 Sep 2003 11:23:21 -0700 Content-Transfer-Encoding: 7bit Bernard Aboba writes: >> Is the use of EAP MD5-Challenge actually illegal or just ill-advised? > > I believe that it's illegal -- mutual authentication is required. That's too bad. Is there any reason we need to get ourselves in the same predicament (other than reducing code size for 802.11 implementers? ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Sep 14 05:19:20 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24998 for ; Sun, 14 Sep 2003 05:19:08 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3AD7E580022; Sun, 14 Sep 2003 04:19:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 5B07C580021 for ; Sun, 14 Sep 2003 04:18:24 -0500 (CDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h8E9I5ZQ021717 for ; Sun, 14 Sep 2003 09:18:06 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8E9D1W29302 for ; Sun, 14 Sep 2003 09:13:01 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003091402181925446 ; Sun, 14 Sep 2003 02:18:19 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 14 Sep 2003 02:18:19 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Issue 174: Mandatory to Implement X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: Thread-Topic: [eap] Issue 174: Mandatory to Implement Thread-Index: AcN5Ut070uIJr7sqRHeBCMBM9nXMYgBTjgcg From: "Walker, Jesse" To: , "Bernard Aboba" Cc: X-OriginalArrivalTime: 14 Sep 2003 09:18:19.0416 (UTC) FILETIME=[23207980:01C37AA1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 14 Sep 2003 02:18:19 -0700 Content-Transfer-Encoding: quoted-printable Ill advised. EAP methods are outside the scope of the 802.11i PAR. > -----Original Message----- > From: Glen Zorn [mailto:gwz@cisco.com] > Sent: Friday, September 12, 2003 10:24 AM > To: 'Bernard Aboba' > Cc: eap@frascone.com > Subject: RE: [eap] Issue 174: Mandatory to Implement >=20 >=20 > Bernard Aboba writes: >=20 > >> The obvious problem is that this leaves EAP as essentially an empty > >> framework, removing the basis for any but purely formal > >> interoperability. In addition, since AFAIK 802.11i doesn't specify > >> any EAP method as mandatory (relying instead upon RFC 2284), it > >> leaves them in the same boat. Is this really desirable? > >=20 > > Since EAP MD5-Challenge is already illegal for use with=20 > IEEE 802.11i, > > they are already in this predicament, no?=20 >=20 > Is the use of EAP MD5-Challenge actually illegal or just ill-advised? >=20 > ~gwz >=20 > "They that can give up essential liberty to obtain a little temporary > safety deserve neither..."=20 > -- Benjamin Franklin, 1759 >=20 > "It is forbidden to kill; therefore all murderers are punished unless > they kill in large numbers and to the sound of trumpets."=20 > -- Voltaire >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Sep 14 05:21:10 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25047 for ; Sun, 14 Sep 2003 05:20:58 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9F773580025; Sun, 14 Sep 2003 04:21:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 6A3A5580025 for ; Sun, 14 Sep 2003 04:20:25 -0500 (CDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h8E9K9ZQ022416 for ; Sun, 14 Sep 2003 09:20:09 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8E9F4W29895 for ; Sun, 14 Sep 2003 09:15:04 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003091402202200240 ; Sun, 14 Sep 2003 02:20:22 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 14 Sep 2003 02:20:22 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Issue 174: Mandatory to Implement X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: Thread-Topic: [eap] Issue 174: Mandatory to Implement Thread-Index: AcN5WADt7Iu/hB/lSJ27unvC0fQMUABSTgsw From: "Walker, Jesse" To: "Bernard Aboba" , "Glen Zorn" Cc: X-OriginalArrivalTime: 14 Sep 2003 09:20:22.0608 (UTC) FILETIME=[6C8E1500:01C37AA1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 14 Sep 2003 02:20:22 -0700 Content-Transfer-Encoding: quoted-printable Bernard, The 802.11i drafts says that it assumes mutual authentication, but it = can't require that people respect this assumption. People won't, and = they will reap the consequences. -- Jesse > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Friday, September 12, 2003 10:29 AM > To: Glen Zorn > Cc: eap@frascone.com > Subject: RE: [eap] Issue 174: Mandatory to Implement >=20 >=20 > > Is the use of EAP MD5-Challenge actually illegal or just=20 > ill-advised? >=20 > I believe that it's illegal -- mutual authentication is required. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Sep 14 19:09:22 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17440 for ; Sun, 14 Sep 2003 19:09:10 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4A2E9580021; Sun, 14 Sep 2003 18:09:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id AB1CE58001E for ; Sun, 14 Sep 2003 18:08:39 -0500 (CDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8EN8Hd16590 for ; Sun, 14 Sep 2003 19:08:17 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h8ENAMS14816 for ; Sun, 14 Sep 2003 19:10:27 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h8EN7mpZ010719 for ; Sun, 14 Sep 2003 19:07:52 -0400 To: eap@frascone.com Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <10718.1063580868@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Subject: [eap] questions about PRF in eap-sim-11.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 14 Sep 2003 19:07:48 -0400 -----BEGIN PGP SIGNED MESSAGE----- Section 17, page 50, says: Key derivation is based on the random number generation specified in NIST Federal Information Processing Standards (FIPS) Publication 186-2 [12]. The pseudo-random number generator is specified in the change notice 1 (2001 October 5) of [12] (Algorithm 1). As specified in the change notice (page 74), when Algorithm 1 is used as a general-purpose pseudo-random number generator, the "mod q" term in step 3.3 is omitted. The function G used in the algorithm is constructed via Secure Hash Standard as specified in Appendix 3.3 of * the standard. For convenience, the random number algorithm with the correct modification is cited in Annex B. 160-bit XKEY and XVAL values are used, so b = 160. On each full authentication, the Master Key is used as the initial secret seed- key XKEY. The optional user input values (XSEED_j) in step 3.1 are set to zero. May I suggest that annex B be actually fully edited to reflect all of these settings? In *, I assume it is a reference to 186-2? We need a total of K_encr(128 bits), K_aut(128 bits), MSK(64 bytes), EMSK(64 bytes). A total of 1280 bytes, or m = 4. So, the algorithm would become: let XKEY := MK, XSEED_j := 0 Step 3: For j = 0 to 3 do a. XVAL = XKEY b. w_0 = SHA1(XVAL) c. XKEY = (1 + XKEY + w_0) mod 2^160 d. XVAL = XKEY e. w_1 = SHA1(XVAL) f. XKEY = (1 + XKEY + w_1) mod 2^160 3.3 x_j = w_0|w_1 Assuming that I'm correct, I would strongly suggest that this be documented in this way. This makes it trivial to code without wandering through 150 pages of FIPS documents. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP2T0rYqHRg3pndX9AQENtgP/ep9cRmhDycJOrq9M3HYBncKOJBRBxsgK MZoutlwGJ2oXdQZRTaRaPkDdDnCnOLIiwvonucG0OfRz1AB6gmodZU+Zm3wpXjTM y0ymFKFnyjTdw+wpHfaOHDqu2XMRBA9sBbcVRUbOF/qlXgyyjcRYzf/oj5ORF1O/ 7zxY5Up3Kn4= =D0m6 -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Sep 14 22:53:10 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24416 for ; Sun, 14 Sep 2003 22:53:01 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 924F6580021; Sun, 14 Sep 2003 21:53:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 5F75F58001E for ; Sun, 14 Sep 2003 21:52:07 -0500 (CDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h8F2ppZQ009518 for ; Mon, 15 Sep 2003 02:51:51 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8F2BlL27022 for ; Mon, 15 Sep 2003 02:11:47 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003091419520129523 ; Sun, 14 Sep 2003 19:52:01 -0700 Received: from orsmsx401.amr.corp.intel.com ([192.168.65.207]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 14 Sep 2003 19:52:02 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [eap] Issue 174: Mandatory to Implement Message-ID: Thread-Topic: [eap] Issue 174: Mandatory to Implement Thread-Index: AcN5QQM/Qfyqx87FQSuJPEeS7qUc0QB8t2nw From: "Walker, Jesse" To: , "Bernard Aboba" Cc: X-OriginalArrivalTime: 15 Sep 2003 02:52:02.0018 (UTC) FILETIME=[56BBF420:01C37B34] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 14 Sep 2003 19:52:01 -0700 Content-Transfer-Encoding: quoted-printable The right thing to do is to replace MD5 challenge as the = mandatory-to-implement method. This will cause problems--it always = does--but that's just how it is. To serve the future EAP must cut ties = that are holding it in the past. > > It seems wasteful to require an EAP peer to implement the > > EAP MD5-Challenge method, even in situations (such as > > IEEE 802.11i) where mutual authentication is required. Can > > we relax this requirement? >=20 > The obvious problem is that this leaves EAP as essentially an empty > framework, removing the basis for any but purely formal > interoperability. In addition, since AFAIK 802.11i doesn't=20 > specify any > EAP method as mandatory (relying instead upon RFC 2284), it=20 > leaves them > in the same boat. Is this really desirable? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 15 04:57:18 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18292 for ; Mon, 15 Sep 2003 04:57:06 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0EB33580025; Mon, 15 Sep 2003 03:57:04 -0500 (CDT) Delivered-To: eap@frascone.com Received: from filter2.kt.co.kr (unknown [147.6.42.146]) by mail.frascone.com (Postfix) with ESMTP id F25FB580021 for ; Mon, 15 Sep 2003 03:56:31 -0500 (CDT) Received: from external ([147.6.9.133]) by filter2 (1.0) id h8F8sWE45837; Mon, 15 Sep 2003 17:54:32 +0900 From: "DongGook Park" To: "Jose Puthenkulam" Cc: "EAP mailing list" Message-ID: <000101c37b67$3d29bfa0$85090693@DongGookPark> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [eap] A few comments on draft-puthenkulam-eap-binding-03.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Sep 2003 17:56:18 +0900 Content-Transfer-Encoding: 7bit Dear Jose Puthenkulam, I have some comments and questions with regard to your recent IETF draft entitled " The Compound Authentication Binding Problem" (draft-puthenkulam-eap-binding-03.txt), which you can find below in this mail. Best regards, DongGook Park ===================================== Information Security Research Division Korea Telecom 17 WooMyeon-Dong SeoCho-Gu Seoul 137-792 Korea, South Telephone: +82 2 526 6173 Email: dgpark6@kt.co.kr Homepage: http://home.naver.com/dgpark6/ ===================================== ###### A few comments on draft-puthenkulam-eap-binding-03.txt ####### This draft describes MITM attacks against tunneled authentication protocols, and proposes some countermeasures. I've found a bit misleading descriptions from the draft: 1. [Comment] On page 15, the draft describes the Binding Phase Exchange with compound keyed MACs. The draft reads "... The validation of the compound protects against the MITM attack, as the attacker is unable to get any of the inner method keys. ..." This description seems to be rather misleading... As far as I understand, the attack cannot succeed not because the attacker is not able to access the inner method keys, but because the new additional message exchange of "Binding Phase" is not expected message from the viewpoint of the victim entity. For the victim entity has simply executed a legacy authentication protocol (not as an inner protocol of the tunneled authentication protocol) which does not include the additional Binding Phase exchange. 2. [Comment] On page 18, before the start of Section 3,4, the authors argue that "Stage 2" is REQUIRED for additional protection on top of "Stage 1" protection. Strangely, however, the draft does not explain why it is the case, but rather they only emphasize the importance of "Stage 1" countermeasure and the insufficiency of "Stage 2" being used alone... I think, rather, readers would expect why the additional countermeasure "Stage 2" is used on top of the essential protection "Stage 1". By the way, I don't see why Stage 2 is necessary in addition to Stage 1 as far as the man-in-the-middle attack is concerned. IMHO, each stage can be considered as a selective countermeasure; Stage 1 as a full-blown costly fix (due to additional messages and hence some relevant addition/modification to existing EAP protocols), and Stage 2 as a lightweight solution which does not entail message addition/modification, a penalty of which is some delayed detection of whether a MITM attack has occurred or not. 3. [Question] On page 17, Section 3.5 "Solution approaches", the first proposed approach for accommodation of Stage 1 or 2 (the draft, in fact, describes only the case with "Stage 1") is to "implement the binding phase exchange as a new EAP method". Does this mean that we need to have something like EAP-BindingPhaseExchange in addition to e.g. EAP-TTLS? 4. [Question] On page 13, Section 3.2 "Solution Concepts", the description headed by "[S1]" argues that cryptographic binding solution will not work for "non-key-deriving methods" without breaking at least one of the solution criteria given in the draft. Most probably, password-based authentication protocols such as CHAP will correspond to the non-key-deriving methods. But why? Are we not allowed to use the password instead of the inner method key in the case of the situation where any inner key is not available from the inner protocol? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 15 13:59:07 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15696 for ; Mon, 15 Sep 2003 13:59:01 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF933580109; Mon, 15 Sep 2003 12:59:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 0ACEF580029 for ; Mon, 15 Sep 2003 12:58:52 -0500 (CDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 216AE6A903; Mon, 15 Sep 2003 20:58:50 +0300 (EEST) Message-ID: <3F65FD19.70706@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Cc: Bernard Aboba Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] EAP WG interim meeting, Oct 15th, 2003 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Sep 2003 20:55:37 +0300 Content-Transfer-Encoding: 7bit The following notice was sent to the ietf announce list: In order to ensure that the EAP Key Framework document is in sync with IEEE 802.11i, ian EAP WG interim meeting will be held coincident with the IEEE 802.11i interim meeting planned to take place in Herndon, VA. The date is October 15, 2003. The agenda for the meeting will be as follows: 1. EAP keying framework issues - naming - binding - key transport - system level security considerations - other EAP keying issues 2. Synchronization of EAP WG and 802.11i documents. 3. Possible other synchronization issues between EAP WG and 802.11i. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 15 15:37:15 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22365 for ; Mon, 15 Sep 2003 15:37:02 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0EDC5580109; Mon, 15 Sep 2003 14:37:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id 13653580029 for ; Mon, 15 Sep 2003 14:36:58 -0500 (CDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8FJand23146; Mon, 15 Sep 2003 15:36:49 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h8FJcij11457; Mon, 15 Sep 2003 15:38:49 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h8FJaDxC010354; Mon, 15 Sep 2003 15:36:13 -0400 To: eap , freeradius-users Cc: mah@eunet.at Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <10353.1063654573@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Subject: [eap] non-wire related comments on eap-sim-11.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Sep 2003 15:36:13 -0400 -----BEGIN PGP SIGNED MESSAGE----- A1) please include real packet dumps, including encrypted data with keys, to help people. A2) There is no per-attribute description/reference. -> AT_VERSION_LIST for instance has no reference. A3) paragraph 1 of 5.2. This conversation seems totally out of place, and very confusing. A4) The definitions of the attributes seems to be partially defined only in the scenarios of sections 9-15. I would rather the attributes were defined seperately from the messages in which they are used. Otherwise, it appears that one has to code per-message marshalling/etc. It is hard to tell if this is true or not. A5) It was not at all obvious that the AT_MAC is a keyed operation. The last sentence of 8.1 says so, but I missed it at least twice, thinking, but, it must be keyed, I remembered reading about it. Maybe this is just the way that I read the document. A5b) Annex A/B might be a little more detailed. In particular, I think that you have chosen G to be SHA1, but I'm not particularly certain. Nor do I understahe what "m" is, or what the "optional user input" is in this context. A6) split normative and informative references. A7) section 3, overview, para 3. It seemed that this was the only place that the value of the Start subtype was clearly stated. A8) section 5.1, page 9, > In this case, the permanent username MUST be of the format "1imsi". It took me awhile to understand that the thing in quotes is a pattern, not a string. Please remove "", or use another notation. A9) section 5.1, page 9, para 4. This seems really nebulous. A10) section 5.2, first paragraph. It seems that you are putting the most complicated "gotcha" at the beginning. At this point, I don't even know what you are talking about yet! A11) time-sequence diagrams. They are simply not useful to me. They just seem to take lots of space. They are useful when there are more than two parties. A12) section 5.1, 5.2 and 5.3 should have *NO* mention of re-authentication. Please describe the base protocol first, (including state machines), and then give the version that supports re-authentication. A13) section 5.3, page 15, para 7. " A received AT_PERMANENT_ID_REQ does not necessarily originate from " The advice given seems very complicated and very dubious to me. I believe that this must come out from the client state machine. A14) section 6. Caveat: I read this much less carefully. page 22, para 4: " Re-authentication identities are one-time identities. If the client does not receive a new re-authentication identity, it MUST use either the permanent identity or a pseudonym identity on the next authentication to initiate full authentication. " Given that the identity is involved in the AT_MACs, are there any cryptographic restrictions on the one-time identities? A15) section 7. basic format. What if length == 0. Malformed packet. Then what? A16) section 7. 0/127, 128-255 as "skippable". I recommend that you adopt the terminology from IKEv2. The high bit is the "critical" bit (or in this case, the "non-critical" bit). A17) section 8.2. AT_CHECKCODE. This whole concept seems very fragile to me. In particular, the whole concept of round trips could be much better explained. Remember that there are multiple entities that re-transimit: 802.11, LCP, Radius, etc. EAP re-transmits seem to be server driven. Radius re-transmits are client driven. A18) Is AT_CHECKCODE cumulative, or does it just protect the SIM/Start message? A19) What if it is known that the encapsulator provides integrity protection and privacy? I.e. IKEv2? A20) section 10. I'd like to see real numbers in the entire packet. Hex dumps. The code/id/Length/etc. break out seems to take way more white space that it provides value. A21) re: AT_NEXT_PSEUDONYM, and I guess identities in general. What about UTF-8? Internationalization? A22) section 18. This seems to be the only place that there is a table of values. I guess that is okay, but I found it hard to find. I'd like to see a table with brief explanations of each attribue back in section 10 or earlier. A23) security considerations seem very well written. Good work! A24) Annex B. I found it to be clear as MUD. I guess I don't code very often to FIPS documents, are they all so obtuse? C code for this PRF would be welcome, along with test vectors. When I get mine working, I'll be happy to contribute them. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP2YUp4qHRg3pndX9AQFIHAP+KQgZHhvCtMe8FQc36Mp/0nbO8ISOzHx3 ruoDdA4jmZCyIwtftP1XqVuWP+Kjr40gl63gaqFpqmglQTj9j1f5lyQlsNPGMrfj 2ndNlhGN7HigTgkmOFWkeyzHXNfmcA2IVUZv7ev2CBKBqo98H0N01xHrne1XyKTS SdSAyzz8SWw= =JIMR -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 15 15:41:07 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22654 for ; Mon, 15 Sep 2003 15:40:59 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 33FE3580109; Mon, 15 Sep 2003 14:41:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id 5586C580029 for ; Mon, 15 Sep 2003 14:40:32 -0500 (CDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8FJeOd23175; Mon, 15 Sep 2003 15:40:24 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h8FJgKj11601; Mon, 15 Sep 2003 15:42:25 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h8FJdnsK010442; Mon, 15 Sep 2003 15:39:49 -0400 To: eap , freeradius-users Cc: mah@eunet.at Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <10441.1063654789@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Subject: [eap] wire related comments on eap-sim-11.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Sep 2003 15:39:49 -0400 -----BEGIN PGP SIGNED MESSAGE----- B1) why is the TLV format different from the RADIUS one? The length is the only difference. (being /4) How often do we need attributes longer than 253 bytes? What happens if the length is 0? (Yeah, it is illegal, but why have such a situation) The 4* the length is there so that one can have 1022 byte attributes. These don't fit into single EAP-Message payloads in radius, is the situation better in LCP? The 4* length seems to simply result in there needing to be another length in many packets. That probably cancels any advantage in encoding the length as a byte. The rounding up to 32-bit size also seems to waste a lot of bytes needlessly - the EAP messages won't be aligned when they arrive in at a radius server, which is likely the end that will biggest load due to EAP messages, so why bother here? I suggest that the TLV format be junked in favour of one that is either identical to PPP or identical to radius. This is gratuitously different. B2) why are there boath IV and ENCR attribues? Just put the IV at the front of cipher text. This makes much more sense. B4) It appears that AT_FULLAUTH_ID_REQ, PERMANEND_ID_REQ and ANY_ID_REQ are always mutually exclusive. I strongly suggest that there be an "ID_REQ" attribute, with three values: FULLAUTH/PERMANENT/ANY In fact, these three cases seem like they are really three different "Start" situations, and I suggest that they be turned into three "Start" messages. This would be much easier to document and analyze. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP2YVg4qHRg3pndX9AQHJ4AQA3AyXhRBKcc1QKkZOVseHCLrHm9DRvw8R VAJks6LkITUzJiVz6iKzcpFs+bBc1vUL/WY4gSE1NOrzEOV7wy1cZPUfmP0tZp7+ zMPlF1K0W5EzIBQAbmI5SyBpWDQklTOoIFxH8kzPwueiQODHt9468FY4cwmnEhZ3 yp2NiJMoZlA= =w42y -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 15 15:59:25 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23342 for ; Mon, 15 Sep 2003 15:59:04 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4774A580109; Mon, 15 Sep 2003 14:59:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id C5711580029 for ; Mon, 15 Sep 2003 14:58:58 -0500 (CDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8FJwwd23227 for ; Mon, 15 Sep 2003 15:58:58 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h8FK13j12322 for ; Mon, 15 Sep 2003 16:01:08 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h8FJwXIA010853 for ; Mon, 15 Sep 2003 15:58:33 -0400 To: eap In-reply-to: Your message of "Mon, 15 Sep 2003 15:36:13 EDT." <10353.1063654573@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <10852.1063655913@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Subject: [eap] my Issue A12 - state machines - server side Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Sep 2003 15:58:33 -0400 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Michael" == Michael Richardson writes: Michael> A12) section 5.1, 5.2 and 5.3 should have *NO* mention of Michael> re-authentication. Please describe the base protocol first, Michael> (including state machines), and then give the version that Michael> supports re-authentication. I have implemented basic authentication so far. As such, my state machines are incomplete, but even so, there are a number of holes and questions that are not easily determined from reading the document. In particular, as I'm writing this, I realize that the EAP-business of dealing with retransmits in IDs is probably best made explicit in new states. Obviously, I have not taken into account any notifications. I suggest text based upon what I write here. I.e. in this style. I can write similar text for the client. The server seems to have three states in my implementation: 1) START 2) CHALLENGE 3) SUCCESS 0) Upon recognizing the user as an EAP-SIM, the server transitions into the START state. This is done upon receipt of an EAP/Identity message detailing a user who should be using EAP-SIM. (EAP may have other state that it goes through to get here) 1) START The transition into the START state will result in transmitting an EAP-Request/Sim/Start message. When in state "Start", the following messages may be received: a) An EAP-Response/Sim/Start. i) Verify selected version is compatible and presence of NONCE_MT, and transition to 2) CHALLENGE. **** ii) upon failure to verify - ???? b) An EAP/Identity message. Transition to 1) START. **** c) OTHER MESSAGES - unsure. Transition to 1) START ???? 2) CHALLENGE The transition into the CHALLENGE state will result in an EAP-Request/Sim/Challenge message being sent. {Existing RAND challenges should be used if this user has not completed the state yet. The EAP ID should not be updated} When in state "Challenge", the following messages may be received: a) an EAP-Response/Sim/Start i) Verify selected version is compatible and presence of NONCE_MT, and transition to 2) CHALLENGE. **** ii) upon failure to verify - ???? b) an EAP-Response/Sim/Challenge i) verify AT-MAC. If valid, transition to 3) SUCCESS. **** ii) If AT-MAC failes then ???? **** c) an EAP/Identity message. Transition to 1) START ???? d) OTHER MESSAGES - unsure. Drop? 3) SUCCESS The transition into the SUCCESS state will result in an EAP-Success message being sent. When in state SUCCESS, receipt of any message results in a transition back to (0). ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP2YZ4oqHRg3pndX9AQGRtwP/fjIjpcpnRKHpNwpaoDgfwpDc1FaokGur 3PmJfoK5ht1NB0NZFl5Kk91eLlN1Eu0DHeLennuvFD455IbCzmY8VA/24OnuE19T nqw9IQ+LBewpfH4rKOSjT3uUjH+QhMpKNCuP2T0dE1oov4OuSoUqclDG62CWIKun CINaaIPOzQs= =X4EW -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 15 19:30:35 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02029 for ; Mon, 15 Sep 2003 19:30:11 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9BB6F580109; Mon, 15 Sep 2003 18:30:05 -0500 (CDT) Delivered-To: eap@frascone.com Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id A5C31580029 for ; Mon, 15 Sep 2003 18:29:06 -0500 (CDT) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8FNT3fX011535; Mon, 15 Sep 2003 16:29:03 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.99.6]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Sep 2003 16:33:27 -0700 From: "Joseph Salowey" To: "'Michael Richardson'" , Subject: RE: [eap] questions about PRF in eap-sim-11.txt Message-ID: <012e01c37be1$258754f0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <10718.1063580868@marajade.sandelman.ottawa.on.ca> X-OriginalArrivalTime: 15 Sep 2003 23:33:27.0962 (UTC) FILETIME=[C3D107A0:01C37BE1] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Sep 2003 16:29:01 -0700 Content-Transfer-Encoding: 7bit Unfortunately this is not quite as trivial as it seems. The NIST documents are confusing. Although the function G is derived from SHA-1 my interpretation of FIPS 186-2 Appendix 3.3 is that it is slightly different. In particular in SHA-1 the length is appended to the message and in function G it is not. The message block processed by SHA-1 is XKEY plus zero padding out to 512 bits with no message length appended. This also seems to be supported by the test vectors listed in: http://csrc.nist.gov/CryptoToolkit/dss/Examples-1024bit.pdf In re-reading the NIST specs I have to say that this is not all that clear. We definitely need to include a better description in the appendix and some test vectors. If you have a simpler way of expressing this it would be great (or if you find that the spec actually uses unmodified SHA-1). Thanks, Joe > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Michael Richardson > Sent: Sunday, September 14, 2003 4:08 PM > To: eap@frascone.com > Subject: [eap] questions about PRF in eap-sim-11.txt > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Section 17, page 50, says: > > Key derivation is based on the random number generation > specified in > NIST Federal Information Processing Standards (FIPS) Publication > 186-2 [12]. The pseudo-random number generator is specified in the > change notice 1 (2001 October 5) of [12] (Algorithm 1). As > specified > in the change notice (page 74), when Algorithm 1 is used as a > general-purpose pseudo-random number generator, the "mod > q" term in > step 3.3 is omitted. The function G used in the algorithm is > constructed via Secure Hash Standard as specified in > Appendix 3.3 of > * the standard. For convenience, the random number algorithm > with the > correct modification is cited in Annex B. > > 160-bit XKEY and XVAL values are used, so b = 160. On each full > authentication, the Master Key is used as the initial secret seed- > key XKEY. The optional user input values (XSEED_j) in step 3.1 are > set to zero. > > May I suggest that annex B be actually fully edited to > reflect all of these settings? > > In *, I assume it is a reference to 186-2? > > We need a total of K_encr(128 bits), K_aut(128 bits), MSK(64 > bytes), EMSK(64 bytes). A total of 1280 bytes, or m = 4. > > So, the algorithm would become: > > let XKEY := MK, > XSEED_j := 0 > > Step 3: For j = 0 to 3 do > a. XVAL = XKEY > b. w_0 = SHA1(XVAL) > c. XKEY = (1 + XKEY + w_0) mod 2^160 > d. XVAL = XKEY > e. w_1 = SHA1(XVAL) > f. XKEY = (1 + XKEY + w_1) mod 2^160 > 3.3 x_j = w_0|w_1 > > Assuming that I'm correct, I would strongly suggest that this > be documented in this way. This makes it trivial to code > without wandering through 150 pages of FIPS documents. > > ] Out and about in Ottawa. hmmm... beer. > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device > driver[ ] > panic("Just another Debian/notebook using, kernel hacking, > security guy"); [ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Finger me for keys - custom hacks make this fully PGP2 compat > > iQCVAwUBP2T0rYqHRg3pndX9AQENtgP/ep9cRmhDycJOrq9M3HYBncKOJBRBxsgK > MZoutlwGJ2oXdQZRTaRaPkDdDnCnOLIiwvonucG0OfRz1AB6gmodZU+Zm3wpXjTM > y0ymFKFnyjTdw+wpHfaOHDqu2XMRBA9sBbcVRUbOF/qlXgyyjcRYzf/oj5ORF1O/ > 7zxY5Up3Kn4= > =D0m6 > -----END PGP SIGNATURE----- > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 15 23:03:22 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08117 for ; Mon, 15 Sep 2003 23:03:05 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35467580109; Mon, 15 Sep 2003 22:03:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id DF699580029 for ; Mon, 15 Sep 2003 22:02:34 -0500 (CDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8G31vd24495; Mon, 15 Sep 2003 23:01:58 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h8G33wj28006; Mon, 15 Sep 2003 23:04:03 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h8G31LoD020976; Mon, 15 Sep 2003 23:01:21 -0400 To: "Joseph Salowey" Cc: eap@frascone.com Subject: Re: [eap] questions about PRF in eap-sim-11.txt In-reply-to: Your message of "Mon, 15 Sep 2003 16:29:01 PDT." <012e01c37be1$258754f0$0300000a@amer.cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <20975.1063681281@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Sep 2003 23:01:21 -0400 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Joseph" == Joseph Salowey writes: Joseph> Unfortunately this is not quite as trivial as it seems. The NIST Joseph> documents are confusing. Joseph> Although the function G is derived from SHA-1 my interpretation Joseph> of FIPS 186-2 Appendix 3.3 is that it is slightly different. In Joseph> particular in SHA-1 the length is appended to the message and in Joseph> function G it is not. Aha. Thank you for this explanation. After a bit of code reading, I have the following code: (regular sha1.c code...) void SHA1FinalNoLen(unsigned char digest[20], SHA1_CTX* context) { unsigned long i, j; for (i = 0; i < 20; i++) { digest[i] = (unsigned char) ((context->state[i>>2] >> ((3-(i & 3)) * 8) ) & 255); } /* Wipe variables */ i = j = 0; memset(context->buffer, 0, 64); memset(context->state, 0, 20); memset(context->count, 0, 8); #ifdef SHA1HANDSOFF /* make SHA1Transform overwrite it's own static vars */ SHA1Transform(context->state, context->buffer); #endif } /* * we do it in 8-bit chunks, because we have to keep the numbers * in network byte order (i.e. MSB) * * make it a structure so that we can do structure assignments. */ typedef struct onesixty { u_int8_t p[20]; } onesixty; static void onesixty_add_mod(onesixty *sum, onesixty *a, onesixty *b) { u_int32_t s; int i, carry; carry = 0; for(i=19; i>=0; i--) { s = a->p[i] + b->p[i] + carry; sum->p[i] = s & 0xff; carry = s >> 8; } } void fips186_2prf(u_int8_t mk[20], u_int8_t finalkey[160]) { SHA1_CTX context; int j, s; onesixty xval, xkey, w_0, w_1, sum, one; u_int8_t *f; char zeros[64]; /* * let XKEY := MK, * * Step 3: For j = 0 to 3 do * a. XVAL = XKEY * b. w_0 = SHA1(XVAL) * c. XKEY = (1 + XKEY + w_0) mod 2^160 * d. XVAL = XKEY * e. w_1 = SHA1(XVAL) * f. XKEY = (1 + XKEY + w_1) mod 2^160 * 3.3 x_j = w_0|w_1 * */ memcpy(&xkey, mk, sizeof(xkey)); /* make the value 1 */ memset(&one, 0, sizeof(one)); one.p[19]=1; f=finalkey; for(j=0; j<3; j++) { /* a. XVAL = XKEY */ xval = xkey; /* b. w_0 = SHA1(XVAL) */ SHA1Init(&context); memset(zeros, 0, sizeof(zeros)); memcpy(zeros, xval.p, 20); SHA1Transform(context.state, zeros); SHA1FinalNoLen(w_0.p, &context); /* c. XKEY = (1 + XKEY + w_0) mod 2^160 */ onesixty_add_mod(&sum, &xkey, &w_0); onesixty_add_mod(&xkey, &sum, &one); /* d. XVAL = XKEY */ xval = xkey; /* e. w_1 = SHA1(XVAL) */ SHA1Init(&context); memset(zeros, 0, sizeof(zeros)); memcpy(zeros, xval.p, 20); SHA1Transform(context.state, zeros); SHA1FinalNoLen(w_1.p, &context); /* f. XKEY = (1 + XKEY + w_1) mod 2^160 */ onesixty_add_mod(&sum, &xkey, &w_1); onesixty_add_mod(&xkey, &sum, &one); /* now store it away */ memcpy(f, &w_0, 20); f += 20; memcpy(f, &w_1, 20); f += 20; } } ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP2Z8/4qHRg3pndX9AQFn8QP/RmPkYoPXdBs4oTatJW06+atLAZvlY8E0 wTGD7+v1PQ3lMbl/oMUM2jXzxKCldoljCGtSt/BfynEHsOn1cvdu/KlyI3Fu6+nu 0MqmAo8O/l3/zT5gXb/ARkKirehRzM5pyjLhlLK8CGK4a/e/ic4mQUmlZXap9Ymx 8FMcRvObPOU= =QUyY -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Sep 16 08:17:21 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06434 for ; Tue, 16 Sep 2003 08:16:38 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22F58580109; Tue, 16 Sep 2003 07:15:04 -0500 (CDT) Delivered-To: eap@frascone.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 5557B580029 for ; Tue, 16 Sep 2003 07:14:14 -0500 (CDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GCE9413427 for ; Tue, 16 Sep 2003 15:14:10 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Sep 2003 14:59:26 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 16 Sep 2003 14:59:24 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 16 Sep 2003 14:59:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C37C49.F7E2ADDC" Subject: Re: [eap] questions about PRF in eap-sim-11.txt Message-ID: X-MS-Has-Attach: yes Thread-Topic: [eap] questions about PRF in eap-sim-11.txt Thread-Index: AcN7/z9OZ3xuTaEXSu2zpBD7sRBiZgALrHagAACzjQAABbtl8A== From: To: , Cc: X-OriginalArrivalTime: 16 Sep 2003 11:59:23.0733 (UTC) FILETIME=[F855B850:01C37C49] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Sep 2003 14:59:22 +0300 This is a multi-part message in MIME format. ------_=_NextPart_001_01C37C49.F7E2ADDC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Michael, Please find a test run of an implementation of the NIST PRF=20 below. The details of running the G function are shown in=20 the attachment. It gives the same result as the NIST example,=20 so it should be correct. Thanks to Jukka-Pekka Honkanen for providing the test runs. If you can verify that you get the same results with your implementation, then I think we could use include these test vectors to EAP SIM and EAP AKA drafts. They would be useful in verifying the PRF implementation. Regards, Henry -- # Copied from "Multiple Examples of DSA" = http://csrc.nist.gov/encryption/dss/Examples-1024bit.pdf # Using the revised algorithm found in the Change Notice for the = generation of x values: # XKEY=3D bd029bbe 7f51960b cf9edb2b 61f06f0f eb5a38b6 # XSEED=3D 00000000 00000000 00000000 00000000 00000000 # The first loop through step 3.2 provides: # XVAL=3D bd029bbe 7f51960b cf9edb2b 61f06f0f eb5a38b6 # Using the routine in Appendix 3.3 Constructing The Function G From = SHA-1 # provides: # w[0]=3D 2070b322 3dba372f de1c0ffc 7b2e3b49 8b260614 # The following value is the updated XKEY value from step 3.2.c: # XKEY=3D dd734ee0 bd0bcd3b adbaeb27 dd1eaa59 76803ecb # The second loop through step 3.2 provides: # XVAL=3D dd734ee0 bd0bcd3b adbaeb27 dd1eaa59 76803ecb # Using the routine in Appendix 3.3 Constructing The Function G From = SHA-1 # provides: # w[1]=3D 3c6c18ba cb0f6c55 babb1378 8e20d737 a3275116 # The following value is the updated XKEY value from step 3.2.c: # XKEY=3D 19df679b 881b3991 6875fea0 6b3f8191 19a78fe2 # Step 3.3 provides the following values: # w[0] || w[1]=3D 2070b322 3dba372f de1c0ffc 7b2e3b49 8b260614 # 3c6c18ba cb0f6c55 babb1378 8e20d737 a3275116 frame # This is xkey input to dss_random(). { 0xbd, 0x02, 0x9b, 0xbe, 0x7f, 0x51, 0x96, 0x0b, 0xcf, 0x9e, 0xdb, 0x2b, 0x61, 0xf0, 0x6f, 0x0f, 0xeb, 0x5a, 0x38, 0xb6 } frame # This is the correct output from dss_random(). { 0x20, 0x70, 0xb3, 0x22, 0x3d, 0xba, 0x37, 0x2f, 0xde, 0x1c, 0x0f, 0xfc, 0x7b, 0x2e, 0x3b, 0x49, 0x8b, 0x26, 0x06, 0x14, 0x3c, 0x6c, 0x18, 0xba, 0xcb, 0x0f, 0x6c, 0x55, 0xba, 0xbb, 0x13, 0x78, 0x8e, 0x20, 0xd7, 0x37, 0xa3, 0x27, 0x51, 0x16 } ------_=_NextPart_001_01C37C49.F7E2ADDC Content-Type: application/octet-stream; name="eap_core.log" Content-Description: eap_core.log Content-Disposition: attachment; filename="eap_core.log" Content-Transfer-Encoding: base64 ICAgICAgIDAuMDAxNTA1OiANCiAgICAgICAwLjAwMjAzMTogRFNTIEcgZnVuY3Rpb24gdGVzdCBz dGFydHMuDQogICAgICAgMC4wMDU4MjM6IGlucHV0OiAweDAwMTJlOGIwOiAyMCAoMHgxNCkgYnl0 ZXMNCiAgICAgICAwLjAwNTk3MTogaW5wdXQ6IDB4MDAwMDogYmQwMjliYmUgN2Y1MTk2MGIgY2Y5 ZWRiMmIgNjFmMDZmMGYgICB8Li4uLn9RLi4uLi4rYS5vLnwNCiAgICAgICAwLjAwNjA5NzogaW5w dXQ6IDB4MDAxMDogZWI1YTM4YjYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Llo4LiAg ICAgICAgICAgIHwNCiAgICAgICAwLjAwNjg4ODogZHNzX3BzZXVkb19yYW5kb20oKTogbW9kOiAw eDAwYTU4MjI4OiAyNCAoMHgxOCkgYnl0ZXMNCiAgICAgICAwLjAwNzAxNTogZHNzX3BzZXVkb19y YW5kb20oKTogbW9kOiAweDAwMDA6IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAw ICAgfC4uLi4uLi4uLi4uLi4uLi58DQogICAgICAgMC4wMDcxMzE6IGRzc19wc2V1ZG9fcmFuZG9t KCk6IG1vZDogMHgwMDEwOiAwMDAwMDAwMCAwMTAwMDAwMCAgICAgICAgICAgICAgICAgICAgIHwu Li4uLi4uLiAgICAgICAgfA0KICAgICAgIDAuMDA3MjQ1OiB4a2V5WzBdOiAweDAwMTJlOGIwOiAy MCAoMHgxNCkgYnl0ZXMNCiAgICAgICAwLjAwNzM2MTogeGtleVswXTogMHgwMDAwOiBiZDAyOWJi ZSA3ZjUxOTYwYiBjZjllZGIyYiA2MWYwNmYwZiAgIHwuLi4uf1EuLi4uLithLm8ufA0KICAgICAg IDAuMDA3NjcxOiB4a2V5WzBdOiAweDAwMTA6IGViNWEzOGI2ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfC5aOC4gICAgICAgICAgICB8DQogICAgICAgMC4wMTczNjc6IFdbMF09YmQwMjli YmUNCiAgICAgICAwLjAxNzQ0MDogV1sxXT03ZjUxOTYwYg0KICAgICAgIDAuMDE3NDk0OiBXWzJd PWNmOWVkYjJiDQogICAgICAgMC4wMTc1NDc6IFdbM109NjFmMDZmMGYNCiAgICAgICAwLjAxNzU5 OTogV1s0XT1lYjVhMzhiNg0KICAgICAgIDAuMDE3NjUyOiBXWzVdPTAwMDAwMDAwDQogICAgICAg MC4wMTc3MDQ6IFdbNl09MDAwMDAwMDANCiAgICAgICAwLjAxODAwNDogV1s3XT0wMDAwMDAwMA0K ICAgICAgIDAuMDE4MDU2OiBXWzhdPTAwMDAwMDAwDQogICAgICAgMC4wMTgxMDg6IFdbOV09MDAw MDAwMDANCiAgICAgICAwLjAxODE2MDogV1sxMF09MDAwMDAwMDANCiAgICAgICAwLjAxODIxMjog V1sxMV09MDAwMDAwMDANCiAgICAgICAwLjAxODI2NDogV1sxMl09MDAwMDAwMDANCiAgICAgICAw LjAxODMxNzogV1sxM109MDAwMDAwMDANCiAgICAgICAwLjAxODM3MDogV1sxNF09MDAwMDAwMDAN CiAgICAgICAwLjAxODQyMjogV1sxNV09MDAwMDAwMDANCiAgICAgICAwLjAxODQ3NDogSFswXT0w eDY3NDUyMzAxLCBIWzFdPTB4ZWZjZGFiODksIEhbMl09MHg5OGJhZGNmZSwgSFszXT0weDEwMzI1 NDc2LCBIWzRdPTB4YzNkMmUxZjANCiAgICAgICAwLjAxODUzNDogICAgdAkgICAgICAgQQkgICAg ICAgQgkgICAgICAgQwkgICAgICAgRAkgICAgICAgRQ0KICAgICAgIDAuMDE4NTg5OiB0PTAJNWNi NzM0NzEJNjc0NTIzMDEJN2JmMzZhZTIJOThiYWRjZmUJMTAzMjU0NzYNCiAgICAgICAwLjAxODY1 NDogdD0xCTdjZThmMTQzCTVjYjczNDcxCTU5ZDE0OGMwCTdiZjM2YWUyCTk4YmFkY2ZlDQogICAg ICAgMC4wMTg3MTI6IHQ9MglkYmNiYTRmMwk3Y2U4ZjE0Mwk1NzJkY2QxYwk1OWQxNDhjMAk3YmYz NmFlMg0KICAgICAgIDAuMDE4NzcwOiB0PTMJMDcxNGJiODUJZGJjYmE0ZjMJZGYzYTNjNTAJNTcy ZGNkMWMJNTlkMTQ4YzANCiAgICAgICAwLjAxODgyODogdD00CTYxNzNkOTBiCTA3MTRiYjg1CWY2 ZjJlOTNjCWRmM2EzYzUwCTU3MmRjZDFjDQogICAgICAgMC4wMTg4ODY6IHQ9NQliZTY2MTU3NQk2 MTczZDkwYgk0MWM1MmVlMQlmNmYyZTkzYwlkZjNhM2M1MA0KICAgICAgIDAuMDE4OTQ0OiB0PTYJ ZGU0MDhjZDUJYmU2NjE1NzUJZDg1Y2Y2NDIJNDFjNTJlZTEJZjZmMmU5M2MNCiAgICAgICAwLjAx OTAwMjogdD03CWYzNGMzYzUwCWRlNDA4Y2Q1CTZmOTk4NTVkCWQ4NWNmNjQyCTQxYzUyZWUxDQog ICAgICAgMC4wMTkwNjA6IHQ9OAk1M2VjMjhlZglmMzRjM2M1MAk3NzkwMjMzNQk2Zjk5ODU1ZAlk ODVjZjY0Mg0KICAgICAgIDAuMDE5MTE4OiB0PTkJMmZmNjJlZTIJNTNlYzI4ZWYJM2NkMzBmMTQJ Nzc5MDIzMzUJNmY5OTg1NWQNCiAgICAgICAwLjAxOTE3NjogdD0xMAlmZGIxZTY0ZgkyZmY2MmVl MglkNGZiMGEzYgkzY2QzMGYxNAk3NzkwMjMzNQ0KICAgICAgIDAuMDE5MjM0OiB0PTExCTlkNDI3 MjAzCWZkYjFlNjRmCThiZmQ4YmI4CWQ0ZmIwYTNiCTNjZDMwZjE0DQogICAgICAgMC4wMTkyOTI6 IHQ9MTIJYzk5ZjUzNTgJOWQ0MjcyMDMJZmY2Yzc5OTMJOGJmZDhiYjgJZDRmYjBhM2INCiAgICAg ICAwLjAxOTM1MDogdD0xMwkwMzY1ZThhOAljOTlmNTM1OAllNzUwOWM4MAlmZjZjNzk5Mwk4YmZk OGJiOA0KICAgICAgIDAuMDE5NDA5OiB0PTE0CTRhYWQ1MmQ0CTAzNjVlOGE4CTMyNjdkNGQ2CWU3 NTA5YzgwCWZmNmM3OTkzDQogICAgICAgMC4wMTk0Njc6IHQ9MTUJOTYwZjIyMzUJNGFhZDUyZDQJ MDBkOTdhMmEJMzI2N2Q0ZDYJZTc1MDljODANCiAgICAgICAwLjAxOTUyNTogdD0xNgkxOWJiYjNm Nwk5NjBmMjIzNQkxMmFiNTRiNQkwMGQ5N2EyYQkzMjY3ZDRkNg0KICAgICAgIDAuMDE5NTg0OiB0 PTE3CTE0ODAxNzk5CTE5YmJiM2Y3CTY1ODNjODhkCTEyYWI1NGI1CTAwZDk3YTJhDQogICAgICAg MC4wMTk2NDI6IHQ9MTgJMzg2YzcyYTQJMTQ4MDE3OTkJYzY2ZWVjZmQJNjU4M2M4OGQJMTJhYjU0 YjUNCiAgICAgICAwLjAxOTcwMDogdD0xOQllOTUxY2JiZAkzODZjNzJhNAk0NTIwMDVlNgljNjZl ZWNmZAk2NTgzYzg4ZA0KICAgICAgIDAuMDE5NzU4OiB0PTIwCTY1ZWQ1ZDI3CWU5NTFjYmJkCTBl MWIxY2E5CTQ1MjAwNWU2CWM2NmVlY2ZkDQogICAgICAgMC4wMTk4MTY6IHQ9MjEJMjg3MmRlZjAJ NjVlZDVkMjcJN2E1NDcyZWYJMGUxYjFjYTkJNDUyMDA1ZTYNCiAgICAgICAwLjAxOTg3NDogdD0y MgllNzFiYmI4MwkyODcyZGVmMAlkOTdiNTc0OQk3YTU0NzJlZgkwZTFiMWNhOQ0KICAgICAgIDAu MDE5OTMzOiB0PTIzCTQ0MzE5ZjE3CWU3MWJiYjgzCTBhMWNiN2JjCWQ5N2I1NzQ5CTdhNTQ3MmVm DQogICAgICAgMC4wMTk5OTE6IHQ9MjQJOTAzNGJiYWEJNDQzMTlmMTcJZjljNmVlZTAJMGExY2I3 YmMJZDk3YjU3NDkNCiAgICAgICAwLjAyMDA0OTogdD0yNQk2Mzk5MTNjMwk5MDM0YmJhYQlkMTBj NjdjNQlmOWM2ZWVlMAkwYTFjYjdiYw0KICAgICAgIDAuMDIwMTA3OiB0PTI2CWM4ZjUyOWRhCTYz OTkxM2MzCWE0MGQyZWVhCWQxMGM2N2M1CWY5YzZlZWUwDQogICAgICAgMC4wMjAxNjU6IHQ9MjcJ Njk2ZGY2YjUJYzhmNTI5ZGEJZDhlNjQ0ZjAJYTQwZDJlZWEJZDEwYzY3YzUNCiAgICAgICAwLjAy MDIyNDogdD0yOAkwM2E5NmU1Ngk2OTZkZjZiNQliMjNkNGE3NglkOGU2NDRmMAlhNDBkMmVlYQ0K ICAgICAgIDAuMDIwMjgyOiB0PTI5CWVkNjg4OTZiCTAzYTk2ZTU2CTVhNWI3ZGFkCWIyM2Q0YTc2 CWQ4ZTY0NGYwDQogICAgICAgMC4wMjAzNDA6IHQ9MzAJNWJjYTMwNDEJZWQ2ODg5NmIJODBlYTVi OTUJNWE1YjdkYWQJYjIzZDRhNzYNCiAgICAgICAwLjAyMDM5OTogdD0zMQlkYmJjOWU3Ngk1YmNh MzA0MQlmYjVhMjI1YQk4MGVhNWI5NQk1YTViN2RhZA0KICAgICAgIDAuMDIwNDU3OiB0PTMyCWE0 M2I2ODM5CWRiYmM5ZTc2CTU2ZjI4YzEwCWZiNWEyMjVhCTgwZWE1Yjk1DQogICAgICAgMC4wMjA1 MTU6IHQ9MzMJMTNiZDA2NTgJYTQzYjY4MzkJYjZlZjI3OWQJNTZmMjhjMTAJZmI1YTIyNWENCiAg ICAgICAwLjAyMDU3MzogdD0zNAljNWMwMGVmYQkxM2JkMDY1OAk2OTBlZGEwZQliNmVmMjc5ZAk1 NmYyOGMxMA0KICAgICAgIDAuMDIwNjMxOiB0PTM1CTcyMWZiNTc4CWM1YzAwZWZhCTA0ZWY0MTk2 CTY5MGVkYTBlCWI2ZWYyNzlkDQogICAgICAgMC4wMjA2ODk6IHQ9MzYJMDJlNGFkNjIJNzIxZmI1 NzgJYjE3MDAzYmUJMDRlZjQxOTYJNjkwZWRhMGUNCiAgICAgICAwLjAyMDc0NzogdD0zNwk2NjU4 NjM5NQkwMmU0YWQ2MgkxYzg3ZWQ1ZQliMTcwMDNiZQkwNGVmNDE5Ng0KICAgICAgIDAuMDIwODA1 OiB0PTM4CTM1M2E1YmI2CTY2NTg2Mzk1CTgwYjkyYjU4CTFjODdlZDVlCWIxNzAwM2JlDQogICAg ICAgMC4wMjA4Njk6IHQ9MzkJYmEzZWMwZGQJMzUzYTViYjYJNTk5NjE4ZTUJODBiOTJiNTgJMWM4 N2VkNWUNCiAgICAgICAwLjAyMDkyOTogdD00MAlkMzdmOTViYQliYTNlYzBkZAk4ZDRlOTZlZAk1 OTk2MThlNQk4MGI5MmI1OA0KICAgICAgIDAuMDIwOTgzOiB0PTQxCTA1YmEwZWRjCWQzN2Y5NWJh CTZlOGZiMDM3CThkNGU5NmVkCTU5OTYxOGU1DQogICAgICAgMC4wMjEwMzg6IHQ9NDIJYmFiZDdl ZGIJMDViYTBlZGMJYjRkZmU1NmUJNmU4ZmIwMzcJOGQ0ZTk2ZWQNCiAgICAgICAwLjAyMTA5Mjog dD00MwkyMDE3ZDJhNAliYWJkN2VkYgkwMTZlODNiNwliNGRmZTU2ZQk2ZThmYjAzNw0KICAgICAg IDAuMDIxMTQ1OiB0PTQ0CWJmZTU5MTc3CTIwMTdkMmE0CWVlYWY1ZmI2CTAxNmU4M2I3CWI0ZGZl NTZlDQogICAgICAgMC4wMjExOTk6IHQ9NDUJZjM1NTU3ZjkJYmZlNTkxNzcJMDgwNWY0YTkJZWVh ZjVmYjYJMDE2ZTgzYjcNCiAgICAgICAwLjAyMTI1MjogdD00Ngk5ZDdmNDZhZglmMzU1NTdmOQll ZmY5NjQ1ZAkwODA1ZjRhOQllZWFmNWZiNg0KICAgICAgIDAuMDIxMzA2OiB0PTQ3CWNjMjgzMmFk CTlkN2Y0NmFmCTdjZDU1NWZlCWVmZjk2NDVkCTA4MDVmNGE5DQogICAgICAgMC4wMjEzNTk6IHQ9 NDgJMWM0MDc0NzYJY2MyODMyYWQJZTc1ZmQxYWIJN2NkNTU1ZmUJZWZmOTY0NWQNCiAgICAgICAw LjAyMTQxMzogdD00OQkzMTY5MTY0YgkxYzQwNzQ3Ngk3MzBhMGNhYgllNzVmZDFhYgk3Y2Q1NTVm ZQ0KICAgICAgIDAuMDIxNDY3OiB0PTUwCWRkYTVkOGZlCTMxNjkxNjRiCTg3MTAxZDFkCTczMGEw Y2FiCWU3NWZkMWFiDQogICAgICAgMC4wMjE1MjE6IHQ9NTEJZjAxMzY2YzgJZGRhNWQ4ZmUJY2M1 YTQ1OTIJODcxMDFkMWQJNzMwYTBjYWINCiAgICAgICAwLjAyMTU3NDogdD01MglkY2FlYmQ4Ywlm MDEzNjZjOAliNzY5NzYzZgljYzVhNDU5Mgk4NzEwMWQxZA0KICAgICAgIDAuMDIxNjI4OiB0PTUz CWZhYjM5YWYyCWRjYWViZDhjCTNjMDRkOWIyCWI3Njk3NjNmCWNjNWE0NTkyDQogICAgICAgMC4w MjE2ODI6IHQ9NTQJNDRlNzJjN2MJZmFiMzlhZjIJMzcyYmFmNjMJM2MwNGQ5YjIJYjc2OTc2M2YN CiAgICAgICAwLjAyMTczNjogdD01NQk3YTk2OThkYQk0NGU3MmM3YwliZWFjZTZiYwkzNzJiYWY2 MwkzYzA0ZDliMg0KICAgICAgIDAuMDIxNzg5OiB0PTU2CTBmOWI3ODQwCTdhOTY5OGRhCTExMzlj YjFmCWJlYWNlNmJjCTM3MmJhZjYzDQogICAgICAgMC4wMjE4NDM6IHQ9NTcJZjVlMTMyOGIJMGY5 Yjc4NDAJOWVhNWE2MzYJMTEzOWNiMWYJYmVhY2U2YmMNCiAgICAgICAwLjAyMTg5NjogdD01OAk4 YmJkN2EwNAlmNWUxMzI4YgkwM2U2ZGUxMAk5ZWE1YTYzNgkxMTM5Y2IxZg0KICAgICAgIDAuMDIx OTUwOiB0PTU5CTJiZjgwYjRlCThiYmQ3YTA0CWZkNzg0Y2EyCTAzZTZkZTEwCTllYTVhNjM2DQog ICAgICAgMC4wMjIwMDQ6IHQ9NjAJNGQyOGVhY2MJMmJmODBiNGUJMjJlZjVlODEJZmQ3ODRjYTIJ MDNlNmRlMTANCiAgICAgICAwLjAyMjA1ODogdD02MQk5YTI4YTczZQk0ZDI4ZWFjYwk4YWZlMDJk MwkyMmVmNWU4MQlmZDc4NGNhMg0KICAgICAgIDAuMDIyMTEyOiB0PTYyCWE4ZWU1ZGE3CTlhMjhh NzNlCTEzNGEzYWIzCThhZmUwMmQzCTIyZWY1ZTgxDQogICAgICAgMC4wMjIxNjU6IHQ9NjMJN2Vj NjFmYzgJYThlZTVkYTcJYTY4YTI5Y2YJMTM0YTNhYjMJOGFmZTAyZDMNCiAgICAgICAwLjAyMjIx OTogdD02NAk5YjNmMTNmMgk3ZWM2MWZjOAllYTNiOTc2OQlhNjhhMjljZgkxMzRhM2FiMw0KICAg ICAgIDAuMDIyMjczOiB0PTY1CWFmMzJiNDFhCTliM2YxM2YyCTFmYjE4N2YyCWVhM2I5NzY5CWE2 OGEyOWNmDQogICAgICAgMC4wMjIzMjY6IHQ9NjYJMmU5ZWJiOWIJYWYzMmI0MWEJYTZjZmM0ZmMJ MWZiMTg3ZjIJZWEzYjk3NjkNCiAgICAgICAwLjAyMjM4MDogdD02Nwk4Zjg2NDI5OQkyZTllYmI5 YglhYmNjYWQwNglhNmNmYzRmYwkxZmIxODdmMg0KICAgICAgIDAuMDIyNDM0OiB0PTY4CTA4OTIx ZGI0CThmODY0Mjk5CWNiYTdhZWU2CWFiY2NhZDA2CWE2Y2ZjNGZjDQogICAgICAgMC4wMjI0ODg6 IHQ9NjkJMjZiNDFlODIJMDg5MjFkYjQJNjNlMTkwYTYJY2JhN2FlZTYJYWJjY2FkMDYNCiAgICAg ICAwLjAyMjU0MTogdD03MAk0MWU1OGJhNgkyNmI0MWU4MgkwMjI0ODc2ZAk2M2UxOTBhNgljYmE3 YWVlNg0KICAgICAgIDAuMDIyNTk1OiB0PTcxCTVmMjA4ODI1CTQxZTU4YmE2CTg5YWQwN2EwCTAy MjQ4NzZkCTYzZTE5MGE2DQogICAgICAgMC4wMjI2NDk6IHQ9NzIJMjU2MThlM2UJNWYyMDg4MjUJ OTA3OTYyZTkJODlhZDA3YTAJMDIyNDg3NmQNCiAgICAgICAwLjAyMjcwMjogdD03MwlmYmQ5N2Yz MQkyNTYxOGUzZQk1N2M4MjIwOQk5MDc5NjJlOQk4OWFkMDdhMA0KICAgICAgIDAuMDIyNzU2OiB0 PTc0CWY1ODU3NDhlCWZiZDk3ZjMxCTg5NTg2MzhmCTU3YzgyMjA5CTkwNzk2MmU5DQogICAgICAg MC4wMjI4MTA6IHQ9NzUJMWQ0YzkwOTMJZjU4NTc0OGUJN2VmNjVmY2MJODk1ODYzOGYJNTdjODIy MDkNCiAgICAgICAwLjAyMjg2MzogdD03NglhYmVmOWI0ZAkxZDRjOTA5MwliZDYxNWQyMwk3ZWY2 NWZjYwk4OTU4NjM4Zg0KICAgICAgIDAuMDIyOTE3OiB0PTc3CTE1ODRjYmY5CWFiZWY5YjRkCWM3 NTMyNDI0CWJkNjE1ZDIzCTdlZjY1ZmNjDQogICAgICAgMC4wMjI5NzA6IHQ9NzgJNGRlYzhiYTYJ MTU4NGNiZjkJNmFmYmU2ZDMJYzc1MzI0MjQJYmQ2MTVkMjMNCiAgICAgICAwLjAyMzAyNDogdD03 OQliOTJiOTAyMQk0ZGVjOGJhNgk0NTYxMzJmZQk2YWZiZTZkMwljNzUzMjQyNA0KICAgICAgIDAu MDIzMDc4OiBkaWdlc3Q9CTIwNzBiMzIyCTNkYmEzNzJmCWRlMWMwZmZjCTdiMmUzYjQ5CThiMjYw NjE0DQogICAgICAgMC4wMjMxMzc6IGRzc19wc2V1ZG9fcmFuZG9tKCk6IHdbMF0gICAgPSBHKHhr ZXlbMF0pDQogICAgICAgMC4wMjMxODY6IHdbMF0gICA6IDB4MDAxMmUwODA6IDIwICgweDE0KSBi eXRlcw0KICAgICAgIDAuMDIzMjM4OiB3WzBdICAgOiAweDAwMDA6IDIwNzBiMzIyIDNkYmEzNzJm IGRlMWMwZmZjIDdiMmUzYjQ5ICAgfCBwLiI9LjcvLi4uLnsuO0l8DQogICAgICAgMC4wMjMyODk6 IHdbMF0gICA6IDB4MDAxMDogOGIyNjA2MTQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 LiYuLiAgICAgICAgICAgIHwNCiAgICAgICAwLjAyMzM2MTogZHNzX3BzZXVkb19yYW5kb20oKTog dG1wWzBdID0gKHhrZXlbMF0gKyAxKSBtb2QNCiAgICAgICAwLjAyMzQxMjogdG1wWzBdIDogMHgw MGE1ODQ3MDogMjAgKDB4MTQpIGJ5dGVzDQogICAgICAgMC4wMjM0NjQ6IHRtcFswXSA6IDB4MDAw MDogYjczODVhZWIgMGY2ZmYwNjEgMmJkYjllY2YgMGI5NjUxN2YgICB8LjhaLi5vLmErLi4uLi5R f3wNCiAgICAgICAwLjAyMzUxNDogdG1wWzBdIDogMHgwMDEwOiBiZTliMDJiZCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwuLi4uICAgICAgICAgICAgfA0KICAgICAgIDAuMDIzNTcxOiBk c3NfcHNldWRvX3JhbmRvbSgpOiB4a2V5WzFdID0gKHRtcCArIHhbMF0pIG1vZA0KICAgICAgIDAu MDIzNjIxOiB4a2V5WzFdOiAweDAwMTJjNTQ0OiAyMCAoMHgxNCkgYnl0ZXMNCiAgICAgICAwLjAy MzY3MjogeGtleVsxXTogMHgwMDAwOiBkZDczNGVlMCBiZDBiY2QzYiBhZGJhZWIyNyBkZDFlYWE1 OSAgIHwuc04uLi4uOy4uLicuLi5ZfA0KICAgICAgIDAuMDIzNzIzOiB4a2V5WzFdOiAweDAwMTA6 IDc2ODAzZWNiICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHYuPi4gICAgICAgICAgICB8 DQogICAgICAgMC4wMjM3NzU6IFdbMF09ZGQ3MzRlZTANCiAgICAgICAwLjAyMzgyMzogV1sxXT1i ZDBiY2QzYg0KICAgICAgIDAuMDIzODcxOiBXWzJdPWFkYmFlYjI3DQogICAgICAgMC4wMjM5MjA6 IFdbM109ZGQxZWFhNTkNCiAgICAgICAwLjAyMzk2NzogV1s0XT03NjgwM2VjYg0KICAgICAgIDAu MDI0MDE2OiBXWzVdPTAwMDAwMDAwDQogICAgICAgMC4wMjQwNjM6IFdbNl09MDAwMDAwMDANCiAg ICAgICAwLjAyNDExMTogV1s3XT0wMDAwMDAwMA0KICAgICAgIDAuMDI0MTU3OiBXWzhdPTAwMDAw MDAwDQogICAgICAgMC4wMjQyMTM6IFdbOV09MDAwMDAwMDANCiAgICAgICAwLjAyNDI2MDogV1sx MF09MDAwMDAwMDANCiAgICAgICAwLjAyNDMwNzogV1sxMV09MDAwMDAwMDANCiAgICAgICAwLjAy NDM1NTogV1sxMl09MDAwMDAwMDANCiAgICAgICAwLjAyNDQwMjogV1sxM109MDAwMDAwMDANCiAg ICAgICAwLjAyNDQ1MDogV1sxNF09MDAwMDAwMDANCiAgICAgICAwLjAyNDQ5NzogV1sxNV09MDAw MDAwMDANCiAgICAgICAwLjAyNDU0NTogSFswXT0weDY3NDUyMzAxLCBIWzFdPTB4ZWZjZGFiODks IEhbMl09MHg5OGJhZGNmZSwgSFszXT0weDEwMzI1NDc2LCBIWzRdPTB4YzNkMmUxZjANCiAgICAg ICAwLjAyNDYwMDogICAgdAkgICAgICAgQQkgICAgICAgQgkgICAgICAgQwkgICAgICAgRAkgICAg ICAgRQ0KICAgICAgIDAuMDI0NjQ5OiB0PTAJN2QyN2U3OTMJNjc0NTIzMDEJN2JmMzZhZTIJOThi YWRjZmUJMTAzMjU0NzYNCiAgICAgICAwLjAyNDcwMzogdD0xCWM4Yjk4Y2I3CTdkMjdlNzkzCTU5 ZDE0OGMwCTdiZjM2YWUyCTk4YmFkY2ZlDQogICAgICAgMC4wMjQ3NTY6IHQ9MgkxM2ZiMjE5Nwlj OGI5OGNiNwlkZjQ5ZjllNAk1OWQxNDhjMAk3YmYzNmFlMg0KICAgICAgIDAuMDI0ODA5OiB0PTMJ MGM0MjhhOWEJMTNmYjIxOTcJZjIyZTYzMmQJZGY0OWY5ZTQJNTlkMTQ4YzANCiAgICAgICAwLjAy NDg2MzogdD00CTkxNTA0ZGNhCTBjNDI4YTlhCWM0ZmVjODY1CWYyMmU2MzJkCWRmNDlmOWU0DQog ICAgICAgMC4wMjQ5MTY6IHQ9NQk1YTQ1MTVmNAk5MTUwNGRjYQk4MzEwYTJhNgljNGZlYzg2NQlm MjJlNjMyZA0KICAgICAgIDAuMDI0OTY5OiB0PTYJNWIxMjFiZjgJNWE0NTE1ZjQJYTQ1NDEzNzIJ ODMxMGEyYTYJYzRmZWM4NjUNCiAgICAgICAwLjAyNTAyMzogdD03CTAzMTk3NDdiCTViMTIxYmY4 CTE2OTE0NTdkCWE0NTQxMzcyCTgzMTBhMmE2DQogICAgICAgMC4wMjUwNzY6IHQ9OAlmNzE1YWQx OQkwMzE5NzQ3YgkxNmM0ODZmZQkxNjkxNDU3ZAlhNDU0MTM3Mg0KICAgICAgIDAuMDI1MTMwOiB0 PTkJZjgwYzM1YzcJZjcxNWFkMTkJYzBjNjVkMWUJMTZjNDg2ZmUJMTY5MTQ1N2QNCiAgICAgICAw LjAyNTUyNjogdD0xMAkzMzVlODgxMwlmODBjMzVjNwk3ZGM1NmI0NgljMGM2NWQxZQkxNmM0ODZm ZQ0KICAgICAgIDAuMDI1NTgyOiB0PTExCTU1ZGU2YzViCTMzNWU4ODEzCWZlMDMwZDcxCTdkYzU2 YjQ2CWMwYzY1ZDFlDQogICAgICAgMC4wMjU2MzY6IHQ9MTIJNTU5OWNkNzYJNTVkZTZjNWIJY2Nk N2EyMDQJZmUwMzBkNzEJN2RjNTZiNDYNCiAgICAgICAwLjAyNTY5MDogdD0xMwk3YTU4YjRjOQk1 NTk5Y2Q3NglkNTc3OWIxNgljY2Q3YTIwNAlmZTAzMGQ3MQ0KICAgICAgIDAuMDI1NzQ0OiB0PTE0 CTgwZjNjYjRmCTdhNThiNGM5CTk1NjY3MzVkCWQ1Nzc5YjE2CWNjZDdhMjA0DQogICAgICAgMC4w MjU3OTg6IHQ9MTUJZGIzYWMwZWMJODBmM2NiNGYJNWU5NjJkMzIJOTU2NjczNWQJZDU3NzliMTYN CiAgICAgICAwLjAyNTg1MjogdD0xNgk4ZTdiYjZlYQlkYjNhYzBlYwllMDNjZjJkMwk1ZTk2MmQz Mgk5NTY2NzM1ZA0KICAgICAgIDAuMDI1OTA2OiB0PTE3CTQ0NDc4NmRkCThlN2JiNmVhCTM2Y2Vi MDNiCWUwM2NmMmQzCTVlOTYyZDMyDQogICAgICAgMC4wMjU5NjA6IHQ9MTgJNWVjZTFlODcJNDQ0 Nzg2ZGQJYTM5ZWVkYmEJMzZjZWIwM2IJZTAzY2YyZDMNCiAgICAgICAwLjAyNjAxNDogdD0xOQlj MDJkYjViZgk1ZWNlMWU4Nwk1MTExZTFiNwlhMzllZWRiYQkzNmNlYjAzYg0KICAgICAgIDAuMDI2 MDY4OiB0PTIwCWM0ZjY0NjdkCWMwMmRiNWJmCWQ3YjM4N2ExCTUxMTFlMWI3CWEzOWVlZGJhDQog ICAgICAgMC4wMjYxMjI6IHQ9MjEJNjRiY2Q0NmYJYzRmNjQ2N2QJZjAwYjZkNmYJZDdiMzg3YTEJ NTExMWUxYjcNCiAgICAgICAwLjAyNjE3NzogdD0yMgkyZDBjOGY1Mwk2NGJjZDQ2Zgk3MTNkOTE5 ZglmMDBiNmQ2ZglkN2IzODdhMQ0KICAgICAgIDAuMDI2MjMxOiB0PTIzCWE4NTU0Njg0CTJkMGM4 ZjUzCWQ5MmYzNTFiCTcxM2Q5MTlmCWYwMGI2ZDZmDQogICAgICAgMC4wMjYyODQ6IHQ9MjQJMDk5 YzhkZjcJYTg1NTQ2ODQJY2I0MzIzZDQJZDkyZjM1MWIJNzEzZDkxOWYNCiAgICAgICAwLjAyNjMz ODogdD0yNQkzMjFkMWY5YwkwOTljOGRmNwkyYTE1NTFhMQljYjQzMjNkNAlkOTJmMzUxYg0KICAg ICAgIDAuMDI2MzkyOiB0PTI2CTRlMzRlYjkyCTMyMWQxZjljCWMyNjcyMzdkCTJhMTU1MWExCWNi NDMyM2Q0DQogICAgICAgMC4wMjY0NDY6IHQ9MjcJYTMwMWU2YTgJNGUzNGViOTIJMGM4NzQ3ZTcJ YzI2NzIzN2QJMmExNTUxYTENCiAgICAgICAwLjAyNjUwMDogdD0yOAk4Y2RmODdiYwlhMzAxZTZh OAk5MzhkM2FlNAkwYzg3NDdlNwljMjY3MjM3ZA0KICAgICAgIDAuMDI2NTUzOiB0PTI5CTczZWNh MzU1CThjZGY4N2JjCTI4YzA3OWFhCTkzOGQzYWU0CTBjODc0N2U3DQogICAgICAgMC4wMjY2MDc6 IHQ9MzAJZDk2ZWRhMTkJNzNlY2EzNTUJMjMzN2UxZWYJMjhjMDc5YWEJOTM4ZDNhZTQNCiAgICAg ICAwLjAyNjY2MTogdD0zMQliOTFkNzYxOAlkOTZlZGExOQk1Y2ZiMjhkNQkyMzM3ZTFlZgkyOGMw NzlhYQ0KICAgICAgIDAuMDI2NzE1OiB0PTMyCWIxNWVlZDMzCWI5MWQ3NjE4CTc2NWJiNjg2CTVj ZmIyOGQ1CTIzMzdlMWVmDQogICAgICAgMC4wMjY3Njg6IHQ9MzMJM2Q4OTJkYTcJYjE1ZWVkMzMJ MmU0NzVkODYJNzY1YmI2ODYJNWNmYjI4ZDUNCiAgICAgICAwLjAyNjgyMjogdD0zNAk4YTgzNmEx MAkzZDg5MmRhNwllYzU3YmI0YwkyZTQ3NWQ4Ngk3NjViYjY4Ng0KICAgICAgIDAuMDI2ODc1OiB0 PTM1CTZmZTY1M2Q4CThhODM2YTEwCWNmNjI0YjY5CWVjNTdiYjRjCTJlNDc1ZDg2DQogICAgICAg MC4wMjY5Mjk6IHQ9MzYJMTA3MGZlZmYJNmZlNjUzZDgJMjJhMGRhODQJY2Y2MjRiNjkJZWM1N2Ji NGMNCiAgICAgICAwLjAyNjk4MjogdD0zNwlkY2M4NjRmMQkxMDcwZmVmZgkxYmY5OTRmNgkyMmEw ZGE4NAljZjYyNGI2OQ0KICAgICAgIDAuMDI3MDM2OiB0PTM4CWY1ODM2MTljCWRjYzg2NGYxCWM0 MWMzZmJmCTFiZjk5NGY2CTIyYTBkYTg0DQogICAgICAgMC4wMjcwODk6IHQ9MzkJMGFkNTBmMWIJ ZjU4MzYxOWMJNzczMjE5M2MJYzQxYzNmYmYJMWJmOTk0ZjYNCiAgICAgICAwLjAyNzE0MzogdD00 MAlmNWEzZmFkYgkwYWQ1MGYxYgkzZDYwZDg2Nwk3NzMyMTkzYwljNDFjM2ZiZg0KICAgICAgIDAu MDI3MTk2OiB0PTQxCWMxNzQ0ZDY1CWY1YTNmYWRiCWMyYjU0M2M2CTNkNjBkODY3CTc3MzIxOTNj DQogICAgICAgMC4wMjczOTk6IHQ9NDIJODA0MzNhZjcJYzE3NDRkNjUJZmQ2OGZlYjYJYzJiNTQz YzYJM2Q2MGQ4NjcNCiAgICAgICAwLjAyNzQ1NjogdD00Mwk3MDZmZjUzNQk4MDQzM2FmNwk3MDVk MTM1OQlmZDY4ZmViNgljMmI1NDNjNg0KICAgICAgIDAuMDI3NTEwOiB0PTQ0CTY5OGViYWFmCTcw NmZmNTM1CWUwMTBjZWJkCTcwNWQxMzU5CWZkNjhmZWI2DQogICAgICAgMC4wMjc1NjQ6IHQ9NDUJ ZWJkMDE3MzkJNjk4ZWJhYWYJNWMxYmZkNGQJZTAxMGNlYmQJNzA1ZDEzNTkNCiAgICAgICAwLjAy NzYxODogdD00Ngk3MmJjMTEzMgllYmQwMTczOQlkYTYzYWVhYgk1YzFiZmQ0ZAllMDEwY2ViZA0K ICAgICAgIDAuMDI3NjcyOiB0PTQ3CWYwYTVhY2JjCTcyYmMxMTMyCTdhZjQwNWNlCWRhNjNhZWFi CTVjMWJmZDRkDQogICAgICAgMC4wMjc3MjU6IHQ9NDgJZDRkNDc0ZWYJZjBhNWFjYmMJOWNhZjA0 NGMJN2FmNDA1Y2UJZGE2M2FlYWINCiAgICAgICAwLjAyNzc3ODogdD00OQk3MGVhZjM0MwlkNGQ0 NzRlZgkzYzI5NmIyZgk5Y2FmMDQ0Ywk3YWY0MDVjZQ0KICAgICAgIDAuMDI3ODMyOiB0PTUwCWE5 ZTE0OTNjCTcwZWFmMzQzCWY1MzUxZDNiCTNjMjk2YjJmCTljYWYwNDRjDQogICAgICAgMC4wMjc4 ODU6IHQ9NTEJNmM1YjhiNjAJYTllMTQ5M2MJZGMzYWJjZDAJZjUzNTFkM2IJM2MyOTZiMmYNCiAg ICAgICAwLjAyNzkzODogdD01MglmZDIwNDBkNAk2YzViOGI2MAkyYTc4NTI0ZglkYzNhYmNkMAlm NTM1MWQzYg0KICAgICAgIDAuMDI3OTkyOiB0PTUzCTZkNTcyMjAwCWZkMjA0MGQ0CTFiMTZlMmQ4 CTJhNzg1MjRmCWRjM2FiY2QwDQogICAgICAgMC4wMjgwNDU6IHQ9NTQJNmYwZDU1MmYJNmQ1NzIy MDAJM2Y0ODEwMzUJMWIxNmUyZDgJMmE3ODUyNGYNCiAgICAgICAwLjAyODExNTogdD01NQk4Y2Mz MzIzMgk2ZjBkNTUyZgkxYjU1Yzg4MAkzZjQ4MTAzNQkxYjE2ZTJkOA0KICAgICAgIDAuMDI4MTY5 OiB0PTU2CWRlYWRlODFhCThjYzMzMjMyCWRiYzM1NTRiCTFiNTVjODgwCTNmNDgxMDM1DQogICAg ICAgMC4wMjgyMjM6IHQ9NTcJZDM4MWMzNjkJZGVhZGU4MWEJYTMzMGNjOGMJZGJjMzU1NGIJMWI1 NWM4ODANCiAgICAgICAwLjAyODI3NzogdD01OAkyY2ZiOGUwZQlkMzgxYzM2OQliN2FiN2EwNglh MzMwY2M4YwlkYmMzNTU0Yg0KICAgICAgIDAuMDI4MzMwOiB0PTU5CTE1ZTJiMWNiCTJjZmI4ZTBl CTc0ZTA3MGRhCWI3YWI3YTA2CWEzMzBjYzhjDQogICAgICAgMC4wMjgzODU6IHQ9NjAJN2Y4NWE4 OWYJMTVlMmIxY2IJOGIzZWUzODMJNzRlMDcwZGEJYjdhYjdhMDYNCiAgICAgICAwLjAyODQzODog dD02MQk5NjMyMDVjNwk3Zjg1YTg5ZgljNTc4YWM3Mgk4YjNlZTM4Mwk3NGUwNzBkYQ0KICAgICAg IDAuMDI4NDkyOiB0PTYyCTNjNGZlZDU5CTk2MzIwNWM3CWRmZTE2YTI3CWM1NzhhYzcyCThiM2Vl MzgzDQogICAgICAgMC4wMjg1NDU6IHQ9NjMJNDRlZWM0YzUJM2M0ZmVkNTkJZTU4YzgxNzEJZGZl MTZhMjcJYzU3OGFjNzINCiAgICAgICAwLjAyODU5OTogdD02NAllNzVkMTlhMgk0NGVlYzRjNQk0 ZjEzZmI1NgllNThjODE3MQlkZmUxNmEyNw0KICAgICAgIDAuMDI4NjUyOiB0PTY1CTY5OTIxNWIz CWU3NWQxOWEyCTUxM2JiMTMxCTRmMTNmYjU2CWU1OGM4MTcxDQogICAgICAgMC4wMjg3MDY6IHQ9 NjYJMjE4OWUxNTIJNjk5MjE1YjMJYjlkNzQ2NjgJNTEzYmIxMzEJNGYxM2ZiNTYNCiAgICAgICAw LjAyODc1OTogdD02NwkyNWM3MjA1ZgkyMTg5ZTE1MglkYTY0ODU2YwliOWQ3NDY2OAk1MTNiYjEz MQ0KICAgICAgIDAuMDI4ODE0OiB0PTY4CTdmNGY5YzFmCTI1YzcyMDVmCTg4NjI3ODU0CWRhNjQ4 NTZjCWI5ZDc0NjY4DQogICAgICAgMC4wMjg4Njc6IHQ9NjkJMTJlYWZhZmEJN2Y0ZjljMWYJYzk3 MWM4MTcJODg2Mjc4NTQJZGE2NDg1NmMNCiAgICAgICAwLjAyODkyMTogdD03MAk3Yzc0MWQyYwkx MmVhZmFmYQlkZmQzZTcwNwljOTcxYzgxNwk4ODYyNzg1NA0KICAgICAgIDAuMDI4OTc0OiB0PTcx CTA4OTcxY2RjCTdjNzQxZDJjCTg0YmFiZWJlCWRmZDNlNzA3CWM5NzFjODE3DQogICAgICAgMC4w MjkwMjg6IHQ9NzIJYjdmZjMwYmEJMDg5NzFjZGMJMWYxZDA3NGIJODRiYWJlYmUJZGZkM2U3MDcN CiAgICAgICAwLjAyOTA4MjogdD03Mwk3Mjk1N2Y5NAliN2ZmMzBiYQkwMjI1YzczNwkxZjFkMDc0 Ygk4NGJhYmViZQ0KICAgICAgIDAuMDI5MTM2OiB0PTc0CWI3ZGMzMmY2CTcyOTU3Zjk0CWFkZmZj YzJlCTAyMjVjNzM3CTFmMWQwNzRiDQogICAgICAgMC4wMjkxODk6IHQ9NzUJN2Q1MWJjOWIJYjdk YzMyZjYJMWNhNTVmZTUJYWRmZmNjMmUJMDIyNWM3MzcNCiAgICAgICAwLjAyOTI0MzogdD03Nglm N2JhMGIwNQk3ZDUxYmM5YglhZGY3MGNiZAkxY2E1NWZlNQlhZGZmY2MyZQ0KICAgICAgIDAuMDI5 Mjk2OiB0PTc3CTg4MDBkOWU4CWY3YmEwYjA1CWRmNTQ2ZjI2CWFkZjcwY2JkCTFjYTU1ZmU1DQog ICAgICAgMC4wMjkzNTA6IHQ9NzgJZGI0MWMwY2MJODgwMGQ5ZTgJN2RlZTgyYzEJZGY1NDZmMjYJ YWRmNzBjYmQNCiAgICAgICAwLjAyOTQwMzogdD03OQlkNTI2ZjViOQlkYjQxYzBjYwkyMjAwMzY3 YQk3ZGVlODJjMQlkZjU0NmYyNg0KICAgICAgIDAuMDI5NDU4OiBkaWdlc3Q9CTNjNmMxOGJhCWNi MGY2YzU1CWJhYmIxMzc4CThlMjBkNzM3CWEzMjc1MTE2DQogICAgICAgMC4wMjk1MTg6IGRzc19w c2V1ZG9fcmFuZG9tKCk6IHdbMV0gICAgPSBHKHhrZXlbMV0pDQogICAgICAgMC4wMjk1Njg6IHdb MV0gICA6IDB4MDAxMmUwOTQ6IDIwICgweDE0KSBieXRlcw0KICAgICAgIDAuMDI5NjIxOiB3WzFd ICAgOiAweDAwMDA6IDNjNmMxOGJhIGNiMGY2YzU1IGJhYmIxMzc4IDhlMjBkNzM3ICAgfDxsLi4u LmxVLi4ueC4gLjd8DQogICAgICAgMC4wMjk2NzE6IHdbMV0gICA6IDB4MDAxMDogYTMyNzUxMTYg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8LidRLiAgICAgICAgICAgIHwNCiAgICAgICAw LjAyOTc2MzogICBvdXRwdXQ6IDB4MDAxMmUwODA6IDQwICgweDI4KSBieXRlcw0KICAgICAgIDAu MDI5ODE1OiAgIG91dHB1dDogMHgwMDAwOiAyMDcwYjMyMiAzZGJhMzcyZiBkZTFjMGZmYyA3YjJl M2I0OSAgIHwgcC4iPS43Ly4uLi57LjtJfA0KICAgICAgIDAuMDI5ODY3OiAgIG91dHB1dDogMHgw MDEwOiA4YjI2MDYxNCAzYzZjMThiYSBjYjBmNmM1NSBiYWJiMTM3OCAgIHwuJi4uPGwuLi4ubFUu Li54fA0KICAgICAgIDAuMDI5OTE4OiAgIG91dHB1dDogMHgwMDIwOiA4ZTIwZDczNyBhMzI3NTEx NiAgICAgICAgICAgICAgICAgICAgIHwuIC43LidRLiAgICAgICAgfA0KICAgICAgIDAuMDI5OTcw OiBleHBlY3RlZDogMHgwMDEyZTQ4MDogNDAgKDB4MjgpIGJ5dGVzDQogICAgICAgMC4wMzAwMjA6 IGV4cGVjdGVkOiAweDAwMDA6IDIwNzBiMzIyIDNkYmEzNzJmIGRlMWMwZmZjIDdiMmUzYjQ5ICAg fCBwLiI9LjcvLi4uLnsuO0l8DQogICAgICAgMC4wMzAwNzM6IGV4cGVjdGVkOiAweDAwMTA6IDhi MjYwNjE0IDNjNmMxOGJhIGNiMGY2YzU1IGJhYmIxMzc4ICAgfC4mLi48bC4uLi5sVS4uLnh8DQog ICAgICAgMC4wMzAxMjM6IGV4cGVjdGVkOiAweDAwMjA6IDhlMjBkNzM3IGEzMjc1MTE2ICAgICAg ICAgICAgICAgICAgICAgfC4gLjcuJ1EuICAgICAgICB8DQogICAgICAgMC4wMzAxNzQ6IE9LOiBk c3NfcHNldWRvX3JhbmRvbSgpIGNvcnJlY3Qgb3V0cHV0Lg0KICAgICAgIDAuMDMwMzE0OiBEU1Mg RyBmdW5jdGlvbiB0ZXN0IHN0b3BzLg0KDQo= ------_=_NextPart_001_01C37C49.F7E2ADDC-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Sep 16 09:04:26 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10746 for ; Tue, 16 Sep 2003 09:04:16 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 281B7580109; Tue, 16 Sep 2003 08:04:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 56A2C580029 for ; Tue, 16 Sep 2003 08:03:55 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8GCUkD24912 for ; Tue, 16 Sep 2003 05:30:52 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20030916121502.18293.77474.Mailman@wolverine> Message-ID: References: <20030916121502.18293.77474.Mailman@wolverine> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Re: eap digest, Vol 1 #412 - 7 msgs Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Sep 2003 05:30:46 -0700 (PDT) > **** ii) upon failure to verify - ???? > > b) an EAP-Response/Sim/Challenge > i) verify AT-MAC. If valid, transition to 3) SUCCESS. > **** ii) If AT-MAC failes then ???? > > **** c) an EAP/Identity message. Transition to 1) START ???? > > d) OTHER MESSAGES - unsure. Drop? I believe that dropping all but an EAP-Response/Sim/Challenge is the appropriate thing, given RFC 2284bis. Even EAP-Response/Identity should be dropped. > 3) SUCCESS > > The transition into the SUCCESS state will result in an EAP-Success > message being sent. > > When in state SUCCESS, receipt of any message results in a transition > back to (0). I don't believe this is correct. For example, an EAP-Request should be handled as per RFC 3579. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Sep 16 10:22:52 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16498 for ; Tue, 16 Sep 2003 10:22:08 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 62993580109; Tue, 16 Sep 2003 09:22:04 -0500 (CDT) Delivered-To: eap@frascone.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 78AB5580029 for ; Tue, 16 Sep 2003 09:21:05 -0500 (CDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GEKx420381 for ; Tue, 16 Sep 2003 17:21:02 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Sep 2003 17:20:45 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 16 Sep 2003 17:20:45 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 16 Sep 2003 17:20:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] non-wire related comments on eap-sim-11.txt Message-ID: Thread-Topic: [eap] non-wire related comments on eap-sim-11.txt Thread-Index: AcN7wRU4e4xfvqdWQQeP8Lmg2J58jwAaRrGw From: To: , , Cc: X-OriginalArrivalTime: 16 Sep 2003 14:20:44.0717 (UTC) FILETIME=[B7652DD0:01C37C5D] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Sep 2003 17:20:44 +0300 Content-Transfer-Encoding: quoted-printable Michael, Many thanks for your comments. I agree the document could use some=20 restructuring and clarification. It's a result of cumulative = revisioning,=20 and we haven't really thought about the structure since the beginning. It's very hard to structure the document so that you can understand everything by reading it once. I think we need to have a good overview section. It's not a good idea to duplicate the same information in several places of the document, so it may be hard to avoid referencing sections that follow the current section. > A1) please include real packet dumps, including encrypted data > with keys, to help people. We're planning to do that in appendix A.=20 =20 > A2) There is no per-attribute description/reference. > -> AT_VERSION_LIST for instance has no reference. ... > A4) The definitions of the attributes seems to be partially defined > only in the scenarios of sections 9-15. I would rather the=20 > attributes were defined seperately from the messages in which > they are used. Otherwise, it appears that one has to=20 > code per-message > marshalling/etc. It is hard to tell if this is true or not. >=20 Most of the attributes can be used in a certain message only, but there are attributes like AT_MAC that are general. Maybe we should have a separate section for the attribute definitions, like for example RFC2865. That would make the message definitions=20 simpler. > A3) paragraph 1 of 5.2. This conversation seems totally out of > place, and very confusing. OK. =20 > A5) It was not at all obvious that the AT_MAC is a keyed operation. > The last sentence of 8.1 says so, but I missed it at=20 > least twice, > thinking, but, it must be keyed, I remembered reading about it. >=20 > Maybe this is just the way that I read the document. Yes, it is a keyed operation, as described in section 8.1. > A5b) Annex A/B might be a little more detailed. > In particular, I think that you have chosen G to be SHA1, but > I'm not particularly certain. > Nor do I understahe what "m" is, or what the "optional=20 > user input" > is in this context. Please see other postings on the EAP mailing list about the PRF. > A6) split normative and informative references. OK. > A7) section 3, overview, para 3. > It seemed that this was the only place that the value=20 > of the Start > subtype was clearly stated. In addition, all protocol numbers are stated in=20 section 18 (IANA considerations). > A8) section 5.1, page 9,=20 >=20 > > In this case, the permanent username MUST be of the=20 > format "1imsi".=20 > =09 > It took me awhile to understand that the thing in quotes is a > pattern, not a string. Please remove "", or use another=20 > notation. OK > A9) section 5.1, page 9, para 4. > This seems really nebulous. >=20 Do you mean it's hard to understand if you don't know about re-authentication and IMSI privacy, which are discussed in later sections?=20 > A10) section 5.2, first paragraph. > It seems that you are putting the most complicated "gotcha" > at the beginning. At this point, I don't even know what you are > talking about yet! The "gotcha" is rationale for the feature. Maybe the first paragraph can be removed altogether. > A11) time-sequence diagrams. They are simply not useful to=20 > me. They just > seem to take lots of space. > They are useful when there are more than two parties. > A12) section 5.1, 5.2 and 5.3 should have *NO* mention of > re-authentication. Please describe the base protocol first,=09 > (including state machines), and then give the version that=20 > supports re-authentication. I agree it should be easy to understand the protocol in a general level by reading the first sections. But I'm not sure if we really need to first specify the base protocol only and cut corners in the specification of the Start messages for example. > A13) section 5.3, page 15, para 7. > " A received AT_PERMANENT_ID_REQ does not necessarily=20 > originate from " >=20 > The advice given seems very complicated and very dubious to me. > I believe that this must come out from the client state machine. The "advice" could be removed from the base description (and even omitted from state machine if we have such a thing), and we could discuss protection against active attacks on anonymity separately. > A14) section 6. > Caveat: I read this much less carefully.=20 > page 22, para 4: >=20 > " > Re-authentication identities are one-time identities. If=20 > the client=20 > does not receive a new re-authentication identity, it MUST use=20 > either the permanent identity or a pseudonym identity on the next=20 > authentication to initiate full authentication.=20 > " >=20 > Given that the identity is involved in the AT_MACs, are there > any cryptographic restrictions on the one-time identities? The identities are involved in key derivations in order to get implicit integrity protection by "binding" the derived keys to the identity string. I'm not sure if I properly understand your question, but I don't think there are any restrictions on the identities. >=20 > A15) section 7. basic format. > What if length =3D=3D 0. Malformed packet. > Then what? The current draft (section 15) specifies silent discard as the default operation in error cases, but we're going to change this in response to Glen's comments. If the client encounters a malformed packet, it sends an EAP-Response/SIM/Client-Error, to which the server replies with EAP Failure. If the server encounters a malformed packet, it issues EAP Failure. > A16) section 7. 0/127, 128-255 as "skippable". > I recommend that you adopt the terminology from IKEv2. > The high bit is the "critical" bit (or in this case, the > "non-critical" bit).=20 OK, that's another way to describe the same thing. > A17) section 8.2. AT_CHECKCODE. ...will be removed from the next version of EAP SIM. > A19) What if it is known that the encapsulator provides integrity=20 > protection and privacy? I.e. IKEv2? You'll still have to use AT_MAC, but you don't have to use IMSI privacy. If the encapsulator provides fast reconnect, you don't have to use EAP/SIM's re-authentication. >=20 > A20) section 10. > I'd like to see real numbers in the entire packet. > Hex dumps. > The code/id/Length/etc. break out seems to take way more white > space that it provides value. I think the hex dumps belong to the test vector section. The packets are not fixed length so hex dumps would be problematic except as examples. If we re-arrange the attributes to separate sections, then the descriptions of the messages will be shorter, but I think it is still useful to clearly state at least=20 the Subtype and Code for each message. > A21) re: AT_NEXT_PSEUDONYM, and I guess identities in general. > What about UTF-8? Internationalization? Should we specify that all identities contain UTF-8 encoded=20 ISO 10646 characters and refer to RFC2279? =20 > A22) section 18. > This seems to be the only place that there is a table of > values. I guess that is okay, but I found it hard to find. > I'd like to see a table with brief explanations of each=20 > attribue back in section 10 or earlier. Do you think a section with a separate subsection for each attribute would be good enough? For each message, the section that specifies the message can list the attributes that may, must and must not=20 be included. > A24) Annex B. I found it to be clear as MUD. I guess I don't > code very often to FIPS documents, are they all so obtuse? > C code for this PRF would be welcome, along with test vectors. > When I get mine working, I'll be happy to contribute them. This NIST specification really is very hard to follow. I think that we need to have pseudo-code too. I posted some test vectors on the list which we can include. Best regards, Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Sep 16 10:57:33 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19828 for ; Tue, 16 Sep 2003 10:57:14 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 62C1D580109; Tue, 16 Sep 2003 09:57:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 81CD0580029 for ; Tue, 16 Sep 2003 09:56:21 -0500 (CDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GEuH404769 for ; Tue, 16 Sep 2003 17:56:20 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Sep 2003 17:56:14 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 16 Sep 2003 17:56:14 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 16 Sep 2003 17:56:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] wire related comments on eap-sim-11.txt Message-ID: Thread-Topic: [eap] wire related comments on eap-sim-11.txt Thread-Index: AcN7wXJMNpKMgMPeQhSbCxlNDToTpwAaO0jw From: To: , , Cc: X-OriginalArrivalTime: 16 Sep 2003 14:56:13.0884 (UTC) FILETIME=[AC7A47C0:01C37C62] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Sep 2003 17:56:13 +0300 Content-Transfer-Encoding: quoted-printable Hi Michael, Although EAP/SIM is an Internet-Draft, there are implementations and other documents that depend on it. So in general, we would like=20 to maintain compatibility and interoperability with implementations=20 of old draft versions, unless there is a very good reason to break=20 compatibility. We have version numbers in order to help us make new=20 incompatible versions of the protocol, but we'd like to avoid doing that unless we really have to. I believe that these three issues are not critical but rather=20 they are matters of opinion, nicer ways of doing the same thing. I agree that your proposals would be as good as or better than what we currently have. But there isn't anything fundamentally=20 wrong in the current ways that would justify an incompatible=20 change. So I think we should not change the document with regard=20 to these issues. By the way, do you have a separate comment B3? Best regards, Henry > -----Original Message----- > From: ext Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: 15 September, 2003 22:40 > To: eap; freeradius-users > Cc: mah@eunet.at > Subject: [eap] wire related comments on eap-sim-11.txt >=20 >=20 >=20 > *** PGP Signature Status: unknown > *** Signer: Unknown, Key ID =3D 0xE99DD5FD > *** Signed: 15.09.2003 10:39:47 PM > *** Verified: 16.09.2003 11:12:23 AM > *** BEGIN PGP VERIFIED MESSAGE *** >=20 >=20 > =09 > B1) why is the TLV format different from the RADIUS one? > The length is the only difference. (being /4) > How often do we need attributes longer than 253 bytes? > What happens if the length is 0? (Yeah, it is illegal, > but why have such a situation) >=20 > The 4* the length is there so that one can have 1022 byte > attributes. These don't fit into single EAP-Message payloads in > radius, is the situation better in LCP?=20 >=20 > The 4* length seems to simply result in there needing=20 > to be another > length in many packets. That probably cancels any advantage in=20 > encoding the length as a byte.=20 >=20 > The rounding up to 32-bit size also seems to waste a=20 > lot of bytes > needlessly - the EAP messages won't be aligned when they arrive > in at a radius server, which is likely the end that=20 > will biggest load > due to EAP messages, so why bother here?=20 >=20 > I suggest that the TLV format be junked in favour of one that is > either identical to PPP or identical to radius.=20 >=20 > This is gratuitously different. >=20 > B2) why are there boath IV and ENCR attribues? > Just put the IV at the front of cipher text. This makes=20 > much more > sense.=20 >=20 > B4) It appears that AT_FULLAUTH_ID_REQ, PERMANEND_ID_REQ and > ANY_ID_REQ are always mutually exclusive. I strongly suggest > that there be an "ID_REQ" attribute, with three values: > FULLAUTH/PERMANENT/ANY >=20 > In fact, these three cases seem like they are really three > different "Start" situations, and I suggest that they be > turned into three "Start" messages. This would be much easier > to document and analyze. >=20 > ] Out and about in Ottawa. hmmm... beer. =20 > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON =20 > |net architect[ > ] mcr@sandelman.ottawa.on.ca=20 > http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another Debian/notebook using, kernel hacking,=20 > security guy"); [ >=20 >=20 > *** END PGP VERIFIED MESSAGE *** > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Sep 16 12:25:17 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24807 for ; Tue, 16 Sep 2003 12:25:03 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 60033580109; Tue, 16 Sep 2003 11:25:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id 86359580029 for ; Tue, 16 Sep 2003 11:24:32 -0500 (CDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8GGNMd27769; Tue, 16 Sep 2003 12:23:22 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h8GGPBr04644; Tue, 16 Sep 2003 12:25:38 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h8GGMXC1008206; Tue, 16 Sep 2003 12:22:34 -0400 To: henry.haverinen@nokia.com Cc: eap@frascone.com Subject: Re: [eap] questions about PRF in eap-sim-11.txt In-reply-to: Your message of "Tue, 16 Sep 2003 14:59:22 +0300." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <8205.1063729353@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Sep 2003 12:22:33 -0400 -----BEGIN PGP SIGNED MESSAGE----- Henry, I already tested against those test vectors. That's why I knew that I had the code wrong, and how I determined what was correct. Input was: |bd029bbe_7f51960b_cf9edb2b_61f06f0f_eb5a38b6| Output was: 2070b322_3dba372f_de1c0ffc_7b2e3b49_8b260614 3c6c18ba_cb0f6c55_babb1378_8e20d737_a3275116 c9ec5c2f_3261cba3_98384ecf_9189707c_20dbe3b6 8d6fc9d2_37313854_7338c3f5_7cf68f38_683aea5b f9e60c0d_73b177bc_69edde1b_eb3f596a_9555fee9 0d570204_a3044bb5_a67f6509_25f14c1d_0446b252 78360140_28faffbf_49840408_ccb30408_00b40408 38faffbf_18ef0440_48ae1340_c0970040_48faffbf Your test vector does not provide the entire 1280 bits of keying needed to verify all of EAP-SIM's calculations. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP2c4yIqHRg3pndX9AQFFbAP/db7U8jzF1roZ8S/hoy/9WY6qSkn3Tdg3 ZBedt1WOqDPsHbxxknOY/Nkf7yQEYnD586wqyzr/xeNgW+oW/OUlBQ/dQMTqfhor D9ngfPNBoIAMboPAAtr4nf4DzCeKQfvVAakxfAEo9VmP16zZr2kMBQcvjmWWFSzy Ax7WAaoYX5M= =rXRZ -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Sep 16 13:03:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26998 for ; Tue, 16 Sep 2003 13:03:57 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA9D8580109; Tue, 16 Sep 2003 12:04:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from fw2.gdm.de (fw2.gdm.de [193.108.184.154]) by mail.frascone.com (Postfix) with ESMTP id BD625580029 for ; Tue, 16 Sep 2003 12:03:50 -0500 (CDT) Received: by fw2.gdm.de (8.11.6p2/8.11.6) id h8GH3mU04422 for eap@frascone.com; Tue, 16 Sep 2003 19:03:48 +0200 (CEST) Received: (from localhost) by fw2.gdm.de (MSCAN) id 2/fw2.gdm.de/smtp-gw/mscan; Tue Sep 16 19:03:48 2003 From: Hubert.Ertl@de.gi-de.com To: eap@frascone.com Message-ID: X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0.1CF1|March 04, 2003) at 16.09.2003 19:01:40 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by amavisd-new Subject: [eap] Hubert Ertl/GDM/GuD is out of the office. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Sep 2003 19:01:47 +0200 Content-Transfer-Encoding: quoted-printable Ich werde ab 16.09.2003 nicht im B=FCro sein. Ich kehre zur=FCck am 19.09.2003. I am away from my email. I will respond to your message when back on September 19th.= _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 17 06:51:03 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04774 for ; Wed, 17 Sep 2003 06:50:57 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55480580116; Wed, 17 Sep 2003 05:51:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from mta08.mail.mel.aone.net.au (mta08.mail.au.uu.net [203.2.192.89]) by mail.frascone.com (Postfix) with ESMTP id 1D9D3580029 for ; Wed, 17 Sep 2003 05:50:21 -0500 (CDT) Received: from pc1 ([63.12.24.147]) by mta08.mail.mel.aone.net.au with ESMTP id <20030917105015.JQWR15355.mta08.mail.mel.aone.net.au@pc1> for ; Wed, 17 Sep 2003 20:50:15 +1000 From: "Ehsan Sakhaee" To: Message-ID: <000201c37d09$7a5e6490$0100a8c0@pc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Subject: [eap] EAP-Failure Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 17 Sep 2003 20:50:04 +1000 Content-Transfer-Encoding: 7bit Hi, Does EAP-Failure have the same function as a 802.11 MAC Disassociate message. Ie would it disassociate a client if sent from an adversary? Regards, E.Sakhaee _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 17 07:59:37 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07663 for ; Wed, 17 Sep 2003 07:59:18 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E367580116; Wed, 17 Sep 2003 06:59:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id E8DB3580029 for ; Wed, 17 Sep 2003 06:58:57 -0500 (CDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8HBwg405090 for ; Wed, 17 Sep 2003 14:58:56 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Sep 2003 14:58:42 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 17 Sep 2003 14:58:42 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 17 Sep 2003 14:58:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] my Issue A12 - state machines - server side Message-ID: Thread-Topic: [eap] my Issue A12 - state machines - server side Thread-Index: AcN7w/7jpgnuOTHeTK2jnCW11ubytwAatLeQ From: To: , X-OriginalArrivalTime: 17 Sep 2003 11:58:41.0806 (UTC) FILETIME=[09C1EAE0:01C37D13] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 17 Sep 2003 14:58:41 +0300 Content-Transfer-Encoding: quoted-printable Michael, I think we should not duplicate anything that is covered by rfc2284bis or the EAP state machine (draft-vollbrecht-eap-state) in the EAP method drafts. They specify, among other things, the processing of=20 EAP notifications, EAP identity, EAP Success, EAP Failure, how the Identifier field is used, and how the EAP exchange proceeds in general. Certainly we have to specify the processing of EAP/SIM packets, also in any error and corner cases, such as unexpected Subtype, or unexpected attributes included. In the current version, the default action in error cases is Silent Discard and that is specified for these cases too. However, we're planning to change the drafts=20 according to Glen's comments. In the next versions, if an error=20 occurs in the server, the server generally issues EAP Failure.=20 If an error occurs on the client, the client sends a Client Error packet (a new EAP/SIM subtype), and the server is expected to respond with EAP Failure. I agree the specification in general needs some re-structuring and clarification, but I'm inclined to think we don't need to add state machines to the documents. They are after all quite simple request/response protocols, and the operation in various cases can be described=20 unambiguously without state machnies.=20 However state machnies can be very useful in the discussions, even if we did not make them part of the document. Regards, Henry > -----Original Message----- > From: ext Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: 15 September, 2003 22:59 > To: eap > Subject: [eap] my Issue A12 - state machines - server side >=20 >=20 >=20 > *** PGP Signature Status: unknown > *** Signer: Unknown, Key ID =3D 0xE99DD5FD > *** Signed: 15.09.2003 10:58:26 PM > *** Verified: 16.09.2003 11:08:00 AM > *** BEGIN PGP VERIFIED MESSAGE *** >=20 >=20 > >>>>> "Michael" =3D=3D Michael Richardson=20 > writes: > Michael> A12) section 5.1, 5.2 and 5.3 should have=20 > *NO* mention of > Michael> re-authentication. Please describe the base=20 > protocol first, > Michael> (including state machines), and then give the=20 > version that=20 > Michael> supports re-authentication. >=20 > I have implemented basic authentication so far. As such, my=20 > state machines > are incomplete, but even so, there are a number of holes and=20 > questions that > are not easily determined from reading the document. >=20 > In particular, as I'm writing this, I realize that the EAP-business > of dealing with retransmits in IDs is probably best made explicit in > new states. >=20 > Obviously, I have not taken into account any notifications. >=20 > I suggest text based upon what I write here. I.e. in this style. > I can write similar text for the client. >=20 > The server seems to have three states in my implementation: > 1) START > 2) CHALLENGE > 3) SUCCESS >=20 > 0)=20 >=20 > Upon recognizing the user as an EAP-SIM, the server transitions into > the START state. This is done upon receipt of an=20 > EAP/Identity message > detailing a user who should be using EAP-SIM. > (EAP may have other state that it goes through to get here) >=20 > 1) START >=20 > The transition into the START state will result in transmitting an=20 > EAP-Request/Sim/Start message.=20 >=20 > When in state "Start", the following messages may be received: > a) An EAP-Response/Sim/Start. =20 > i) Verify selected version is compatible and presence=20 > of NONCE_MT, > and transition to 2) CHALLENGE. > =20 > **** ii) upon failure to verify - ???? >=20 > b) An EAP/Identity message. Transition to 1) START. >=20 > **** c) OTHER MESSAGES - unsure. Transition to 1) START ???? >=20 > 2) CHALLENGE >=20 > The transition into the CHALLENGE state will result in an > EAP-Request/Sim/Challenge message being sent.=20 > {Existing RAND challenges should be used if this user has not > completed the state yet. The EAP ID should not be updated} >=20 > When in state "Challenge", the following messages may be received: > a) an EAP-Response/Sim/Start=20 > i) Verify selected version is compatible and presence=20 > of NONCE_MT, > and transition to 2) CHALLENGE. > =20 > **** ii) upon failure to verify - ???? >=20 > b) an EAP-Response/Sim/Challenge > i) verify AT-MAC. If valid, transition to 3) SUCCESS. > **** ii) If AT-MAC failes then ???? >=20 > **** c) an EAP/Identity message. Transition to 1) START ???? >=20 > d) OTHER MESSAGES - unsure. Drop? >=20 > 3) SUCCESS >=20 > The transition into the SUCCESS state will result in an EAP-Success > message being sent. >=20 > When in state SUCCESS, receipt of any message results in a=20 > transition > back to (0). >=20 > ] Out and about in Ottawa. hmmm... beer. =20 > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON =20 > |net architect[ > ] mcr@sandelman.ottawa.on.ca=20 > http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another Debian/notebook using, kernel hacking,=20 > security guy"); [ >=20 >=20 > =20 >=20 >=20 >=20 >=20 > *** END PGP VERIFIED MESSAGE *** > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 17 13:03:09 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20271 for ; Wed, 17 Sep 2003 13:03:06 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 33E1858000F; Wed, 17 Sep 2003 12:03:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by mail.frascone.com (Postfix) with ESMTP id 9F0EA58000E for ; Wed, 17 Sep 2003 12:02:46 -0500 (CDT) Received: by fw1.gdm.de (8.11.6p2/8.11.6) id h8HH2jK20064 for eap@frascone.com; Wed, 17 Sep 2003 19:02:45 +0200 (CEST) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Wed Sep 17 19:02:45 2003 From: Hubert.Ertl@de.gi-de.com To: eap@frascone.com Message-ID: X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0.1CF1|March 04, 2003) at 17.09.2003 19:00:42 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by amavisd-new Subject: [eap] Hubert Ertl/GDM/GuD is out of the office. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 17 Sep 2003 19:00:48 +0200 Content-Transfer-Encoding: quoted-printable Ich werde ab 16.09.2003 nicht im B=FCro sein. Ich kehre zur=FCck am 19.09.2003. I am away from my email. I will respond to your message when back on September 19th.= _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 17 13:16:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20593 for ; Wed, 17 Sep 2003 13:15:57 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 18861580012; Wed, 17 Sep 2003 12:16:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 7242458000F for ; Wed, 17 Sep 2003 12:15:20 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8HGfSn24356 for ; Wed, 17 Sep 2003 09:41:58 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20030917170003.16185.58395.Mailman@wolverine> Message-ID: References: <20030917170003.16185.58395.Mailman@wolverine> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Re: EAP-Failure Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 17 Sep 2003 09:41:28 -0700 (PDT) > Does EAP-Failure have the same function as a 802.11 MAC Disassociate > message. Ie would it disassociate a client if sent from an adversary? No. EAP-Failure only has an effect in circumstances where the method expects it. That means that where a method provides its own protected success/failure indications, if an adversary spoofs an EAP Failure (or Success) it will be silently discarded. See RFC 2284bis-05, Section 4.2. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 17 13:36:08 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21241 for ; Wed, 17 Sep 2003 13:35:59 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9546C58000F; Wed, 17 Sep 2003 12:36:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id 3DCB658000E for ; Wed, 17 Sep 2003 12:35:41 -0500 (CDT) Received: from sandelman.ottawa.on.ca ([2002:c08b:2e9e::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8HHZIw03827 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 17 Sep 2003 13:35:19 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h8HHZ2ev016158 for ; Wed, 17 Sep 2003 13:35:12 -0400 To: eap Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <16157.1063820102@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Subject: [eap] question about AT_MAC text Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 17 Sep 2003 13:35:02 -0400 -----BEGIN PGP SIGNED MESSAGE----- A25) Section 12 is said to be authoritative by section 8.1 Section 8.1 says the contents are message specific. How much of the EAP packet is HMAC'ed? All of it, or just the EAP-SIM portion? ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP2hoAYqHRg3pndX9AQEj0AQAlwY6O8sPPutwcx7UbTBRrIwb/+xcqkvI uvTQOBlhI/T1kckJSZIyWwnaF2SrH3uqPLtP/gPXcGpc+Kx4T1fF74N/sLAqrpt4 hU5T9hMTw6tc7T1OMacCUp2L1TVeK52RBJSusDAo4fe2K6DbdnWSKTNBin6e3ZK6 rlCLlePch7s= =1Y6Y -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 17 15:26:13 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25807 for ; Wed, 17 Sep 2003 15:25:59 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DBCA258000F; Wed, 17 Sep 2003 14:26:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id C8D1D58000E for ; Wed, 17 Sep 2003 14:25:06 -0500 (CDT) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8HJP3qP019572; Wed, 17 Sep 2003 12:25:03 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.99.6]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Sep 2003 12:29:29 -0700 From: "Joseph Salowey" To: "'Michael Richardson'" , "'eap'" Subject: RE: [eap] question about AT_MAC text Message-ID: <02c001c37d51$6460bbf0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <16157.1063820102@marajade.sandelman.ottawa.on.ca> X-OriginalArrivalTime: 17 Sep 2003 19:29:29.0343 (UTC) FILETIME=[035888F0:01C37D52] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 17 Sep 2003 12:25:01 -0700 Content-Transfer-Encoding: 7bit All of the EAP packet should be HMAC'ed. Additional data is appended to the EAP packet and included in the MAC. The value of this additional data depends upon the EAP-SIM message type. Joe > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Michael Richardson > Sent: Wednesday, September 17, 2003 10:35 AM > To: eap > Subject: [eap] question about AT_MAC text > > > -----BEGIN PGP SIGNED MESSAGE----- > > > A25) Section 12 is said to be authoritative by section 8.1 > Section 8.1 says the contents are message specific. > How much of the EAP packet is HMAC'ed? All of it, or just > the EAP-SIM portion? > > ] Out and about in Ottawa. hmmm... beer. > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device > driver[ ] > panic("Just another Debian/notebook using, kernel hacking, > security guy"); [ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Finger me for keys - custom hacks make this fully PGP2 compat > > iQCVAwUBP2hoAYqHRg3pndX9AQEj0AQAlwY6O8sPPutwcx7UbTBRrIwb/+xcqkvI > uvTQOBlhI/T1kckJSZIyWwnaF2SrH3uqPLtP/gPXcGpc+Kx4T1fF74N/sLAqrpt4 > hU5T9hMTw6tc7T1OMacCUp2L1TVeK52RBJSusDAo4fe2K6DbdnWSKTNBin6e3ZK6 > rlCLlePch7s= > =1Y6Y > -----END PGP SIGNATURE----- > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 18 01:10:13 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14894 for ; Thu, 18 Sep 2003 01:10:07 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6240E580019; Thu, 18 Sep 2003 00:10:05 -0500 (CDT) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 6F1DB580017 for ; Thu, 18 Sep 2003 00:09:02 -0500 (CDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 396996A906; Thu, 18 Sep 2003 08:09:00 +0300 (EEST) Message-ID: <3F693D25.6070104@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Cc: Bernard Aboba Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] more information about the interim meeting Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 18 Sep 2003 08:05:41 +0300 Content-Transfer-Encoding: 7bit Here is more information about the interim meeting: EAP WG Interim Meeting Meeting Date: October 15, 2003 Time: 9 AM - 5 PM, EDT Meeting location: Trusecure 13650 Dulles Technology Drive Suite 500 Herndon, VA 20171 (888) 627-2281 Main Phone (703) 480-8200 Local Phone Directions: http://www.trusecure.com/corporate/locations/directions-hq.shtml Recommended Airport: Washington Dulles Airport (IAD) Recommended Hotels: Homewood Suites 13460 Sunrise Valley Drive Herndon, VA 20171 Tel: 1-703-793-1700 Fax: 1-703-793-1899 Directions: Take Dulles Toll Road east toward Washington D.C. Stay in right hand lane to exit 10 (Herndon/Chantilly). Turn right at light (onto Centerville Rd). At 2nd light, turn right onto Sunrise Valley Drive and continue 1/2 mile to Hotel on right. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 18 09:58:14 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11950 for ; Thu, 18 Sep 2003 09:58:02 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3175458011D; Thu, 18 Sep 2003 08:58:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 0A815580017 for ; Thu, 18 Sep 2003 08:57:31 -0500 (CDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11903; Thu, 18 Sep 2003 09:57:23 -0400 (EDT) Message-Id: <200309181357.JAA11903@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: eap@frascone.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [eap] I-D ACTION:draft-ietf-eap-statemachine-00.txt,.ps,.pdf Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 18 Sep 2003 09:57:22 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : State Machines for EAP Peer and Authenticator Author(s) : J. Vollbrecht et al. Filename : draft-ietf-eap-statemachine-00.txt,.ps,.pdf Pages : 37 Date : 2003-9-18 This document describes a set of state machines for EAP Peer, EAP Standalone Authenticator (non-passthrough), EAP Backend Authenticator (for use on AAA servers), and EAP Full Authenticator (for both local and passthrough). This set of state machines shows how EAP can be implemented to support deployment in either a Peer/AP or Peer/AP/AAA Server environment. The Peer and Standalone Authenticator machines are illustrative of how the EAP protocol defined in [I-D.ietf-eap-rfc2284bis] may be implemented. The Backend and Full/ Passthrough Authenticators illustrate how EAP/RADIUS protocol support defined in [RFC3579] may be implemented. Where there are differences [I-D.ietf-eap-rfc2284bis]/[RFC3579] are authoritative. This document describes a state machine based on an EAP 'Switch' model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. The State Machine and associated model are informative only. Implementations may achieve the same results using different methods. A brief description of the EAP 'Switch' model is given in the Introduction section. The authors believe this document corresponds to the current state of revisions to the defining [I-D/ietf-eap-rfc2284bis]/[RFC3579] documents. The intent is for this document to synchronize with the defining documents when they are released, and if discrepancies are found the defining documents are authoritative. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-00.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-eap-statemachine-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-statemachine-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2003-9-18095703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-statemachine-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-statemachine-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-18095703.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 19 12:19:57 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10042 for ; Fri, 19 Sep 2003 12:19:50 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 155A958012A; Fri, 19 Sep 2003 02:57:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by mail.frascone.com (Postfix) with ESMTP id 5E5C5580129 for ; Fri, 19 Sep 2003 02:56:12 -0500 (CDT) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h8IJ6Jbf006541 for ; Thu, 18 Sep 2003 12:06:20 -0700 (MST) Received: from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h8IJ63Dd029736 for ; Thu, 18 Sep 2003 14:06:03 -0500 Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2657.2) id ; Thu, 18 Sep 2003 15:06:14 -0400 Message-ID: <19CD0E423FC1D611893500508B6F0B9C014961AE@ma07exm01.dma.isg.mot.com> From: Eastlake III Donald-LDE008 To: eap@frascone.com Subject: RE: [eap] more information about the interim meeting MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 18 Sep 2003 15:06:09 -0400 The recommended Homewood Suites insists that are complete sold out. Donald -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Thursday, 18 September, 2003 1:06 AM To: eap@frascone.com Cc: Bernard Aboba Subject: [eap] more information about the interim meeting Here is more information about the interim meeting: EAP WG Interim Meeting Meeting Date: October 15, 2003 Time: 9 AM - 5 PM, EDT Meeting location: Trusecure 13650 Dulles Technology Drive Suite 500 Herndon, VA 20171 (888) 627-2281 Main Phone (703) 480-8200 Local Phone Directions: http://www.trusecure.com/corporate/locations/directions-hq.shtml Recommended Airport: Washington Dulles Airport (IAD) Recommended Hotels: Homewood Suites 13460 Sunrise Valley Drive Herndon, VA 20171 Tel: 1-703-793-1700 Fax: 1-703-793-1899 Directions: Take Dulles Toll Road east toward Washington D.C. Stay in right hand lane to exit 10 (Herndon/Chantilly). Turn right at light (onto Centerville Rd). At 2nd light, turn right onto Sunrise Valley Drive and continue 1/2 mile to Hotel on right. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 19 12:36:32 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12332 for ; Fri, 19 Sep 2003 12:36:26 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AEB7458012B; Thu, 18 Sep 2003 23:06:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 5576C58012A for ; Thu, 18 Sep 2003 23:05:21 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8J3VqQ14511 for ; Thu, 18 Sep 2003 20:32:02 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Link to paper on GSM cryptanalysis Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 18 Sep 2003 20:31:52 -0700 (PDT) Here is a link to the Barkan, Biham, Keller paper on GSM cryptanalysis: http://www.cs.technion.ac.il/users/wwwb/cgi-bin/tr-get.cgi/2003/CS/CS-2003-05.ps.gz News story: http://www.theregister.co.uk/content/55/32653.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 19 12:36:32 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12333 for ; Fri, 19 Sep 2003 12:36:26 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A2D4580122; Thu, 18 Sep 2003 18:57:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 639DC580017 for ; Thu, 18 Sep 2003 18:56:38 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8INNAM32459 for ; Thu, 18 Sep 2003 16:23:25 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Key Design discussions Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 18 Sep 2003 16:23:09 -0700 (PDT) I've created a web site holding the position papers and minutes of the Key Framework Design Team: http://www.drizzle.com/~aboba/key-design/ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 19 13:26:40 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16085 for ; Fri, 19 Sep 2003 13:26:40 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DCEBE58011B; Thu, 18 Sep 2003 17:44:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from old-n2.infonet.com (old-n2-130.infonet.com [192.157.130.138]) by mail.frascone.com (Postfix) with ESMTP id 59AEC580017 for ; Thu, 18 Sep 2003 17:43:45 -0500 (CDT) Received: from hubnotes1.infonet.com (hubnotes1 [198.137.76.56]) by old-n2.infonet.com with ESMTP id h8IMeNK04015 for ; Thu, 18 Sep 2003 22:40:23 GMT From: josh_mendel@infonet.com To: eap@frascone.com Message-ID: X-MIMETrack: Serialize by Router on HUBNOTES1/SVR/ISC(Release 6.0.2CF2|July 23, 2003) at 09/18/2003 03:43:43 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [eap] Josh Mendel/HQ/ISC is out of the office. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 18 Sep 2003 15:43:40 -0700 I will be out of the office starting 09/18/2003 and will not return until 09/22/2003. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 19 13:58:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17495 for ; Fri, 19 Sep 2003 13:58:56 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0833D58011B; Fri, 19 Sep 2003 12:59:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id A94B4580023 for ; Fri, 19 Sep 2003 12:58:50 -0500 (CDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5EBEE6A901; Fri, 19 Sep 2003 20:58:48 +0300 (EEST) Message-ID: <3F6B430F.6020702@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Cc: Bernard Aboba References: <3F693D25.6070104@piuha.net> In-Reply-To: <3F693D25.6070104@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [eap] interim meeting participation Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 19 Sep 2003 20:55:27 +0300 Content-Transfer-Encoding: 7bit If you intend to participate the interim meeting on October 15th, we would appreciate if you could confirm your participation by sending mail to the chairs. Please do so before Monday the 22nd. Thanks, --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 19 14:15:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18292 for ; Fri, 19 Sep 2003 14:14:58 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1C3BD5801B2; Fri, 19 Sep 2003 13:15:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id 9F90F58012A for ; Fri, 19 Sep 2003 13:14:54 -0500 (CDT) Received: (qmail 1745 invoked from network); 19 Sep 2003 18:14:53 -0000 Received: from unknown (HELO mtghouse.com) (192.168.11.223) by deneb.mtghouse.com with SMTP; 19 Sep 2003 18:14:53 -0000 Message-ID: <3F6B47A9.5040401@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Cc: "eap@frascone.com" , Bernard Aboba Subject: Re: [eap] interim meeting participation References: <3F693D25.6070104@piuha.net> <3F6B430F.6020702@piuha.net> In-Reply-To: <3F6B430F.6020702@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 19 Sep 2003 14:15:05 -0400 Content-Transfer-Encoding: 7bit It will be in VA. Jari Arkko wrote: > > If you intend to participate the interim meeting > on October 15th, we would appreciate if you could > confirm your participation by sending mail to the > chairs. Please do so before Monday the 22nd. > > Thanks, > > --Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Sep 20 01:25:29 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12184 for ; Sat, 20 Sep 2003 01:25:20 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A2CB580029; Sat, 20 Sep 2003 00:25:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id D8C02580024 for ; Sat, 20 Sep 2003 00:24:47 -0500 (CDT) Received: from cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 19 Sep 2003 22:25:47 -0700 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8K5OixW005456; Fri, 19 Sep 2003 22:24:44 -0700 (PDT) Received: from gwzw2k (sjc-vpn1-48.cisco.com [10.21.96.48]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id WAA28183; Fri, 19 Sep 2003 22:24:43 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Eastlake III Donald-LDE008'" , Subject: RE: [eap] more information about the interim meeting Organization: Cisco Systems Message-ID: <002901c37f37$7ab9c670$079d4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <19CD0E423FC1D611893500508B6F0B9C014961AE@ma07exm01.dma.isg.mot.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 19 Sep 2003 22:24:04 -0700 Content-Transfer-Encoding: 7bit eap-admin@frascone.com writes: > The recommended Homewood Suites insists that are complete sold out. There is an Embassy Suites that is closer (according to MapQuest), cheaper & available (as of 5 minutes ago): EMBASSY STES DULLES ARPRT 13341 WOODLAND PARK DRIVE HERNDON VA 20171 > > Donald > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Thursday, 18 September, 2003 1:06 AM > To: eap@frascone.com > Cc: Bernard Aboba > Subject: [eap] more information about the interim meeting > > Here is more information about the interim meeting: > > EAP WG Interim Meeting > Meeting Date: October 15, 2003 > Time: 9 AM - 5 PM, EDT > > Meeting location: > > Trusecure > 13650 Dulles Technology Drive > Suite 500 > Herndon, VA 20171 > (888) 627-2281 Main Phone > (703) 480-8200 Local Phone > > Directions: > > http://www.trusecure.com/corporate/locations/directions-hq.shtml > > Recommended Airport: Washington Dulles Airport (IAD) > > Recommended Hotels: > > Homewood Suites > 13460 Sunrise Valley Drive > Herndon, VA 20171 > Tel: 1-703-793-1700 > Fax: 1-703-793-1899 > > Directions: > > Take Dulles Toll Road east toward Washington D.C. Stay in right hand > lane to exit 10 (Herndon/Chantilly). Turn right at light (onto > Centerville Rd). At 2nd light, turn right onto Sunrise Valley Drive > and continue 1/2 mile to Hotel on right. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Sep 21 01:05:33 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04796 for ; Sun, 21 Sep 2003 01:05:21 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D473958010D; Sun, 21 Sep 2003 00:05:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from smtp805.mail.sc5.yahoo.com (smtp805.mail.sc5.yahoo.com [66.163.168.184]) by mail.frascone.com (Postfix) with SMTP id B9BD6580026 for ; Sun, 21 Sep 2003 00:04:38 -0500 (CDT) Received: from adsl-64-160-54-157.dsl.snfc21.pacbell.net (HELO adithya) (mohanp@sbcglobal.net@64.160.54.157 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 21 Sep 2003 05:04:38 -0000 Message-ID: <001301c37ffd$dcb5c7e0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Subject: [eap] Comments on pasi.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 20 Sep 2003 22:04:39 -0700 Content-Transfer-Encoding: 7bit Hi, I had a few questions/comments on the pasi's notes. In the section, "client's point of view", >The proposed key derivation mechanisms (e.g. AAA server >includes the BSSID when deriving the key to be sent to the AP) >authenticates also the BSSID (MAC address) of the AP (if the >AAA server can check that the BSSID is correct). However, it's >not clear how much this actually helps the client in >determining if it's talking to the correct AP or not. Since I am not sure i understood the meaning of correct AP here. Is the correct AP the one that the client thinks that will provide the expected service ? AAA server "trusts" that this is the "correct" AP and tells the client indirectly by including the BSSID in key derivation. Why is this not sufficient ? Could you elaborate ? >"correct" here usually includes the intentions of the person >operating the client, the identities that are authenticated >should really be meaningful to that person. BSSID certainly >is not; SSID probably is (although it doesn't uniquely >identify the AP). What extra assurance the client gets by authenticating the "SSID" ? What exactly does the AAA server do with the SSID ? Does it verify that this AP is the right one for the SSID ? Eventually the client wants to be able to send/receive packets. BSSID seems important for this purpose. So, don't you really want to verify whether this "BSSID" can be associated with this "SSID", and just include the BSSID in key derivation as that's what is used eventually in sending and receiving packets. -mohan _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Sep 21 18:02:17 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09626 for ; Sun, 21 Sep 2003 18:02:07 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7AF83580112; Sun, 21 Sep 2003 17:02:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id D8DC1580026 for ; Sun, 21 Sep 2003 17:01:34 -0500 (CDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.183] (may be forged)) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8LLxhk23648 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 21 Sep 2003 18:01:07 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h8LLo2ar006140 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 21 Sep 2003 17:50:33 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h8LH0vCq002963 for ; Sun, 21 Sep 2003 13:01:57 -0400 To: eap@frascone.com Subject: Re: [eap] section 5/state machines In-reply-to: Your message of "Tue, 16 Sep 2003 05:30:46 PDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <2962.1064163657@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 21 Sep 2003 13:00:57 -0400 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bernard" == Bernard Aboba writes: >> **** ii) upon failure to verify - ???? >> >> b) an EAP-Response/Sim/Challenge >> i) verify AT-MAC. If valid, transition to 3) SUCCESS. >> **** ii) If AT-MAC failes then ???? >> >> **** c) an EAP/Identity message. Transition to 1) START ???? >> >> d) OTHER MESSAGES - unsure. Drop? Bernard> I believe that dropping all but an EAP-Response/Sim/Challenge is Bernard> the Bernard> appropriate thing, given RFC 2284bis. Even Bernard> EAP-Response/Identity should Bernard> be dropped. I'm not convinced, given: 1) radius puts the responsability on the "NAS" to retransmit. 2) EAP puts the responsonability on the authenticator to retransmit. I have to read the EAP-state machine document though. >> When in state SUCCESS, receipt of any message results in a transition >> back to (0). Bernard> I don't believe this is correct. For example, an EAP-Request Bernard> should be Bernard> handled as per RFC 3579. okay. My opinion, as an implementor who came to this topic relatively cold a month ago, is that either EAP-SIM is plug-in actions to another state machine, or it documents a state machine itself. Either way, section 5 needs massive revisions. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP23ZSIqHRg3pndX9AQGtowP+Md3cD5J2F0psknBrke4eJubjniERxQcp 7Zc2UzqiXr2hVbLQy90U/DDme5WknksdQ/2SJY+LbeXJIJYAKvu6r68PsHRb/IOG bs4qSL8fQQXfLWv3ZxhOi2ZE4cgc/UoTXCMc8xV6liC7TSffrJPybxiNRK7WlIQU boVwC0cx4E8= =E+3Y -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 22 00:14:18 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18095 for ; Mon, 22 Sep 2003 00:14:13 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 98438580109; Sun, 21 Sep 2003 23:14:04 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 7253B580026 for ; Sun, 21 Sep 2003 23:13:29 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8M3e5N30354 for ; Sun, 21 Sep 2003 20:40:05 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Hotels for EAP WG Interim Meeting 10/15/03 in Herndon, VA Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 21 Sep 2003 20:40:05 -0700 (PDT) We've gotten some inquiries about alternative hotels in Herndon, VA. Here is a listing of hotels in the vicinity: Candlewood Suites Price Range: $59-95 13845 Sunrise Valley Dr., Herndon, VA 20171 Comfort Inn Dulles Price Range: $59-139 200 Elden Street, Herndon, VA 20170 Days Hotel And Conference Ctr Price Range: $65-232 2200 Centreville Road, Herndon, VA 20170 Embassy Suites Dulles Price Range: $32-299 13341 Woodland Park Rd, Herndon, VA 20171 Hilton Washington Dulles Airp Price Range: $46-277 13869 Park Central Road, Herndon, VA 20171 Holiday Inn Express Herndon Price Range: $35-149 485 Elden Street, Herndon, VA 20170 Homewood Suites Dulles Price Range: $150-179 13460 Sunrise Valley Dr., Herndon, VA 20171 Hyatt Dulles Price Range: $75-339 2300 Dulles Corner Blvd., Herndon, VA 20171 Oakwood Dulles Price Range: $109-202 13800 Jefferson Park Drive, Herndon, VA 20171 Summerfield Suites Dulles Price Range: $93-225 13700 Coppermine Rd, Herndon, VA 20171 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 22 07:22:47 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10010 for ; Mon, 22 Sep 2003 07:22:29 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4A29B580117; Mon, 22 Sep 2003 06:22:04 -0500 (CDT) Delivered-To: eap@frascone.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 49ACC58000C for ; Mon, 22 Sep 2003 06:21:17 -0500 (CDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8MBLFt12937 for ; Mon, 22 Sep 2003 14:21:15 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Sep 2003 14:21:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 14:21:06 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 14:21:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Comments on pasi.txt Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222F0@esebe023.ntc.nokia.com> Thread-Topic: [eap] Comments on pasi.txt Thread-Index: AcN//gkfIN0pVI1DSTi/JiQy4EvxSgA8/jzw From: To: , X-OriginalArrivalTime: 22 Sep 2003 11:21:06.0400 (UTC) FILETIME=[9D7F0600:01C380FB] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 22 Sep 2003 14:21:05 +0300 Content-Transfer-Encoding: quoted-printable Mohan Parthasarathy wrote: > Hi,=20 >=20 > I had a few questions/comments on the pasi's notes. >=20 > In the section, "client's point of view", >=20 > >The proposed key derivation mechanisms (e.g. AAA server > >includes the BSSID when deriving the key to be sent to the AP) > >authenticates also the BSSID (MAC address) of the AP (if the > >AAA server can check that the BSSID is correct). However, it's=20 > >not clear how much this actually helps the client in=20 > >determining if it's talking to the correct AP or not. Since=20 >=20 > I am not sure i understood the meaning of correct AP here. > Is the correct AP the one that the client thinks that will provide > the expected service ? AAA server "trusts" that this is the > "correct" AP and tells the client indirectly by including > the BSSID in key derivation. Why is this not sufficient ? > Could you elaborate ? By "correct AP", I meant any AP that provides the service expected by the user, and most likely the BSSID has nothing to do with the user's expectations... I think this is somewhat similar as DNS names and IP addresses. Suppose you want to connect to ExampleBank's on-line banking service. It wouldn't be very useful for the client to authenticate the server's IP address or MAC address (although these would uniquely identify the server). It's much more likely that the DNS name helps you in determining whether this is the expected service or not, although, just like SSID, it doesn't necessarily uniquely identify a single web server (most likely it's at least a cluster, and could be geographically distributed). > >"correct" here usually includes the intentions of the person=20 > >operating the client, the identities that are authenticated=20 > >should really be meaningful to that person. BSSID certainly=20 > >is not; SSID probably is (although it doesn't uniquely > >identify the AP). >=20 > What extra assurance the client gets by authenticating the "SSID" ? > What exactly does the AAA server do with the SSID ? Does it > verify that this AP is the right one for the SSID ?=20 Authenticating the SSID helps if the same AAA server (and AAA=20 server "identity") can provide different services. Suppose that=20 you can use your USIM card and EAP-AKA to authenticate to both=20 "Joe's_HotSpot" SSID and "Example_Inc_Intranet" SSID (this,=20 of course, means that both Joe's HotSpot and Example Inc. have some sort of agreement with your 3G operator). If the client now selects the "Example_Inc_Intranet" SSID from a=20 list and authenticates successfully, current specs (WPA1) don't=20 guarantee that he's actually talking to Example Inc's AP at all.=20 He could be talking to one of Joe's APs instead (if either Joe=20 has turned bad, or his access points have been compromised). (Actually, it seems that the current situation is even worse: the SSID is not included in the four-way handshake, so can an attacker just change it on the radio link, without any help from Joe? I'm not 100% sure about this...) This certainly violates the user's expectations, and it=20 would be prevented if the client authenticated the SSID.=20 One way to implement this would be that when the AAA server=20 receives a RADIUS Access-Request from Joe, it checks that the=20 Called-Station-Id attribute has indeed SSID "Joe's HotSpot" (presumably this would be configured in the AAA server when an agreeement with Joe is made), and the SSID is also included=20 in key derivation. > Eventually the client wants to be able to send/receive packets. > BSSID seems important for this purpose. So, don't you really > want to verify whether this "BSSID" can be associated with this > "SSID", and just include the BSSID in key derivation as that's > what is used eventually in sending and receiving packets.=20 BSSID is certainly important for sending and received packets,=20 but I'm not sure if it's necessary to authenticate it. It might=20 be easier to just associate the SSID and the key (PMK) directly,=20 skipping the BSSID (just like in SSL/TLS, the IP address is not authenticated)... Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 22 12:42:49 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24317 for ; Mon, 22 Sep 2003 12:42:30 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF85F580023; Mon, 22 Sep 2003 11:42:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id BD584580022 for ; Mon, 22 Sep 2003 11:41:58 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8MG8WG09974 for ; Mon, 22 Sep 2003 09:08:32 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [eap] Issue 176: Sync on key framework reqts Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 22 Sep 2003 09:08:32 -0700 (PDT) Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 9/22/2003 Reference: Document: EAP-05 Comment type: T Priority: S Section: 7.2.1, 7.10 Rationale/Explanation of issue: Since the EAP Key Framework document is informational, all normative statements in it relating to EAP or EAP methods (see Section 4.2.1) either need to be included in RFC 2284bis or removed. Add to Section 7.2.1: Session independence The demonstration that passive attacks (such as capture of the EAP conversation) or active attacks (including compromise of the MSK, EMSK, TSKs or TEKs) does not enable compromise of subsequent or prior MSKs, EMSKs, TSKs or TEKs. Add: "Session indep.: N/A" to Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 change Section 7.10 to: "It is possible for the peer and EAP server to mutually authenticate and derive keys. In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets. EAP Methods deriving keys MUST provide for mutual authentication between the EAP peer and the EAP Server. The MSK and EMSK MUST NOT be used directly to protect data; however, they are of sufficient size to enable derivation of a AAA-Key subsequently used to derive Transient Session Keys (TSKs) for use with the selected ciphersuite. Each ciphersuite is responsible for specifying how to derive the TSKs from the AAA-Key. In order to ensure freshness of Transient Session Keys (TSKs) even in cases where one party may not have a high quality random number generator, EAP methods generating keys MUST support a two-nonce exchange in the derivation of the MSK and EMSK, using nonces of at least 128-bits. EAP methods export the MSK and EMSK and not Transient Session Keys so as to allow EAP methods to be ciphersuite and media independent. Keying material exported by EAP methods MUST be independent of the ciphersuite negotiated to protect data. Depending on the lower layer, EAP methods may run before or after ciphersuite negotiation, so that the selected ciphersuite may not be known to the EAP method. By providing keying material usable with any ciphersuite, EAP methods can used with a wide range of ciphersuites and media. An EAP method deriving keys MUST specify how to derive Transient EAP Keys (TEKs), used for protection of the EAP conversation. TEKs MUST remain local to the EAP method and MUST NOT be exported or provided to third parties. It is RECOMMENDED that methods providing integrity protection of EAP packets include coverage of all the EAP header fields, including the Code, Identifier, Length, Type and Type-Data fields. In order to preserve algorithm independence, EAP methods deriving keys SHOULD support (and document) the protected negotiation of the ciphersuite used to protect the EAP conversation between the peer and server. This is distinct from the ciphersuite negotiated between the peer and authenticator, used to protect data. The strength of Transient Session Keys (TSKs) and Transient EAP Keys (TEKs) used to protect data is ultimately dependent on the strength of keys generated by the EAP method. If an EAP method does not produce keying material of sufficient strength, then the TSKs and TEKs may be subject to brute force attack. EAP methods supporting key derivation MUST be capable of generating an MSK and EMSK, each with an effective key strength of at least 128 bits. Methods supporting key derivation MUST demonstrate cryptographic separation between the TEK, MSK and EMSK branches of the EAP key hierarchy. Without violating a fundamental cryptographic assumption (such as the non-invertibility of a one-way function) an attacker recovering the TEKs, MSK or EMSK MUST NOT be able to recover the other quantities with a level of effort less than brute force. Since Transient Session Keys (TSKs) are derived from the MSK, if branch independence holds, then it is also true that the TSKs are cryptographically separate from the EMSK and TEKs. Non-overlapping substrings of the MSK MUST be cryptographically separate from each other, as defined in Section 7.2.1. That is, knowledge of one substring MUST NOT help in recovering some other substring without breaking some hard cryptographic assumption. This is required because some existing ciphersuites form TSKs by simply splitting the AAA-Key to pieces of appropriate length. Likewise, non-overlapping substrings of the EMSK MUST be cryptographically separate from each other, and from substrings of the MSK. The EMSK is reserved for future use and MUST remain on the EAP peer and EAP server where it is derived; it MUST NOT be transported to, or shared with, additional parties, or used to derive any other keys. (This restriction will be relaxed in a future document that specifies how the EMSK can be used.) Since EAP does not provide for explicit key lifetime negotiation, EAP peers, authenticators and authentication servers MUST be prepared for situations in which one or parties discard key state which remains valid on another party. This specification does not provide detailed guidance on how EAP methods derive the MSK, EMSK and TEKs; how the AAA-Key is derived from the MSK and/or EMSK; or how the TSKs are be derived from the AAA-Key. The development and validation of key derivation algorithms is difficult, and as a result EAP methods SHOULD reuse existing key derivation algorithms (such as those specified in IKE [RFC2409], or TLS [RFC2246]), rather than inventing new ones. EAP methods requesting publication as an RFC MUST provide citations to literature justifying the security of the chosen algorithms. EAP methods SHOULD also utilize well established and analyzed mechanisms for MSK, EMSK, TSK and TEK derivation." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 22 13:05:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25615 for ; Mon, 22 Sep 2003 13:04:59 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E9B65801B8; Mon, 22 Sep 2003 12:05:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from fw2.gdm.de (fw2.gdm.de [193.108.184.154]) by mail.frascone.com (Postfix) with ESMTP id 08995580022 for ; Mon, 22 Sep 2003 12:04:07 -0500 (CDT) Received: by fw2.gdm.de (8.11.6p2G/8.11.6) id h8MH43215991 for eap@frascone.com; Mon, 22 Sep 2003 19:04:03 +0200 (CEST) Received: (from localhost) by fw2.gdm.de (MSCAN) id 2/fw2.gdm.de/smtp-gw/mscan; Mon Sep 22 19:04:03 2003 From: Hubert.Ertl@de.gi-de.com To: eap@frascone.com Message-ID: X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0.1CF1|March 04, 2003) at 22.09.2003 19:01:40 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by amavisd-new Subject: [eap] Hubert Ertl/GDM/GuD is out of the office. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 22 Sep 2003 19:01:58 +0200 Content-Transfer-Encoding: quoted-printable Ich werde ab 22.09.2003 nicht im B=FCro sein. Ich kehre zur=FCck am 26.09.2003. I am away from my email. I will respond to your message when back on September 26th.= _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 22 20:05:12 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18302 for ; Mon, 22 Sep 2003 20:04:59 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 54B185801BD; Mon, 22 Sep 2003 19:05:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from smtp803.mail.sc5.yahoo.com (smtp803.mail.sc5.yahoo.com [66.163.168.182]) by mail.frascone.com (Postfix) with SMTP id 7123558000C for ; Mon, 22 Sep 2003 19:04:09 -0500 (CDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@209.137.156.6 with login) by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 22 Sep 2003 23:05:53 -0000 Message-ID: <008101c3815e$127592f0$c80ba8c0@adithya> From: "Mohan Parthasarathy" To: , References: <005701c38159$1ef63430$c80ba8c0@adithya> Subject: Re: [eap] Comments on pasi.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 22 Sep 2003 16:05:50 -0700 Content-Transfer-Encoding: 7bit > > > > I had a few questions/comments on the pasi's notes. > > > > In the section, "client's point of view", > > > > >The proposed key derivation mechanisms (e.g. AAA server > > >includes the BSSID when deriving the key to be sent to the AP) > > >authenticates also the BSSID (MAC address) of the AP (if the > > >AAA server can check that the BSSID is correct). However, it's > > >not clear how much this actually helps the client in > > >determining if it's talking to the correct AP or not. Since > > > > I am not sure i understood the meaning of correct AP here. > > Is the correct AP the one that the client thinks that will provide > > the expected service ? AAA server "trusts" that this is the > > "correct" AP and tells the client indirectly by including > > the BSSID in key derivation. Why is this not sufficient ? > > Could you elaborate ? > > By "correct AP", I meant any AP that provides the service > expected by the user, and most likely the BSSID has nothing > to do with the user's expectations... > > I think this is somewhat similar as DNS names and IP addresses. > Suppose you want to connect to ExampleBank's on-line banking > service. It wouldn't be very useful for the client to > authenticate the server's IP address or MAC address (although > these would uniquely identify the server). It's much more likely > that the DNS name helps you in determining whether this is the > expected service or not, although, just like SSID, it doesn't > necessarily uniquely identify a single web server (most likely > it's at least a cluster, and could be geographically > distributed). > Ok, this helps understand better.. > > >"correct" here usually includes the intentions of the person > > >operating the client, the identities that are authenticated > > >should really be meaningful to that person. BSSID certainly > > >is not; SSID probably is (although it doesn't uniquely > > >identify the AP). > > > > What extra assurance the client gets by authenticating the "SSID" ? > > What exactly does the AAA server do with the SSID ? Does it > > verify that this AP is the right one for the SSID ? > > Authenticating the SSID helps if the same AAA server (and AAA > server "identity") can provide different services. Suppose that > you can use your USIM card and EAP-AKA to authenticate to both > "Joe's_HotSpot" SSID and "Example_Inc_Intranet" SSID (this, > of course, means that both Joe's HotSpot and Example Inc. > have some sort of agreement with your 3G operator). > > If the client now selects the "Example_Inc_Intranet" SSID from a > list and authenticates successfully, current specs (WPA1) don't > guarantee that he's actually talking to Example Inc's AP at all. > He could be talking to one of Joe's APs instead (if either Joe > has turned bad, or his access points have been compromised). > > (Actually, it seems that the current situation is even worse: > the SSID is not included in the four-way handshake, so can > an attacker just change it on the radio link, without any > help from Joe? I'm not 100% sure about this...) > > This certainly violates the user's expectations, and it > would be prevented if the client authenticated the SSID. > One way to implement this would be that when the AAA server > receives a RADIUS Access-Request from Joe, it checks that the > Called-Station-Id attribute has indeed SSID "Joe's HotSpot" > (presumably this would be configured in the AAA server when > an agreeement with Joe is made), and the SSID is also included > in key derivation. > Ok. There are two parts to it. The first part is the authentication i.e verification of SSID in the called-station-id attribute. The second part is including the SSID in the key derivation. I assume you meant that both the SSID and BSSID and should be included in the key derivation. > > Eventually the client wants to be able to send/receive packets. > > BSSID seems important for this purpose. So, don't you really > > want to verify whether this "BSSID" can be associated with this > > "SSID", and just include the BSSID in key derivation as that's > > what is used eventually in sending and receiving packets. > > BSSID is certainly important for sending and received packets, > but I'm not sure if it's necessary to authenticate it. It might > be easier to just associate the SSID and the key (PMK) directly, > skipping the BSSID (just like in SSL/TLS, the IP address is > not authenticated)... > Did you mean skip the BSSID altogether from authentication and key derivation ? thanks mohan > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Sep 23 13:03:06 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24455 for ; Tue, 23 Sep 2003 13:03:04 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0B08A58011E; Tue, 23 Sep 2003 12:03:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from fw2.gdm.de (fw2.gdm.de [193.108.184.154]) by mail.frascone.com (Postfix) with ESMTP id 59F9B58001E for ; Tue, 23 Sep 2003 12:02:53 -0500 (CDT) Received: by fw2.gdm.de (8.11.6p2G/8.11.6) id h8NH2pa00447 for eap@frascone.com; Tue, 23 Sep 2003 19:02:51 +0200 (CEST) Received: (from localhost) by fw2.gdm.de (MSCAN) id 2/fw2.gdm.de/smtp-gw/mscan; Tue Sep 23 19:02:51 2003 From: Hubert.Ertl@de.gi-de.com To: eap@frascone.com Message-ID: X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0.1CF1|March 04, 2003) at 23.09.2003 19:00:28 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by amavisd-new Subject: [eap] Hubert Ertl/GDM/GuD is out of the office. Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 23 Sep 2003 19:00:54 +0200 Content-Transfer-Encoding: quoted-printable Ich werde ab 22.09.2003 nicht im B=FCro sein. Ich kehre zur=FCck am 26.09.2003. I am away from my email. I will respond to your message when back on September 26th.= _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 24 07:43:17 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08311 for ; Wed, 24 Sep 2003 07:43:06 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EE3D6580109; Wed, 24 Sep 2003 06:43:06 -0500 (CDT) Delivered-To: eap@frascone.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id E5D36580010 for ; Wed, 24 Sep 2003 06:42:37 -0500 (CDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OBgVt22875 for ; Wed, 24 Sep 2003 14:42:31 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 14:42:31 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:42:31 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 14:35:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Issue 176: Sync on key framework reqts Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BBF4@esebe023.ntc.nokia.com> Thread-Topic: [eap] Issue 176: Sync on key framework reqts Thread-Index: AcOBKKkz0mnM2GbQRLebdfdstXDl4wBXNyHA From: To: , X-OriginalArrivalTime: 24 Sep 2003 11:35:20.0313 (UTC) FILETIME=[EF4B4E90:01C3828F] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 24 Sep 2003 14:35:18 +0300 Content-Transfer-Encoding: quoted-printable Hi, I have a couple of comments to your proposed text: > Add to Section 7.2.1: >=20 > Session independence > The demonstration that passive attacks (such as capture of the > EAP conversation) or active attacks (including compromise of the > MSK, EMSK, TSKs or TEKs) does not enable compromise of subsequent > or prior MSKs, EMSKs, TSKs or TEKs. Currently 2284bis doesn't specify what a TEK is, and I fear that specifying it would unnecessarily rule out perfectly ok key agreement protocols. But if we haven't defined what a TEK=20 is, we probably shouldn't have requirements about it! So, I propose that we remove the TEKs from the paragraph above (and all other references to them); IMHO they're an internal protocol detail, and not all protocols will have similar internal=20 structure--if they did, we wouldn't need this Extensibility thing=20 in the first place :-) > The MSK and EMSK MUST NOT be used directly to protect data; > however, they are of sufficient size to enable derivation > of a AAA-Key subsequently used to derive Transient Session > Keys (TSKs) for use with the selected ciphersuite. > Each ciphersuite is responsible for specifying how to > derive the TSKs from the AAA-Key. BTW, currently the text doesn't say who exactly is=20 responsible for specifying how to derive the AAA-Key from=20 the MSK. This should probably be clarified. > In order to ensure freshness of Transient Session Keys > (TSKs) even in cases where one party may not have a high > quality random number generator, EAP methods generating > keys MUST support a two-nonce exchange in the derivation > of the MSK and EMSK, using nonces of at least 128-bits. I think this is an unnecessary implementation detail; there are other perfectly valid ways to ensure that your keys are fresh. Besides, some algorithms simply can't be made to work without both parties having good RNGs (e.g. EAP-TLS/PEAP=20 when used with DHE_DSS ciphersuites). We might leave it there with a "SHOULD" or "RECOMMENDED" text, though. In addition, the text probably should refer to=20 freshness of MSK/EMSK, since e.g. in 802.11i the TSKs are=20 always fresh even when the MSK isn't. Proposed replacement: "EAP methods SHOULD ensure the freshness of MSK and EMSK even in cases where one party may not have a high quality=20 random number generator. A RECOMMENDED method is to include a two-nonce exchange in the derivation of the MSK and EMSK, using nonces of at least 128 bits." > The strength of Transient Session Keys (TSKs) and > Transient EAP Keys (TEKs) used to protect data is > ultimately dependent on the strength of keys generated > by the EAP method. If an EAP method does not produce keying > material of sufficient strength, then the TSKs and TEKs > may be subject to brute force attack. EAP methods > supporting key derivation MUST be capable of generating > an MSK and EMSK, each with an effective key strength > of at least 128 bits. Appropriate key strength is IMHO a deployment issue, not=20 something that needs to be fixed here. I think it's enough to require methods to disclose their effective key strength (as is already required), and let the administrators decide what is an acceptable length for their environment. For instance, to fullfill the above requirement, EAP-TLS and PEAP would have to prohibit the use of 1024-bit RSA=20 keys--something quite common today, and definitely=20 "secure enough" for this purpose. Proposed replacement: delete the whole paragraph (we already have a requirement to disclose key strength elsewhere). > The development and validation of key derivation algorithms is > difficult, and as a result EAP methods SHOULD reuse existing key > derivation algorithms (such as those specified in IKE [RFC2409], or > TLS [RFC2246]), rather than inventing new ones. EAP methods > requesting publication as an RFC MUST provide citations to > literature justifying the security of the chosen algorithms. EAP > methods SHOULD also utilize well established and analyzed mechanisms > for MSK, EMSK, TSK and TEK derivation." While I can't disagree about the recommendation to reuse existing work as much as possible, why are we adding a new "MUST" level=20 requirement here? What exactly is the existing literature required to justify?=20 For instance, just pointing out that e.g. some particular PRF or encryption algorithm is OK doesn't guarantee that a protocol=20 composed from them is OK. Similarly, just pointing out that=20 TLS itself is OK doesn't guarantee that an EAP method using=20 TLS is ok (like we saw with the MitM attack against PEAP=20 and EAP-TTLS). I'm also a bit worried that we might be placing unnecessary burden=20 on authors of EAP methods. IMHO it's better to see the methods published at IETF than not published all (and the process of=20 getting something published at IETF is slow enough as it is). Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 24 10:28:31 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17800 for ; Wed, 24 Sep 2003 10:28:08 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AB92358010E; Wed, 24 Sep 2003 09:28:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 7FEC3580010 for ; Wed, 24 Sep 2003 09:27:15 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8ODrZ109520; Wed, 24 Sep 2003 06:53:35 -0700 From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: eap@frascone.com Subject: RE: [eap] Issue 176: Sync on key framework reqts In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BBF4@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A608BBF4@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 24 Sep 2003 06:53:35 -0700 (PDT) > So, I propose that we remove the TEKs from the paragraph above > (and all other references to them); IMHO they're an internal > protocol detail, and not all protocols will have similar internal > structure--if they did, we wouldn't need this Extensibility thing > in the first place :-) OK. > > The MSK and EMSK MUST NOT be used directly to protect data; > > however, they are of sufficient size to enable derivation > > of a AAA-Key subsequently used to derive Transient Session > > Keys (TSKs) for use with the selected ciphersuite. > > Each ciphersuite is responsible for specifying how to > > derive the TSKs from the AAA-Key. > > BTW, currently the text doesn't say who exactly is > responsible for specifying how to derive the AAA-Key from > the MSK. This should probably be clarified. Yes. How about: "The AAA-Key is derived from the keying material exported by the EAP method (MSK and EMSK). This derivation occurs on the AAA server. For details, see [KEYFRAME]." > > In order to ensure freshness of Transient Session Keys > > (TSKs) even in cases where one party may not have a high > > quality random number generator, EAP methods generating > > keys MUST support a two-nonce exchange in the derivation > > of the MSK and EMSK, using nonces of at least 128-bits. > > I think this is an unnecessary implementation detail; there > are other perfectly valid ways to ensure that your keys are > fresh. Besides, some algorithms simply can't be made to work > without both parties having good RNGs (e.g. EAP-TLS/PEAP > when used with DHE_DSS ciphersuites). > > We might leave it there with a "SHOULD" or "RECOMMENDED" > text, though. In addition, the text probably should refer to > freshness of MSK/EMSK, since e.g. in 802.11i the TSKs are > always fresh even when the MSK isn't. Proposed replacement: > > "EAP methods SHOULD ensure the freshness of MSK and EMSK > even in cases where one party may not have a high quality > random number generator. A RECOMMENDED method is to include > a two-nonce exchange in the derivation of the MSK and EMSK, > using nonces of at least 128 bits." Another concern that motivated this reqts was EAP SA naming. For that purpose I'm not sure that a two-nonce exchange is required, just a quantity from each side that together are very likely to be temporally unique. So maybe it is: "EAP methods SHOULD ensure the freshness of the MSK and EMSK even in cases where one party may not have a high quality random number generator. A RECOMMENDED method is for each party to provide a nonce of at least 128 bits, used in the derivation of the MSK and EMSK. The combination of the peer and server nonce uniquely identifies the exchange." > > The strength of Transient Session Keys (TSKs) and > > Transient EAP Keys (TEKs) used to protect data is > > ultimately dependent on the strength of keys generated > > by the EAP method. If an EAP method does not produce keying > > material of sufficient strength, then the TSKs and TEKs > > may be subject to brute force attack. EAP methods > > supporting key derivation MUST be capable of generating > > an MSK and EMSK, each with an effective key strength > > of at least 128 bits. > > Appropriate key strength is IMHO a deployment issue, not > something that needs to be fixed here. I think it's enough > to require methods to disclose their effective key strength > (as is already required), and let the administrators > decide what is an acceptable length for their environment. I think this requirement is about being capable of generating a strong key if it is desired. If it is desired to deploy using a strong key, then the method needs to support that mode of operation. So perhaps this should be: "The strength of Transient Session Keys (TSKs) used to protect data is ultimately dependent on the strength of keys generated by the EAP method. If an EAP method cannot produce keying material of sufficient strength, then the TSKs may be subject to brute force attack. In order to enable deployments requiring strong keys, EAP methods supporting key derivation SHOULD be capable of generating an MSK and EMSK, each with an effective key strength of at least 128 bits." > For instance, to fullfill the above requirement, EAP-TLS > and PEAP would have to prohibit the use of 1024-bit RSA > keys--something quite common today, and definitely > "secure enough" for this purpose. This requirement is about what should be implemented not what should be used. > > The development and validation of key derivation algorithms is > > difficult, and as a result EAP methods SHOULD reuse existing key > > derivation algorithms (such as those specified in IKE [RFC2409], or > > TLS [RFC2246]), rather than inventing new ones. EAP methods > > requesting publication as an RFC MUST provide citations to > > literature justifying the security of the chosen algorithms. EAP > > methods SHOULD also utilize well established and analyzed mechanisms > > for MSK, EMSK, TSK and TEK derivation." > > While I can't disagree about the recommendation to reuse existing > work as much as possible, why are we adding a new "MUST" level > requirement here? What exactly is the existing literature required > to justify? If a mechanism is well established and analyzed, presumably literature citations are not an issue. So I think this is redundant. Also, EAP methods do not derive TSKs. Perhaps it should be: "The development and validation of key derivation algorithms is difficult, and as a result EAP methods SHOULD reuse well established and analyzed mechanisms for key derivation (such as those specified in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones. EAP methods SHOULD also utilize well established and analyzed mechanisms for MSK and EMSK derivation." > For instance, just pointing out that e.g. some particular PRF > or encryption algorithm is OK doesn't guarantee that a protocol > composed from them is OK. Similarly, just pointing out that > TLS itself is OK doesn't guarantee that an EAP method using > TLS is ok (like we saw with the MitM attack against PEAP > and EAP-TTLS). Yes, that's definitely true. Do you have any text to recommend? > I'm also a bit worried that we might be placing unnecessary burden > on authors of EAP methods. IMHO it's better to see the methods > published at IETF than not published all (and the process of > getting something published at IETF is slow enough as it is). I'd agree. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 24 13:54:07 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28672 for ; Wed, 24 Sep 2003 13:54:01 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58749580121; Wed, 24 Sep 2003 12:54:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id 99D87580010 for ; Wed, 24 Sep 2003 12:53:58 -0500 (CDT) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8OHqJHo003596; Wed, 24 Sep 2003 10:53:55 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.65.241]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Sep 2003 10:57:21 -0700 From: "Joseph Salowey" To: "'Bernard Aboba'" , Cc: Subject: RE: [eap] Issue 176: Sync on key framework reqts Message-ID: <011401c382c4$abe09950$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 24 Sep 2003 17:57:21.0531 (UTC) FILETIME=[4D679CB0:01C382C5] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 24 Sep 2003 10:52:49 -0700 Content-Transfer-Encoding: 7bit > > We might leave it there with a "SHOULD" or "RECOMMENDED" > text, though. > > In addition, the text probably should refer to freshness of > MSK/EMSK, > > since e.g. in 802.11i the TSKs are always fresh even when the MSK > > isn't. Proposed replacement: > > > > "EAP methods SHOULD ensure the freshness of MSK and EMSK > > even in cases where one party may not have a high quality > > random number generator. A RECOMMENDED method is to include > > a two-nonce exchange in the derivation of the MSK and EMSK, > > using nonces of at least 128 bits." > > Another concern that motivated this reqts was EAP SA naming. > For that purpose I'm not sure that a two-nonce exchange is > required, just a quantity from each side that together are > very likely to be temporally unique. So maybe it is: > > "EAP methods SHOULD ensure the freshness of the MSK and EMSK > even in cases where one party may not have a high quality > random number generator. A RECOMMENDED method is for each > party to provide a nonce of at least 128 bits, used in the > derivation of the MSK and EMSK. The combination of the peer > and server nonce uniquely identifies the exchange." [Joe] Is this the only way we are specifying names? It seems that this should be up to the EAP-method to define how an identifier is derived for the exchange. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 24 14:55:11 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01178 for ; Wed, 24 Sep 2003 14:55:04 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC2DD58012D; Wed, 24 Sep 2003 13:55:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id 846E8580121 for ; Wed, 24 Sep 2003 13:54:17 -0500 (CDT) Received: from sandelman.ottawa.on.ca ([2002:cd96:c8ed::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8OIs5e12285 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 24 Sep 2003 14:54:06 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h8OIo2ah023812 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 24 Sep 2003 14:50:02 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h8OFbpqe013856 for ; Wed, 24 Sep 2003 11:39:37 -0400 To: eap Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <13855.1064417871@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Subject: [eap] question about AT_MAC text Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 24 Sep 2003 11:37:51 -0400 (Sorry if this is a resend?) -----BEGIN PGP SIGNED MESSAGE----- A25) Section 12 is said to be authoritative by section 8.1 Section 8.1 says the contents are message specific. How much of the EAP packet is HMAC'ed? All of it, or just the EAP-SIM portion? ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP2hoAYqHRg3pndX9AQEj0AQAlwY6O8sPPutwcx7UbTBRrIwb/+xcqkvI uvTQOBlhI/T1kckJSZIyWwnaF2SrH3uqPLtP/gPXcGpc+Kx4T1fF74N/sLAqrpt4 hU5T9hMTw6tc7T1OMacCUp2L1TVeK52RBJSusDAo4fe2K6DbdnWSKTNBin6e3ZK6 rlCLlePch7s= =1Y6Y -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 24 15:09:12 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02181 for ; Wed, 24 Sep 2003 15:09:01 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 551605801B5; Wed, 24 Sep 2003 14:09:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 027EC58012D for ; Wed, 24 Sep 2003 14:08:18 -0500 (CDT) Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 24 Sep 2003 12:04:20 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8OJ6EJs007450; Wed, 24 Sep 2003 12:06:15 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.65.241]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Sep 2003 12:10:45 -0700 From: "Joseph Salowey" To: "'Michael Richardson'" , "'eap'" Subject: RE: [eap] question about AT_MAC text Message-ID: <012001c382ce$ecc56860$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <13855.1064417871@marajade.sandelman.ottawa.on.ca> Importance: Normal X-OriginalArrivalTime: 24 Sep 2003 19:10:45.0418 (UTC) FILETIME=[8E5370A0:01C382CF] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 24 Sep 2003 12:06:13 -0700 Content-Transfer-Encoding: 7bit All of the EAP packet should be HMAC'ed. Additional data is appended to the EAP packet and included in the MAC. The value of this additional data depends upon the EAP-SIM message type. Joe > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Michael Richardson > Sent: Wednesday, September 24, 2003 8:38 AM > To: eap > Subject: [eap] question about AT_MAC text > > > > (Sorry if this is a resend?) > > -----BEGIN PGP SIGNED MESSAGE----- > > > A25) Section 12 is said to be authoritative by section 8.1 > Section 8.1 says the contents are message specific. > How much of the EAP packet is HMAC'ed? All of it, or just > the EAP-SIM portion? > > ] Out and about in Ottawa. hmmm... beer. > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device > driver[ ] > panic("Just another Debian/notebook using, kernel hacking, > security guy"); [ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Finger me for keys - custom hacks make this fully PGP2 compat > > iQCVAwUBP2hoAYqHRg3pndX9AQEj0AQAlwY6O8sPPutwcx7UbTBRrIwb/+xcqkvI > uvTQOBlhI/T1kckJSZIyWwnaF2SrH3uqPLtP/gPXcGpc+Kx4T1fF74N/sLAqrpt4 > hU5T9hMTw6tc7T1OMacCUp2L1TVeK52RBJSusDAo4fe2K6DbdnWSKTNBin6e3ZK6 > rlCLlePch7s= > =1Y6Y > -----END PGP SIGNATURE----- > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Sep 24 19:55:09 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15799 for ; Wed, 24 Sep 2003 19:55:03 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D16E580127; Wed, 24 Sep 2003 18:55:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 0161E580010 for ; Wed, 24 Sep 2003 18:54:32 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8ONKit10032; Wed, 24 Sep 2003 16:20:44 -0700 From: Bernard Aboba To: Joseph Salowey Cc: Pasi.Eronen@nokia.com, eap@frascone.com Subject: RE: [eap] Issue 176: Sync on key framework reqts In-Reply-To: <011401c382c4$abe09950$0300000a@amer.cisco.com> Message-ID: References: <011401c382c4$abe09950$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 24 Sep 2003 16:20:44 -0700 (PDT) > > "EAP methods SHOULD ensure the freshness of the MSK and EMSK > > even in cases where one party may not have a high quality > > random number generator. A RECOMMENDED method is for each > > party to provide a nonce of at least 128 bits, used in the > > derivation of the MSK and EMSK. The combination of the peer > > and server nonce uniquely identifies the exchange." > > [Joe] Is this the only way we are specifying names? It seems that this > should be up to the EAP-method to define how an identifier is derived > for the exchange. I don't think this paragraph should be talking about naming (since there is no other discussion in RFC 2284bis about this. Maybe just delete the last sentence. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 25 07:50:41 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19725 for ; Thu, 25 Sep 2003 07:50:12 -0400 (EDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 716FF58012A; Thu, 25 Sep 2003 06:50:06 -0500 (CDT) Delivered-To: eap@frascone.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 969DB58000F for ; Thu, 25 Sep 2003 06:49:44 -0500 (CDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8PA6s618961 for ; Thu, 25 Sep 2003 13:06:54 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 25 Sep 2003 13:06:53 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 25 Sep 2003 13:06:52 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 25 Sep 2003 13:06:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Issue 176: Sync on key framework reqts Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6B8C7D7@esebe023.ntc.nokia.com> Thread-Topic: [eap] Issue 176: Sync on key framework reqts Thread-Index: AcOCp/Op01q18jZvRYKoONflhpcH4gAm/8YQ From: To: Cc: X-OriginalArrivalTime: 25 Sep 2003 10:06:51.0864 (UTC) FILETIME=[BDA00580:01C3834C] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 25 Sep 2003 13:06:51 +0300 Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: > > BTW, currently the text doesn't say who exactly is > > responsible for specifying how to derive the AAA-Key from > > the MSK. This should probably be clarified. >=20 > Yes. How about: >=20 > "The AAA-Key is derived from the keying material exported by the EAP > method (MSK and EMSK). This derivation occurs on the AAA server. =20 > For details, see [KEYFRAME]." Hmm, does this create a dependency to the keying framework? I'm not sure; but it's not possible to actually implement=20 a working system without knowing how this derivation is done... Also, since many deployed systems just use AAA-Key=3D=3DMSK, this certainly should be documented somewhere... how about this? "The AAA-Key is derived from the keying material exported by the=20 EAP method (MSK and EMSK). This derivation occurs on the AAA server. In many existing protocols that use EAP, the AAA-Key and MSK=20 are equivalent, but more complicated mechanisms are possible (see [KEYFRAME] for details)." > Another concern that motivated this reqts was EAP SA naming. For=20 > that purpose I'm not sure that a two-nonce exchange is required,=20 > just a quantity from each side that together are very likely to=20 > be temporally unique. So maybe it is: >=20 > "EAP methods SHOULD ensure the freshness of the MSK and EMSK=20 > even in cases where one party may not have a high quality=20 > random number generator. A RECOMMENDED method is for each party=20 > to provide a nonce of at least 128 bits, used in the derivation=20 > of the MSK and EMSK. The combination of the peer and server=20 > nonce uniquely identifies the exchange." This works for me (except that I'm not sure if the=20 last sentence is actually necessary). > I think this requirement is about being capable of generating=20 > a strong key if it is desired. If it is desired to deploy using=20 > a strong key, then the method needs to support that mode of=20 > operation. So perhaps this should be: >=20 > "The strength of Transient Session Keys (TSKs) used to protect > data is ultimately dependent on the strength of keys generated > by the EAP method. If an EAP method cannot produce keying material of > of sufficient strength, then the TSKs may be subject to brute=20 > force attack. In order to enable deployments requiring strong=20 > keys, EAP methods supporting key derivation SHOULD be capable=20 > of generating an MSK and EMSK, each with an effective key=20 > strength of at least 128 bits." Looks ok! =20 > > While I can't disagree about the recommendation to reuse existing > > work as much as possible, why are we adding a new "MUST" level > > requirement here? What exactly is the existing literature required > > to justify? >=20 > If a mechanism is well established and analyzed, presumably=20 > literature citations are not an issue. So I think this is=20 > redundant. Also, EAP methods do not derive TSKs. Perhaps it=20 > should be: >=20 > "The development and validation of key derivation algorithms=20 > is difficult, and as a result EAP methods SHOULD reuse well=20 > established and analyzed mechanisms for key derivation (such as=20 > those specified in IKE [RFC2409] or TLS [RFC2246]), rather than=20 > inventing new ones. EAP methods SHOULD also utilize well=20 > established and analyzed mechanisms for MSK and EMSK derivation." Ok. > > For instance, just pointing out that e.g. some particular PRF > > or encryption algorithm is OK doesn't guarantee that a protocol > > composed from them is OK. Similarly, just pointing out that > > TLS itself is OK doesn't guarantee that an EAP method using > > TLS is ok (like we saw with the MitM attack against PEAP > > and EAP-TTLS). >=20 > Yes, that's definitely true. Do you have any text to recommend? Hmm... I'm not sure if we actually need any text about this.=20 Presumably the "security considerations" section for the EAP method should discuss any known weaknesses, and the yet-unknown weaknesses we by definition don't about yet :-) And I really wouldn't like to see a requirement saying that "EAP methods must have formal security proofs" or anything like that. So, the recommendation to reuse existing work as=20 much as possible might be sufficient here? Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 25 14:03:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10680 for ; Thu, 25 Sep 2003 14:03:03 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 718465801BD; Thu, 25 Sep 2003 13:03:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 415AB5801C0; Thu, 25 Sep 2003 13:03:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B5F2B5801C0 for ; Thu, 25 Sep 2003 13:02:11 -0500 (CDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 9E91C5801BD for ; Thu, 25 Sep 2003 13:02:10 -0500 (CDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F1FBA6A90D; Thu, 25 Sep 2003 21:02:07 +0300 (EEST) Message-ID: <3F732CCA.9010201@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aboba@internaut.com, eap@frascone.com Subject: Re: [eap] Issue 176: Sync on key framework reqts References: <052E0C61B69C3741AFA5FE88ACC775A6B8C7D7@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6B8C7D7@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 25 Sep 2003 20:58:34 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: >>"The AAA-Key is derived from the keying material exported by the EAP >>method (MSK and EMSK). This derivation occurs on the AAA server. >>For details, see [KEYFRAME]." > > > Hmm, does this create a dependency to the keying framework? > I'm not sure; but it's not possible to actually implement > a working system without knowing how this derivation is done... > > Also, since many deployed systems just use AAA-Key==MSK, this > certainly should be documented somewhere... how about this? Yes, this is important. > "The AAA-Key is derived from the keying material exported by the > EAP method (MSK and EMSK). This derivation occurs on the AAA server. > In many existing protocols that use EAP, the AAA-Key and MSK > are equivalent, but more complicated mechanisms are possible > (see [KEYFRAME] for details)." Works for me. > Hmm... I'm not sure if we actually need any text about this. > Presumably the "security considerations" section for the EAP > method should discuss any known weaknesses, and the yet-unknown > weaknesses we by definition don't about yet :-) And I really > wouldn't like to see a requirement saying that "EAP methods > must have formal security proofs" or anything like that. Agree. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 25 15:56:14 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18486 for ; Thu, 25 Sep 2003 15:56:06 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E31FA5801C2; Thu, 25 Sep 2003 14:56:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0B70158010A; Thu, 25 Sep 2003 14:56:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 12233580029 for ; Thu, 25 Sep 2003 14:55:34 -0500 (CDT) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 1B79258010A for ; Thu, 25 Sep 2003 14:55:32 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8PJLm116175 for ; Thu, 25 Sep 2003 12:21:48 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed resolution to Issue 176 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 25 Sep 2003 12:21:48 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Based on the discussion of Issue 176, I'd like to propose the following potential resolution. Add to Section 7.2.1: Session independence The demonstration that passive attacks (such as capture of the EAP conversation) or active attacks (including compromise of the MSK, EMSK, TSKs or TEKs) does not enable compromise of subsequent or prior MSKs, EMSKs, TSKs or TEKs. Add: "Session indep.: N/A" to Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 Change Section 7.10 to the following: "It is possible for the peer and EAP server to mutually authenticate and derive keys. In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets. EAP Methods deriving keys MUST provide for mutual authentication between the EAP peer and the EAP Server. The MSK and EMSK MUST NOT be used directly to protect data; however, they are of sufficient size to enable derivation of a AAA-Key subsequently used to derive Transient Session Keys (TSKs) for use with the selected ciphersuite. Each ciphersuite is responsible for specifying how to derive the TSKs from the AAA-Key. The AAA-Key is derived from the keying material exported by the EAP method (MSK and EMSK). This derivation occurs on the AAA server. In many existing protocols that use EAP, the AAA-Key and MSK are equivalent, but more complicated mechanisms are possible (see [KEYFRAME] for details). EAP methods SHOULD ensure the freshness of the MSK and EMSK even in cases where one party may not have a high quality random number generator. A RECOMMENDED method is for each party to provide a nonce of at least 128 bits, used in the derivation of the MSK and EMSK. EAP methods export the MSK and EMSK and not Transient Session Keys so as to allow EAP methods to be ciphersuite and media independent. Keying material exported by EAP methods MUST be independent of the ciphersuite negotiated to protect data. Depending on the lower layer, EAP methods may run before or after ciphersuite negotiation, so that the selected ciphersuite may not be known to the EAP method. By providing keying material usable with any ciphersuite, EAP methods can used with a wide range of ciphersuites and media. It is RECOMMENDED that methods providing integrity protection of EAP packets include coverage of all the EAP header fields, including the Code, Identifier, Length, Type and Type-Data fields. In order to preserve algorithm independence, EAP methods deriving keys SHOULD support (and document) the protected negotiation of the ciphersuite used to protect the EAP conversation between the peer and server. This is distinct from the ciphersuite negotiated between the peer and authenticator, used to protect data. The strength of Transient Session Keys (TSKs) used to protect data is ultimately dependent on the strength of keys generated by the EAP method. If an EAP method cannot produce keying material of sufficient strength, then the TSKs may be subject to brute force attack. In order to enable deployments requiring strong keys, EAP methods supporting key derivation SHOULD be capable of generating an MSK and EMSK, each with an effective key strength of at least 128 bits. Methods supporting key derivation MUST demonstrate cryptographic separation between the MSK and EMSK branches of the EAP key hierarchy. Without violating a fundamental cryptographic assumption (such as the non-invertibility of a one-way function) an attacker recovering the MSK or EMSK MUST NOT be able to recover the other quantity with a level of effort less than brute force. Non-overlapping substrings of the MSK MUST be cryptographically separate from each other, as defined in Section 7.2.1. That is, knowledge of one substring MUST NOT help in recovering some other substring without breaking some hard cryptographic assumption. This is required because some existing ciphersuites form TSKs by simply splitting the AAA-Key to pieces of appropriate length. Likewise, non-overlapping substrings of the EMSK MUST be cryptographically separate from each other, and from substrings of the MSK. The EMSK is reserved for future use and MUST remain on the EAP peer and EAP server where it is derived; it MUST NOT be transported to, or shared with, additional parties, or used to derive any other keys. (This restriction will be relaxed in a future document that specifies how the EMSK can be used.) Since EAP does not provide for explicit key lifetime negotiation, EAP peers, authenticators and authentication servers MUST be prepared for situations in which one or parties discard key state which remains valid on another party. This specification does not provide detailed guidance on how EAP methods derive the MSK and EMSK; how the AAA-Key is derived from the MSK and/or EMSK; or how the TSKs are be derived from the AAA-Key. The development and validation of key derivation algorithms is difficult, and as a result EAP methods SHOULD reuse well established and analyzed mechanisms for key derivation (such as those specified in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones. EAP methods SHOULD also utilize well established and analyzed mechanisms for MSK and EMSK derivation. Further details on EAP Key Derivation are provided within [KEYFRAME]." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Sep 25 15:58:50 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18603 for ; Thu, 25 Sep 2003 15:58:10 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 400935801CF; Thu, 25 Sep 2003 14:58:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 70EF45801C0; Thu, 25 Sep 2003 14:58:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC0065801C2 for ; Thu, 25 Sep 2003 14:57:21 -0500 (CDT) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id AAB0F5801C0 for ; Thu, 25 Sep 2003 14:57:06 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8PJNGs16255 for ; Thu, 25 Sep 2003 12:23:17 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 177: Rewrite of SA sections Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 25 Sep 2003 12:23:16 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 177: Rewrite of SA sections Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 9/25/2003 Reference: Document: Keyframe-07 Comment type: T Priority: S Section: 3.1-3.5 Rationale/Explanation of issue: The SA discussion needs to be revised given recent Key Design team discussions. Change sections 3.1-3.5 to: "3.1 EAP SA An EAP SA exists between the EAP peer and server. It includes: the EAP peer identity the EAP server identity the EAP method type the EAP peer and server nonces the Transient EAP Keys (TEKs) the Master Session Key (MSK) the Extended Master Session Key (EMSK) The EAP SA is not explicitly bound to a particular port on the EAP peer. An EAP peer with multiple ports may create an EAP SA on one port and then choose to use that SA to subsequently create a phase 2 SA on another port. It cannot be assumed that the EAP SA expires after the EAP authentication and key derivation is complete. Some methods may be support "fast resume" by caching EAP SA state on the EAP peer and server. EAP does not support SA lifetime negotiation or an SA "delete" operation, although some EAP methods may support this. Either the EAP peer or EAP server may delete an EAP SA at any time, and methods which allow an EAP SA to persist need to permit the EAP peer and server to recognize when they have gotten out of sync with respect to the EAP SA state. For example, EAP TLS [RFC 2716] supports "fast resume" (TLS session resumption), which assumes that both the EAP peer and server cache EAP master keys (the TLS master secret). An EAP peer attempting a fast resume provides the session-id identifying the session that it wishes to resume. If the EAP server retains the master key corresponding to this session in its cache, then the "fast resume" can proceed; otherwise a full TLS exchange ensues. An EAP peer may negotiate EAP SAs with one or more EAP servers as the result of pre-authentication or AAA load balancing and failover effects. For example, an EAP peer may pre-authenticate to one or more EAP servers, or may be directed to more than one EAP server as the result of an authentication server becoming unreachable. In general, EAP servers cannot be assumed to be synchronized with respect to EAP SA state, particularly since they may not exist within the same administrative domain. Since an EAP SA is typically created prior to secure association, the EAP SA is not bound to a particular target network. 3.2. AAA-Key SA An AAA-Key SA exists between the authenticator and authentication server. It includes: the EAP peer name the NAS/authenticator name the AAA-Key the AAA-Key maximum lifetime (if known) the AAA attributes sent in the Access-Accept The AAA-Key SA is created as the result of the transport of the AAA- Token from the authentication server to the NAS/authenticator. The AAA- Key SA is more specific than the EAP SA in that it is bound to a particular authenticator, as defined by the NAS identification attributes included in the AAA request. For example, within RADIUS the NAS is identified by the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address attributes. Unless the attributes providing explicit scoping are providing, it is assumed that the AAA-Key is usable by the NAS to which it is delivered, without restriction. Since the AAA-Key SA is bound to the NAS identified in the AAA Request, a NAS/authenticator that operates on a shared use network will share the AAA-Key SA between multiple virtual NAS devices. Since these virtual NAS devices might appear to the peer to be different NASes, a mechanism is needed for the EAP peer to differentiate them, so that the peer can determine which devices a AAA-Key can be used with. In the case of IEEE 802.11, it has been proposed that a "Group Identifier" be added to the Beacon and Probe Response messages, containing a MAC address uniquely identifying a particular Access Point. Such a "Group Identifier" could be included in the NAS-Identifier attribute so as to uniquely identify a particular NAS to the AAA server. Since a AAA-Key SA may be shared between virtual NASes, it is possible for an EAP peer to successfully complete a fast handoff between virtual NASes operating on the same physical NAS. Since the virtual NASes may have access to different networks or even exist within different administrative domains, this creates a security problem unless the AAA attributes are applied to the new session. For example, an EAP peer authenticating to a GUEST network could successfully complete a fast handoff to the CORPORATE network. This would be harmless if it only resulted in the peer receiving the GUEST service, without obtaining additional time on the network. Existing RADIUS attributes may not be adequate to this task. For example, today there are no standard attributes usable to indicate: a. Which SSIDs a peer is authorized to attach to. b. The absolute time at which a session is to end (as opposed to the Session-Time attribute which is relative) c. The times of day during which access is allowed d. The Calling-Station-Ids from which a client may access the network e. Whether fast handoff is permitted. Attribute a) is useful so that when a client attempts a fast handoff to the CORPORATE network from the GUEST network, the NAS checking the AAA attributes will discover that the peer is only authorized for GUEST, not CORPORATE. As a result, the fast handoff attempt will fail. Attribute b) can be used to prevent a peer attempting a fast handoff between the GUEST network and another network from obtaining additional session time. Attribute c) can be used to prevent a peer from accessing the network outside of authorized hours. Attribute d) can be used to ensure that a peer is accessing the network only from an administrator-authorized NIC. This might be important in high security installations. Attribute e) might be useful in situations where the administrator desires to limit deployment of fast handoff. In fast handoff, a single EAP SA may be used to establish multiple AAA- Key SAs (see Appendix E for details). Although a AAA-Key SA may not persist longer than the maximum SA lifetime negotiated for an EAP SA (for methods that support such a negotiation), if an EAP SA is deleted by an EAP peer or authenticator, this does not necessarily imply deletion of the child AAA-Key SA. For example, fast handoff keying material provided by an authentication server may continue to be cached by NASes/authenticators after the corresponding EAP SA has been deleted by the authentication server and/or peer. 3.3. Unicast Secure Association SA The unicast secure association SA exists between the EAP peer and authenticator. It includes: the peer port identifier (Calling-Station-Id) the NAS port identifier (Called-Station-Id) the unicast Transient Session Keys (TSKs) the unicast secure association peer nonce the unicast secure association authenticator nonce the negotiated unicast capabilities and unicast ciphersuite. During the phase 2a exchange, the EAP peer and authenticator demonstrate mutual possession of the AAA-Key derived and transported in phase 1; securely negotiate the session capabilities (including unicast ciphersuites), and derive fresh unicast transient session keys. The AAA-Key SA (phase 1b) is therefore used to create the unicast secure association SA (phase 2a), and in the process the phase 2a unicast secure association SA is bound to ports on the EAP peer and authenticator. However in order for a phase 2a security association to be established, it is not necessary for the phase 1a exchange to be rerun each time. This enables the EAP exchange to be bypassed when fast handoff support is desired. Since both peer and authenticator nonces are used in the creation of the unicast secure association SA, the transient session keys (TSKs) are guaranteed to be fresh, even if the AAA-Key is not. As a result one or more unicast secure association SAs (phase 2a) may be derived from a single AAA-Key SA (phase 1b). The phase 2a security associations may utilize the same security parameters (e.g. mode, ciphersuite, etc.) or they may utilize different parameters. A unicast secure association SA (phase 2a) may not persist longer than the maximum lifetime of its parent AAA-Key SA (if known). However, the deletion of a parent EAP or AAA-Key SA does not necessarily imply deletion of the corresponding unicast secure association SA. Similarly, the deletion of a unicast secure association protocol SA does not imply the deletion of the parent AAA-key SA or EAP SA. However, the failure to mutually prove possession of the AAA-Key during the unicast secure association protocol exchange (phase 2a) is grounds for removal of a AAA-Key SA by both parties. An EAP peer may be able to negotiate multiple phase 2a SAs with a single EAP authenticator, or may be able to maintain multiple phase 2a SAs with multiple authenticators, based on a single EAP SA derived in phase 1a. For example, during a re-key of the secure association protocol SA, it is possible for two phase 2a SAs to exist during the period between when the new phase 2a SA parameters (such as the TSKs) are calculated and when they are installed. Except where explicitly specified by the semantics of the unicast secure association protocol, it should not be assumed that the installation of a new phase 2a SA necessarily implies deletion of the old phase 2a SA. On some media (e.g. 802.11) a port on an EAP peer may only establish phase 2a and 2b SAs with a single port of an authenticator within a given Local Area Network (LAN). This implies that the successful negotiation of phase 2a and/or 2b SAs between an EAP peer port and a new authentiator port within a given LAN implies the deletion of existing phase 2a and 2b SAs with authenticators offering access to that Local Area Network (LAN). However, since a given IEEE 820.11 SSID may be comprised of multiple LANs, this does not imply an implicit binding of phase 2a and 2b SAs to an SSID. 3.4. Multicast Secure Association SA The multicast secure association SA includes: the multicast Transient Session Keys the direction vector (for a uni-directional SA) the negotiated multicast capabilities and multicast ciphersuite It is possible for more than one multicast secure association SA to be derived from a single unicast secure association SA. However, a multicast secure association SA is bound to a single EAP SA and a single AAA-Key SA. During a re-key of the multicast secure association protocol SA, it is possible for two phase 2b SAs to exist during the period between when the new phase 2b SA parameters (such as the multicast TSKs) are calculated and when they are installed. Except where explicitly specified by the semantics of the multicast secure association protocol, it should not be assumed that the installation of a new phase 2b SA necessarily implies deletion of the old phase 2b SA. A multicast secure association SA (phase 2b) may not persist longer than the maximum lifetime of its parent AAA-Key or unicast secure association SA. However, the deletion of a parent EAP, AAA-Key or unicast secure association SA does not necessarily imply deletion of the corresponding multicast secure association SA. For example, a unicast secure association SA may be rekeyed without implying a rekey of the multicast secure association SA. Similarly, the deletion of a multicast secure association protocol SA does not imply the deletion of the parent EAP, AAA-Key or unicast secure association SA. However, the failure to mutually prove possession of the AAA-Key during the unicast secure association protocol exchange (phase 2a) is grounds for removal of the AAA-Key, unicast secure association and multicast secure association SAs. 3.5. Key Naming In order to support the correct processing of phase 2 security associations, the secure association (phase 2) protocol supports the naming of phase 2 security associations and associated transient session keys, so that the correct set of transient session keys can be identified for processing a given packet. Explicit creation and deletion operations are also typically supported so that establishment and re-establishment of transient session keys can be synchronized between the parties. In order to securely bind the EAP security association (phase 1) to its child phase 2 security association, the phase 2 secure association protocol allows the EAP peer and authenticator to mutually prove possession of the EAP (phase 1) keying material derived during the EAP exchange (phase 1). In order to avoid confusion in the case where an EAP peer has more than one EAP security association (phase 1) applicable to establishment of a given phase 2 security association, the secure association protocol (phase 2) supports key naming so that the appropriate phase 1 keying material can be utilized by both parties in the secure association protocol exchange. As noted earlier, the discovery phase (phase 0) may be insecure so that in order to prevent spoofing of discovery packets, the secure association (phase 2) protocol should support the secure verification of discovered capabilities, including ciphersuites and other security parameters. This is more scalable than attempting to configure the supported capabilities on each peer and authenticator and more secure than unprotected capabilities negotiation. For example, a peer might be pre-configured with policy indicating the ciphersuite to be used in communicating with a given authenticator. Within PPP, the ciphersuite is negotiated within the Encryption Control Protocol (ECP), after EAP authentication is completed. Within [IEEE80211i], the AP ciphersuites are advertised in the Beacon and Probe Responses, and are securely verified during a 4-way exchange after EAP authentication has completed. As part of the secure association protocol (phase 2), it is necessary to bind the Transient Session Keys (TSKs) to the keying material provided in the AAA-Token. This ensures that the EAP peer and authenticator are both clear about what key to use to provide mutual proof of possession. Keys within the EAP key hierarchy are named as follows: EAP SA name The EAP security association is negotiated between the EAP peer and EAP server, and is uniquely named as follows . Here the EAP peer name and EAP server name are the identifiers securely exchanged within the EAP method. Since multiple EAP SAs may exist between an EAP peer and EAP server, the EAP peer nonce and EAP server nonce allow EAP SAs to be differentiated. The inclusion of the Method Type in the EAP SA name ensures that each EAP method has a distinct EAP SA space. MK Name The EAP Master Key, if supported by an EAP method, is named by the concatenation of the EAP SA name and a method-specific session-id. AAA-Key Name The AAA-Key is named by the concatenation of the EAP SA name, "AAA-Key" and the authenticator name, since the AAA-Key is bound to a particular authenticator. For the purpose of identification, the NAS-Identifier attribute is recommended. In order to ensure that all parties can agree on the NAS name this requires the NAS to advertise its name (typically using a media-specific mechanism, such as the 802.11 Beacon/Probe Response)." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 26 03:34:34 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24104 for ; Fri, 26 Sep 2003 03:34:20 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C41BC5801BB; Fri, 26 Sep 2003 02:34:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0967958010B; Fri, 26 Sep 2003 02:34:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C45A058010B for ; Fri, 26 Sep 2003 02:33:42 -0500 (CDT) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 472EF58000C for ; Fri, 26 Sep 2003 02:33:41 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8Q6xr623456 for ; Thu, 25 Sep 2003 23:59:54 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] ANNOUNCEMENT, TGi Interim Meeting, 14-16 October, Herndon, VA (fwd) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 25 Sep 2003 23:59:53 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) ---------- Forwarded message ---------- Date: Thu, 25 Sep 2003 19:43:18 -0400 From: David Halasz To: stds-802-11@ieee.org, ieee-802-11-tgi@majordomo.rsasecurity.com Subject: Re: [802-11Technical] ANNOUNCEMENT, TGi Interim Meeting, 14-16 October, Herndon, VA The agenda is to address comments received from LB61 and submit a new draft for re-circulation. There is an EAP WG meeting on October 15th. For part of the day on the 15th, there will be a joint discussion, in an effort to keep the two groups synchronized. Oct. 14 - Review results of LB61 - Form sub-groups - Comment resolution Oct. 15 morning - Comment resolution Oct. 15 afternoon - Joint discussion with EAP WG Oct. 16 - Comment resolution - Re-circ. Dave H. At 09:17 AM 9/22/2003, Al Potter wrote: >Folks: > >ICSA Labs is pleased to sponsor an interim meeting of IEEE 802.11 TGi, to be >held in the TruSecure Building (our parent company) in Herndon, VA from 9am >to 5pm on October 14, 15 and 16. The purpose of this meeting will be to >resolve comments from the upcoming recirculation ballot, and to prepare >another draft. > >Details: > >Location: The TruSecure building is at 13650 Dulles Technology Drive, > Herndon, VA. This is literally within sight of > Washington-Dulles > Airport (IAD), and easily accessible from the freeway system > in the area. Directions from Dulles and other airports > are at > >www.trusecure.com/corporate/locations/directions-hq.shtml. The > meeting will be on the 3d floor. > >Lodging: We have reserved a small block of rooms at the Homewood Suites > under the name TruSecure. Contact information for them and > alternatives in the area is below, an "*" indicates the hotel > is in easy walking distance. > > * Homewood Suites Washington Dulles 703-793-1700 > * Embassy Suites Dulles Airport 703-464-0200 > Summerfield Suites Dulles Airport 703-713-6800 > Dulles Hyatt 703-713-1234 > >Meals: As the Homewood and Embassy offer breakfast as part of the > package, we will only be furnishing beverages and a morning > snack. There are restaurants within walking distance, or > in the > hotels. > >Transportation: All of the hotels are a short (<10 minute) cab ride from > Dulles, and as indicated above, the first two are within easy > walking distance to the meeting site. > >Questions: Please direct questions to AL Potter >, but > be aware that I may be inaccessible 29 Sept. through 3 > Oct. If you > have an urgent question in this time period, and Al does not > respond, please readdress you question to Dave Halasz, > the TGi > chair, > > >AL > >-- >+---------------------------------------------------------------------+ >| Al Potter | >| Manager, Network Security Labs | >| ICSA Labs apotter@icsalabs.com | >| www.icsalabs.com PGP Key ID: 0x58c95451 | >+---------------------------------------------------------------------+ > > > > > > > > Dave Halasz Cisco Systems, Inc. 4125 Highlander Parkway Richfield, OH 44286 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Sep 26 03:37:07 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24162 for ; Fri, 26 Sep 2003 03:37:04 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 63D0B5801C2; Fri, 26 Sep 2003 02:37:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 17E8458010C; Fri, 26 Sep 2003 02:37:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BFC2358010C for ; Fri, 26 Sep 2003 02:36:08 -0500 (CDT) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 7A28658010B for ; Fri, 26 Sep 2003 02:36:07 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8Q72Ld23712 for ; Fri, 26 Sep 2003 00:02:21 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] IEEE 802.11i/D6 draft available for inspection Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 26 Sep 2003 00:02:20 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Draft 6 of IEEE 802.11i is now available on the IEEE 802.11 archive. This draft contains material that overlaps with the EAP Key Framework draft, so it is worth a read. http://grouper.ieee.org/groups/802/11/private/Draft_Standards/11i/802.11i-D6.0.doc Username: p8021 password: go_wildcats _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Sep 27 12:58:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06185 for ; Sat, 27 Sep 2003 12:58:02 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C94CD580118; Sat, 27 Sep 2003 11:58:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA3B7580114; Sat, 27 Sep 2003 11:58:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7D77580114 for ; Sat, 27 Sep 2003 11:57:32 -0500 (CDT) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 7E9E7580113 for ; Sat, 27 Sep 2003 11:57:31 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8RGNar16402 for ; Sat, 27 Sep 2003 09:23:36 -0700 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Conclusion of EAP WG Last Call on RFC 2284bis-05 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 27 Sep 2003 09:23:36 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) EAP WG last call has concluded on draft-ietf-eap-rfc2284bis-05.txt. 7 issues were raised. Of these, 1 was rejected and 6 were accepted, 5 of which were editorial. The issues raised and their resolutions are available here: http://www.drizzle.com/~aboba/EAP/eapissues.html A version of the draft with the issue resolutions included is available here prior to showing up on the IETF archive next week: http://www.levkowetz.com/pub/ietf/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-06.b.txt Given the relatively few issues that came up in EAP WG last call, the plan is to post the -06 draft to the IETF archive next week and then request the IESG to consider RFC 2284bis-06 as an IETF Proposed Standard. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Sep 29 10:57:09 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19367 for ; Mon, 29 Sep 2003 10:57:05 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 84E91580012; Mon, 29 Sep 2003 09:57:10 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 31805580016; Mon, 29 Sep 2003 09:57:04 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C9FD4580016 for ; Mon, 29 Sep 2003 09:56:07 -0500 (CDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 756C9580012 for ; Mon, 29 Sep 2003 09:56:06 -0500 (CDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19111; Mon, 29 Sep 2003 10:55:58 -0400 (EDT) Message-Id: <200309291455.KAA19111@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: eap@frascone.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] I-D ACTION:draft-ietf-eap-rfc2284bis-06.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 29 Sep 2003 10:55:57 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk et al. Filename : draft-ietf-eap-rfc2284bis-06.txt Pages : 64 Date : 2003-9-29 This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as PPP or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix B. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.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-eap-rfc2284bis-06.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-eap-rfc2284bis-06.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: <2003-9-29110633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-rfc2284bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-rfc2284bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29110633.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap