From diameter-admin@frascone.com Wed Oct 1 06: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 GAA06056 for ; Wed, 1 Oct 2003 06:02:14 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A040158027A for ; Wed, 1 Oct 2003 05:02:17 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0F25C5801E4 for ; Wed, 1 Oct 2003 05:00:43 -0500 (CDT) Date: Wed, 01 Oct 2003 05:00:42 -0500 Message-ID: <20031001100042.11690.29288.Mailman@wolverine> Subject: frascone.com mailing list memberships reminder From: mailman-owner@wolverine.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 (frascone.com) 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@wolverine. 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 Thu Oct 2 15:17: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 PAA21736 for ; Thu, 2 Oct 2003 15:17:03 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4B647580029; Thu, 2 Oct 2003 14:17:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EDDDF58001E; Thu, 2 Oct 2003 14:17:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4EC9958001E for ; Thu, 2 Oct 2003 14:16:39 -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 2B71058001D for ; Thu, 2 Oct 2003 14:16:37 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h92IgDY09085 for ; Thu, 2 Oct 2003 11:42:13 -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 180: SA Descriptions 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, 2 Oct 2003 11:42:13 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: October 2, 2003 Reference: Document: Keyframe-07 Comment type: T Priority: S Section: 1.3, 1.4, 1.5, 1.6, 1.7 Rationale/Explanation of issue: I've rewritten the following sections to improve clarity: 1.3. Conversation Overview Where EAP key derivation is supported, EAP authentication is typically a component of a four phase exchange: Discovery (phase 0) EAP authentication (phase 1a) Access authorization (phase 1b) Service association (phase 2) In the discovery phase (phase 0), the parties locate each other and exchange some information about the service to be provided. For instance, one of the parties may indicate its willingness to provide a service (and to perform the EAP authenticator role), and the other party requests access to that service (assuming the EAP peer role). Next, the EAP peer and backend authentication server authenticate each other (phase 1a) and derive a shared session key (AAA-Key/MSK). In this phase, the authenticator just forwards EAP packets between the peer and backend authentication server (note that in some cases, the authenticator and backend authentication server can be colocated in the same physical node). This feature of EAP enables deployment of new authentication methods without requiring development of new code on the authenticator. Partially overlapping with this exchange is a second exchange (phase 1b), between the authenticator and the backend authentication server. In this exchange, the authenticator and backend authentication server authenticate each other (using some other mechanism than EAP), and authenticator sends information about the service requested by the peer. When the phase 1a has finished, the backend authentication server sends the authenticator information about whether the service should be provided or not, a key for protecting service communication (AAA-Key/MSK), and optionally more detailed instructions about the service to be provided. After both phases 1a and 1b are complete, the authenticator signals the peer it will allow access to the service (phase 2). Next, the peer and authenticator typically exchange more parameters about the service to be provided (most likely some were already exchanged during phase 0). These parameters also include details of how the subsequent communication between them will be protected and what keys will be used (the keys to be used are either derived from AAA-Key or authenticated using it, ensuring that an attacker not knowing AAA-Key cannot have these keys). During this phase, some or all of the parameters exchanged can also be protected using the AAA-Key (typically, at least the keys and selected ciphersuites are protected). The phases and the relationship between the parties is illustrated below. EAP peer Authenticator Auth. Server -------- ------------- ------------ <----------------------------> Discovery (phase 0) <------------------------------------------------------> EAP authentication (phase 1a) <-------------------------> Access authorization (phase 1b) <----------------------------> Service assocation (phase 2) 1.4 A concrete example: WPA (Details to be added; this is just a sketch) o Phase 0: Beacon, Association Request, Association Response. The client and access point already know what EAP roles they will use. The service parameters exchanged in phase 0 include the SSID, data rates, supported ciphersuites, hop patterns (and other PHY parameters). The AP initiates phase 1a by sending an EAP Identity Request, encapsulated inside EAPOL (though in some cases, the AP requests the backend authentication server to send this). o In phase 1a, the client and backend authentication server authenticate each other. For instance, if EAP-TLS is used, they both exchange certificates, verify that the certificates are valid and belong to the expected party, and prove that they know the corresponding private keys. This exchange also generates a shared key between them. o Phase 1b typically uses RADIUS. The packets are authenticated either with RADIUS's own shared secret method (Message-Authenticator), or IPsec. The access point sends e.g.its own identity and various service parameters (e.g. MAC addresses). When phase 1a has finished, the backend authentication server gives permission for the service (Access-Accept), and sends e.g. AAA-Key and Session-Timeout. o Phase 2: four-way handshake and multicast key handshake. Protects some service parameters (MAC addresses, RSN IE, selected ciphersuite) and negotiates keys. After phase 2, the parties protect the .11i frames with e.g. TKIP or CCMP (basically, encryption and MAC using the keys negotiated in phase 2, and sequence numbers for replay protection) 1.5 Second example: IKEv2 "Road warrior VPN gateway with IKEv2, authenticated only using EAP" (Details to be added; this is just a sketch) o Phase 0: Client is maybe configured with gateway's IP address. The parties exchange Diffie-Hellman parameters, nonces, selects IKEv2 ciphersuite. o Phase 1a: similar as above. o Phase 1b: Has not been specified yet, but presumably RADIUS could be used in similar fashion as with WPA. o Phase 2: Authenticates the Diffie-Hellman parameters and nonces (exchanged in phase 0). This implicitly authenticates other parameters exchanged and the rest of the conversation: this involves negotiating what IP traffic will be protected with what ciphers, and so on. Also can involve assigning a new IP address to the client. After this, the traffic is typically protected with ESP. 1.6 Third example: PPP with MPPE To be written. 1.7 Limitations At this point, it is worthwhile to point out two important limitations. The first one applies to typical phase 2 protocols, while the second one is more a fundamental limitation of the current approach. o Typically, phase 2 does not protect all parameters about the service. For instance, MPPE [RFC3078] does not protect the selected ciphersuite, potentially allowing a "downgrade attack" in which an attacker causes a weaker ciphersuite to be selected than would have been otherwise. To take a second example, 802.11i does not protect the SSID, so the peer (STA) and authenticator (AP) can have a different idea about what service is being provided. o Currently, phases 1a and 1b are (almost) independent of each other. This means that the backend authentication server cannot restrict the service parameters used by the authenticator. A malicious or compromised authenticator (that is trusted by the backend authentication server) can present any set of service parameters it wants to the peer. The parameters can be protected at phase 2, but at this point they are protected using a key known to the authenticator. For instance, if using IKEv2 authenticated solely using EAP, the IKEv2 gateway can claim to offer WLAN service, or a WLAN access point can claim to offer IKEv2 service. To give an another example, a WLAN access point offering service for SSID "Joe's Hotspot" can claim to offer service for "Harry's Hotspot". It should be pointed out that leaving the service parameters to the authenticator actually makes sense in many situations. For instance, in WLANs the authenticator (AP) knows best what data rates, hop patterns or ciphersuite sit supports. ---------------------------------------------------------------- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 2 15:54: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 PAA23069 for ; Thu, 2 Oct 2003 15:54:02 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A96B580109; Thu, 2 Oct 2003 14:54:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AB4C0580023; Thu, 2 Oct 2003 14:54:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 07F47580023 for ; Thu, 2 Oct 2003 14:53:44 -0500 (CDT) Received: from alageremail2.agere.com (alageremail2.agere.com [192.19.192.110]) by mail.frascone.com (Postfix) with ESMTP id B61CD58001E for ; Thu, 2 Oct 2003 14:53:42 -0500 (CDT) Received: from alerelay.agere.com (alerelay.agere.com [135.14.190.33]) by alageremail2.agere.com (8.11.7+Sun/8.10.2) with ESMTP id h92JrfJ18285; Thu, 2 Oct 2003 15:53:41 -0400 (EDT) Received: from palex2kh01.ags.agere.com (palex2kh01.agere.com [128.94.210.100]) by alerelay.agere.com (8.11.6+Sun/8.11.6) with ESMTP id h92Jrfa17394; Thu, 2 Oct 2003 15:53:41 -0400 (EDT) Received: from PAUEX2KF01.ags.agere.com ([135.14.186.42]) by palex2kh01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Oct 2003 15:53:39 -0400 Received: from agere.com ([135.149.86.132]) by PAUEX2KF01.ags.agere.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Oct 2003 15:53:39 -0400 Message-ID: <3F7C823F.3010205@agere.com> From: Dorothy Stanley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 180: SA Descriptions References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Oct 2003 19:53:39.0367 (UTC) FILETIME=[DFD2E370:01C3891E] 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, 02 Oct 2003 14:53:35 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Bernard, A very useful description. Comments below. Thanks, Dorothy >1.4 A concrete example: WPA > > > 1. The WPA/.11i naming in the example should probably be consistent, pick one or the other. Or mention that both use the approach described. > > After phase 2, the parties protect the .11i frames with > e.g. TKIP or CCMP (basically, encryption and MAC using the > keys negotiated in phase 2, and sequence numbers for replay > protection) > > 2. " .11i frames" Change ".11i frames" to "IEEE 802.11 data frames". Today management frames are not protected, though some might be in the future. Or, generalize with "IEEE 802.11 frames" . > >To take a second example, 802.11i does not > protect the SSID, so the peer (STA) and authenticator (AP) > can have a different idea about what service is being > provided. > 3.Pre-ceed "802.11" with IEEE. > > > > > >---------------------------------------------------------------- >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap > > -- ---------------- Dorothy Stanley Agere Systems 2000 North Naperville Rd. Naperville, IL 60566 630-979-1572 (Phone, Fax) 630-222-6753 (Cell) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 3 04:22: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 EAA26993 for ; Fri, 3 Oct 2003 04:22:03 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8DFD658001E; Fri, 3 Oct 2003 03:22:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80B31580018; Fri, 3 Oct 2003 03:22:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AD5C4580018 for ; Fri, 3 Oct 2003 03:21:39 -0500 (CDT) Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251]) by mail.frascone.com (Postfix) with ESMTP id 51EED580016 for ; Fri, 3 Oct 2003 03:21:38 -0500 (CDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Oct 2003 09:21:36 +0100 Message-ID: From: "McCann, Stephen" To: "'Dorothy Stanley'" , Bernard Aboba Cc: eap@frascone.com Subject: RE: [eap] Issue 180: SA Descriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: Fri, 3 Oct 2003 09:21:41 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Dorothy, Bernard, Indeed, perhaps the use of WPA within the description should be avoided, as I understand it to be a WiFi Alliance TM. I also agree with Dorothy, in that this is a very informative description and very welcome to people (like myself) who are sometimes 'on the edge' of these detailed discussions. Thanks. Kind regards Stephen > -----Original Message----- > From: Dorothy Stanley [mailto:dstanley@agere.com] > Sent: Thursday, October 02, 2003 8:54 PM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] Issue 180: SA Descriptions > > > Hi Bernard, > > A very useful description. > Comments below. > > Thanks, > > Dorothy > > >1.4 A concrete example: WPA > > > > > > > 1. The WPA/.11i naming in the example should probably be consistent, > pick one or the other. Or mention that both > use the approach described. > > > > > After phase 2, the parties protect the .11i frames with > > e.g. TKIP or CCMP (basically, encryption and MAC using the > > keys negotiated in phase 2, and sequence numbers for replay > > protection) > > > > > 2. " .11i frames" > Change ".11i frames" to "IEEE 802.11 data frames". Today > management frames are not protected, though some might be in > the future. Or, > generalize with > "IEEE 802.11 frames" . > > > > >To take a second example, 802.11i does not > > protect the SSID, so the peer (STA) and authenticator (AP) > > can have a different idea about what service is being > > provided. > > > 3.Pre-ceed "802.11" with IEEE. > > > ---------------- > Dorothy Stanley > Agere Systems > 2000 North Naperville Rd. > Naperville, IL 60566 > 630-979-1572 (Phone, Fax) > 630-222-6753 (Cell) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 3 08:08: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 IAA03430 for ; Fri, 3 Oct 2003 08:07:17 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9619958001E; Fri, 3 Oct 2003 07:07:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3093C580018; Fri, 3 Oct 2003 07:07:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3628A580018 for ; Fri, 3 Oct 2003 07:06:15 -0500 (CDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 77CC9580013 for ; Fri, 3 Oct 2003 07:06:13 -0500 (CDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 37C266A907; Fri, 3 Oct 2003 15:06:11 +0300 (EEST) Message-ID: <3F7D6550.4000905@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 177: Rewrite of SA sections References: In-Reply-To: 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: Fri, 03 Oct 2003 15:02:24 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard, The text that you provided looks very good (thanks!) but I still do have some question marks. Inline: > "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. Hmm... what do you mean in a concrete sense, the SSID? But wouldn't this be a problem, since typically (at least in RADIUS) the auth and authz happen in the same messages. If we decide the "particular target network" or the SSID after this (using Pasi's terms, after phase 1b), it appears to be too late to decide where the user is allowed to go. Or perhaps you mean that the EAP SA is not bound to the particular AP (or its BSSID or group id)? > 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- As discussed elsewhere, AAA in the name is somewhat confusing and "SA" is also a bit confusing given that one of the parties will immediately forget what it sent as the SA. Is this more like a ticket? > 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. Agreed, but I think we should also state the following: "Current AAA servers make authorization decisions both by sending attributes as well as making a dynamic decision. If fast handoff mechanisms do not involve a new AAA exchange for checking the authorization again, all dynamic decision criteria from the AAA server need to be communicated via attributes. Even this approach has limitations, as it can not be used to implement state-based decisions, such as limiting the number of concurrent sessions to 1 per user." > 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. Good list. Are we taking care of this in RADIUSEXT? > 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. Yes -- I like the idea of being able to turn off a feature which has a complicated security design without a lot of mileage behind it yet... > 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. Hmmm... if the SAs are for multicast, they need to be bound to more than one EAP SA at least on the other end, right? Otherwise they could not be used for communicating to more than one entity. But I may miss something, I haven't studied the 11i multicast SAs, for instance. > 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 server name, EAP Method Type, EAP peer nonce, EAP server nonce>. > 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 > > --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 3 08:15: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 IAA03734 for ; Fri, 3 Oct 2003 08:15:02 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BBF1B58010E; Fri, 3 Oct 2003 07:15:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B9E9B58001E; Fri, 3 Oct 2003 07:15:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1EBF358001E for ; Fri, 3 Oct 2003 07:14:29 -0500 (CDT) Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by mail.frascone.com (Postfix) with ESMTP id 5D27458001D for ; Fri, 3 Oct 2003 07:14:27 -0500 (CDT) Received: by fw1.gdm.de (8.11.6p2G/8.11.6) id h93CEPQ25304 for eap@frascone.com; Fri, 3 Oct 2003 14:14:25 +0200 (CEST) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Fri Oct 3 14:14:25 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.10.2003 14:11:34 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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: Fri, 3 Oct 2003 14:12:12 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Ich werde ab 02.10.2003 nicht im B=FCro sein. Ich kehre zur=FCck am 13.10.2003. I am away from my email. I will respond to your message when back on October 13th.= _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 3 10:36: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 KAA09975 for ; Fri, 3 Oct 2003 10:36:05 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5DB1058010A; Fri, 3 Oct 2003 09:36:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 461D5580018; Fri, 3 Oct 2003 09:36:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1CB80580018 for ; Fri, 3 Oct 2003 09:35:31 -0500 (CDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id E00A0580016 for ; Fri, 3 Oct 2003 09:35:29 -0500 (CDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 265506A902; Fri, 3 Oct 2003 17:35:29 +0300 (EEST) Message-ID: <3F7D884E.7000401@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" , Hannes Tschofenig Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] (fwd) issue 178: keying review by Hannes 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, 03 Oct 2003 17:31:42 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hannes has reviewed the keying framework document. You can see his comments from : http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=http://www.levkowetz.com/ietf/drafts/eap/keying/review_hannes-aboba-pppext-key-problem-07.txt&comments=hannes: Thanks Hannes for the review, its very helpful! Here are some comments to your comments: - The target audience of the document is what you listed, but an important additional audience is security reviewers (e.g. ADs) who would like to ensure that the whole system comprised of EAP, methods, 1X, fast handoffs and whatnot is reasonably secure. - I agree that the document should not be 802.11i/1X specific. These can be used in examples, however, and as such I'd still keep the examples in the body of the document and not in an appendix. But the examples should be short and if more material is needed for 11i/1X then it should be in an appendix. - I agree that the requirements should come before the solution. - Agree about your terminology comments. - Agree about your unilateral auth comment. Suggested clarified text: "Depending on the used method, EAP provides either one-way authentication (in which the peer authenticates to the EAP server), or mutual authentication (in which the peer and EAP server mutually authenticate). A mutually authenticating method is required where keying based on EAP is needed." - Agree that treatment of fast handoff issues probably deserves its own section. - In Sect. 3.2, I agree binding to a port is too application specific (and vague). Bound to the used Calling/Called-Station-Ids? - In the text 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. you said: this sounds like a possibility for a denial of service attack. I would agree, though it is probably easy to deal with by not removing the SAs immediately after getting a bad message, but after a timeout. - Agree with your proposed key naming term definition. - Do not agree with all editorial comments on removing extra explanations; this is a complex issue and we have to give examples, and explain some of the environment where EAP operates (e.g. discovery phase). - Diameter CMS can't be used as an alternative to redirects, as that work has been dropped by the IETF. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 3 10:37:42 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 KAA10023 for ; Fri, 3 Oct 2003 10:37:36 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 51F3B580023; Fri, 3 Oct 2003 09:36:23 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CFDEC580016; Fri, 3 Oct 2003 09:36:06 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7EBB580018 for ; Fri, 3 Oct 2003 09:35:48 -0500 (CDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 55D21580016 for ; Fri, 3 Oct 2003 09:35:47 -0500 (CDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3CB6E6A902 for ; Fri, 3 Oct 2003 17:35:45 +0300 (EEST) Message-ID: <3F7D885E.1000500@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 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] keying framework reviews 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, 03 Oct 2003 17:31:58 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hello, We intend to make a new version of the keying framework document at the end of next week, in preparation for the upcoming meeting. So, now would be a perfect time for everyone to send in their problems with the document, or start a review if you have not yet reviewed it. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 3 15:19: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 PAA22461 for ; Fri, 3 Oct 2003 15:19:03 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A128C58001E; Fri, 3 Oct 2003 14:19:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C8E9E580016; Fri, 3 Oct 2003 14:19:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DDFB0580016 for ; Fri, 3 Oct 2003 14:18:36 -0500 (CDT) 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 7B7F7580013 for ; Fri, 3 Oct 2003 14:18:34 -0500 (CDT) Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 03 Oct 2003 12:24:41 -0700 Received: from dhala-w2k01.cisco.com (dhcp-64-101-220-196.cisco.com [64.101.220.196]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h93JIT5h020347; Fri, 3 Oct 2003 15:18:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20031003151430.031b12f0@unitas.cisco.com> X-Sender: dhala@unitas.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: stds-802-11@ieee.org, ieee-802-11-tgi@majordomo.rsasecurity.com From: David Halasz Cc: aboba@internaut.com, jari.arkko@piuha.net, eap@frascone.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Fwd: Re: [802-11Technical] ANNOUNCEMENT, TGi Interim Meeting, 14-16 October, 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: Fri, 03 Oct 2003 15:18:29 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) A reminder about the Herndon meeting on October 14-16. Also, for planning purposes, if you plan on attending, please send an email too: dhala@cisco.com, apotter@icsalabs.com Dave H. >Date: Thu, 25 Sep 2003 19:43:18 -0400 >To: stds-802-11@ieee.org, ieee-802-11-tgi@majordomo.rsasecurity.com >From: David Halasz >Subject: Re: [802-11Technical] ANNOUNCEMENT, TGi Interim Meeting, 14-16 >October, Herndon, VA >Cc: aboba@internaut.com, jari.arkko@piuha.net > >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 Tue Oct 7 21:00:45 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 VAA00038 for ; Tue, 7 Oct 2003 21:00:14 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 574C9580027; Tue, 7 Oct 2003 20:00:13 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D5F9580029; Tue, 7 Oct 2003 20:00:05 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4280D580027 for ; Tue, 7 Oct 2003 19:59:56 -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 1D91B580012 for ; Tue, 7 Oct 2003 19:59:54 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h980P1S26593 for ; Tue, 7 Oct 2003 17:25:01 -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 169: Review of KEYFRAME-07 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, 7 Oct 2003 17:25:01 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 169 is enclosed below. The proposed fixes are as follows: The proposed fixes are as follows: In Section 1.2, change: "In other words, if the keys are cryptographically separate, there is no shortcut to compute x from y or y from x, but the work an adversary must do to perform this computation is equivalent to performing exhaustive search for the secret state value." To: "In other words, if the keys are cryptographically separate, there is no shortcut to compute x from y or y from x." In Section 1.3, change: "While EAP methods may be based on key management protocols, EAP itself is not a key management protocol. Thus, while EAP may provide for mutual authentication and derivation of keying material, it does not provide for the derivation or naming of transient session keys, the selection of traffic modes such as transport or tunnel mode, the secure negotiation of capabilities such as ciphersuites or filters, or support for key activation. As a result, where EAP is used for key derivation, a secure association protocol (phase 2) should be provided, supporting the creation and deletion of unicast (phase 2a) and multicast (phase 2b) security associations used for the protection of data." To: "While EAP methods may mutually authenticate and derive keys, EAP does not provide for the derivation or naming of transient session keys, the selection of traffic modes such as transport or tunnel mode, the secure negotiation of capabilities such as ciphersuites or filters, or support for key activation. As a result, where EAP is used for key derivation, a secure association protocol (phase 2) should be provided, supporting the creation and deletion of unicast (phase 2a) and multicast (phase 2b) security associations used for the protection of data." In Section 1.3.3, change: "[4] Mutual proof of possession of the keying material generated during EAP authentication (phase 1). By requiring a mutual proof of possession of the AAA-Key, the secure association protocol demonstrates that both the EAP peer and authenticator have been authenticated and authorized by the AAA server. Note that mutual proof of possession is not the same thing as mutual authentication. For example, as a result of a secure association protocol exchange, the EAP peer may not be able to confirm the identity of the authenticator." To: "[4] Mutual proof of possession of the AAA-Key. This demonstrates that both the EAP peer and authenticator have been authenticated and authorized by the AAA server. Since mutual proof of possession is not the same as mutual authentication, the EAP peer cannot verify authenticator assertions (including the authenticator identity) as a result of this exchange." In Section 2.2, change: "Initialization Vector (IV) A quantity of at least 64 octets, suitable for use in an initialization vector field, that is derived between the EAP client and server. Since the IV is a known value in methods such as EAP- TLS [RFC2716] it cannot be used in computation of any quantity that needs to remain secret, and is not used with any known ciphersuite. As a result, its use has been deprecated and EAP methods are not required to generate it." To: "Initialization Vector (IV) A quantity of at least 64 octets, suitable for use in an initialization vector field, that is derived between the EAP client and server. Since the IV is a known value in methods such as EAP- TLS [RFC2716] it cannot be used by itself for computation of any quantity that needs to remain secret. As a result, its use has been deprecated and EAP methods are not required to generate it." In Section 3.3, change: "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." To: "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. Failure to mutually prove possession of the AAA-Key during the unicast secure association protocol exchange (phase 2a) need not be grounds for removal of a AAA-Key SA by both parties; rate-limiting unicast secure association exchanges should suffice to prevent a brute force attack." In Section 3.3, change: "820.11" to "802.11" In Section 3.4, change: "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." To: "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. Failure to mutually prove possession of the AAA-Key during the unicast secure association protocol exchange (phase 2a) need not be grounds for removal of the AAA-Key, unicast secure association and multicast secure association SAs; rate-limiting unicast secure association exchanges should suffice to prevent a brute force attack." In Section 3.5, change: "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." To: "In order to securely bind the AAA-Key security association (phase 1b) to its child phase 2 security associations, the phase 2 secure association protocol allows the EAP peer and authenticator to mutually prove possession of the AAA-Key. In order to avoid confusion in the case where an EAP peer has more than one AAA-Key (phase 1b) applicable to establishment of a phase 2 security association, it is necessary for the secure association protocol (phase 2) to support key selection, so that the appropriate phase 1b keying material can be utilized by both parties in the secure association protocol exchange." In Section 6.2, change: "Where an untrusted AAA intermediary is present (such as a RADIUS proxy or a Diameter agent), and data object security is not used, the MSK may be recovered by an attacker in control of the untrusted intermediary. Possession of the MSK enables decryption of data traffic sent between the peer and a specific authenticator; however where Perfect Forward Secrecy (PFS) is implemented, compromise of the MSK does enable an attacker to impersonate the peer to another authenticator, since that requires possession of the MK or EMSK, which are not transported by the AAA protocol. This vulnerability may be mitigated by implementation of redirect functionality, as provided in [DiamBASE]." To: "Where an untrusted AAA intermediary is present (such as a RADIUS proxy or a Diameter agent), and data object security is not used, the AAA-Key may be recovered by an attacker in control of the untrusted intermediary. Possession of the AAA-Key enables decryption of data traffic sent between the peer and a specific authenticator; however where key separation is implemented, compromise of the AAA-Key does not enable an attacker to impersonate the peer to another authenticator, since that requires possession of the MK or EMSK, which are not transported by the AAA protocol. This vulnerability may be mitigated by implementation of redirect functionality, as provided in [DiamBASE]." In Section 6.3, change: "In order to prevent these attacks, [MiTM] recommends derivation of a compound key by which the EAP peer and authenticator can prove that they have participated in the entire EAP exchange." To: "In order to prevent these attacks, [MiTM] recommends derivation of a compound key by which the EAP peer and server can prove that they have participated in the entire EAP exchange." Add Section 6.5: "6.5 Denial of Service Attacks The caching of security associations may result in vulnerability to denial of service attacks. Since an EAP peer may derive multiple EAP SAs with a given EAP server, and creation of a new EAP SA does not implicitly delete a previous EAP SA, EAP methods that result in creation of persistant state may be vulnerable to denial of service attacks by a rogue EAP peer. As a result, EAP methods creating persistent state may wish to limit the number of cached EAP SAs (Phase 1a) corresponding to an EAP peer. For example, an EAP server may choose to only retain a few EAP SAs for each peer. This prevents a rogue peer from denying access to other peers. Similarly, an authenticator may have multiple AAA-Key SAs corresponding to a given EAP peer; to conserve resources an authenticator may choose to limit the number of cached AAA-Key (Phase 1 b) SAs for each peer. Depending on the media, creation of a new unicast secure association SA may or may not imply deletion of a previous unicast secure association SA. Where there is no implied deletion, the authenticator may choose to limit Phase 2 (unicast and multicast) secure association SAs for each peer." ----------------------------------------------------------------- Issue 169: Review of Key Framework-07 Submitter name: Dan Simon Submitter email address: dansimon@microsoft.com Date first submitted: 8/24/2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-August/001615.html Document: Key-07 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: p. 7, 1st para.: "exhaustive search" is not the best terminology, since some algorithms (notably number-theoretic ones) are attackable by means other than brute force. "Breaking a cryptographic assumption", which you use earlier in the paragraph, is a better phrasing. p. 8, last para.: "Key management" is often used as a synonym for "key distribution", so the question of whether EAP itself is a key management protocol should be thought of primarily in terms of whether it's EAP or individual EAP methods that handle key distribution (i.e., key exchange). I'll leave it to you to decide which way you like to think of it. p. 13, first para.: the IV must not be used by itself in computation of any quantity that needs to remain secret. Obviously, it can be used in combination with secret keys to derive other secret keys. p. 21, 1st para.: removing an SA based on a (single) failed authentication suggests an easy targeted DoS attack (although, granted, a strictly local one, and hence not that much of a concern). In any event, rate-limiting authentication attempts should suffice, especially when strong keys are being used. p. 21, 3rd para.: You mean 802.11, not 820.11, right? p. 22, 4th para.: See comment on p. 21, 1st para., above. p. 24, last para.: I don't think you mean "perfect forward secrecy" here so much as "key separation". None of the keys are being "rolled forward" over time; rather, the MSK is being kept cryptographically separated from the keys needed to impersonate the backend server or peer. p. 25, 2nd last para.: "between the peer and server", not "between the peer and authenticator". (Right?) p. 29, "Cryptographic separation": see first comment, on p. 7, above. p. 30, "Key Strength" and "Freshness": I have no fundamental objection to the 128-bit requirement, but I also would have no objection if it were weakened somewhat (e.g., to 96 bits), and I wouldn't want to see an otherwise reasonable future EAP method proposal get shot down over key-length paranoia. On the other hand, if you're confident that this won't be a problem (i.e., that nobody will ever have trouble meeting the 128-bit requirement within their method), I'll accept your judgment. General: I was wondering if it might be a good idea to have a "DoS attack" section in the security considerations section, spelling out what makes a DoS attack worthy or unworthy of concern. One thought that came to mind as I was reading the doc, for instance: you mention a peer having multiple SAs with the same authenticator--might that allow a client to start establishing SAs with the authenticator (e.g., an AP) until the latter "blows up" or maxes out, then move on to the next authenticator and do the same? Again, if it only disables the authenticator while the client is around, then the attack could be dismissed as "microwave-oven-equivalent"--but could the request for multiple SAs conceivably cause the authenticator to freeze up for a longer period while it holds huge amounts of SA state for the single client, waiting for it to return? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 7 22:06:54 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 WAA01521 for ; Tue, 7 Oct 2003 22:06:14 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D9C12580012; Tue, 7 Oct 2003 21:06:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 16983580109; Tue, 7 Oct 2003 21:06:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6BEE2580109 for ; Tue, 7 Oct 2003 21:05:20 -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 51759580012 for ; Tue, 7 Oct 2003 21:05:18 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h981UPV30495 for ; Tue, 7 Oct 2003 18:30:25 -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 178: Review of Key Framework 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, 7 Oct 2003 18:30:25 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The proposed text of Issue 178 is enclosed below. The required fixes are extensive, and multiple reviewers have commented on some sections, so I think we will need to address the issues in several passes. Here is a first pass at some fixes: In Section 1, change: "Since in EAP keying material is generated by EAP methods, transported by AAA protocols, transformed into session keys by secure association protocols and used by link layer ciphersuites, it is" To: "Since in EAP keying material is generated by EAP methods, transported by AAA protocols, transformed into session keys by secure association protocols and used by lower layer ciphersuites, it is" In Section 1, delete: "The document is organized as follows: Section 1 provides an introduction and defines terminology. Section 2 describes the EAP key hierarchy and exchanges. Section 3 describes EAP security associations and key naming. Section 4 describes the threat model and security requirements. Section 5 describes the IANA considerations. Section 6 describes security considerations. Section 7 provides references. Appendix A summarizes the keying requirements for link layer ciphersuites. Appendix B provides an example transient EAP key (TEK) hierarchy. Appendix C provides an example MSK and EMSK hierarchy. Appendix D provides an example Transient Session Key (TSK) derivation. Appendix E describes AAA-Key derivation, including fast handoff." In Section 1.2, delete: "For example, attributes might include the peer layer 2 address (Calling-Station-Id), the authenticator layer 2 address (Called-Station-Id) and IP address (NAS-IP-Address), the key name, etc." In Section 1.2, change: "The format and wrapping of the AAA-Token, which is intended to be accessible only to the backend authentication server and authenticator, is defined by the AAA protocol." To: "The format and wrapping of the AAA-Token, which is intended to be accessible only to the backend authentication server and authenticator, is defined by the AAA protocol. Examples include RADIUS [RFC2548], and Diameter [DiamEAP]." In Section 1.2, delete: "Key derivation This refers to the ability of the EAP method to export a ciphersuite-independent Master Session Key (MSK), Extended Master Session Key (EMSK), and (optionally) an Initialization Vector (IV)." In Section 1.2, add: "AAA-Key A key derived by the EAP peer and EAP server and transported to the authenticator. In 802.11 terminology, the first 32 octets of the AAA-Key is known as the Pairwise Master Key (PMK)." In Section 1.3, change: "Once the EAP peer and authenticator discover each other, they authenticate using EAP (phase 1a)." To: "Once the EAP peer and authenticator discover each other, EAP authentication may begin (phase 1a)." In Section 1.3, delete: "In 802.11 terminology, the first 32 octets of the AAA-Key is known as the Pairwise Master Key (PMK)." In Section 1.3, change: " <-------------------------------- AAA-Key transport (phase 1b)" to: " <-------------------------------- AAA-Key transport (optional; phase 1b)" In Section 1.3, change: " <-----------------------------> Multicast Secure association (phase 2b)" To: " <-----------------------------> Multicast Secure association (optional; phase 2b)" In Section 1.3.2, change: "Once the EAP peer and authenticator discover each other, they authenticate using EAP (phase 1a)." To: "Once the EAP peer and authenticator discover each other, they exchange EAP packets." In Section 1.3.2, change: "EAP supports either one-way authentication (in which the peer authenticates to the EAP server), or mutual authentication (in which the peer and EAP server mutually authenticate)." To: "Some EAP methods exist which only support one-way authentication; however, EAP methods deriving keys are required to support mutual authentication." In Section 1.3.3, delete: "While EAP methods may be based on key management protocols, EAP itself is not a protocol for negotiation of security associations. While EAP methods supporting key derivation provide for mutual authentication and creation of EAP (phase 1) security associations, in order to preserve media independence, they typically do not support generation of transient session keys or negotiation of ciphersuites used in the protection of data. As a result, where EAP is used for key derivation, a secure association protocol (phase 2) should be provided, supporting the creation and deletion of phase 2 security associations used for the protection of data." In Section 1.3.3, change: " [2] Generation of fresh transient session keys. This is typically accomplished via the exchange of nonces within the secure association protocol, and includes generation of both unicast (phase 2a) and multicast (phase 2b) session keys. While multicast traffic may only pass in one direction in certain cases (such as in IEEE 802.11 infrastructure mode, where only the Access Point sends multicast traffic), in other cases (such as IEEE 802.11 adhoc mode), both endpoints may send multicast traffic. By not using the AAA-Key directly to protect data, the secure association protocol protects against compromise of the AAA-Key, and by guaranteeing the freshness of transient session key, assures that session keys are not reused." to: " [2] Generation of fresh transient session keys. This is typically accomplished via the exchange of nonces within the secure association protocol, and includes generation of both unicast (phase 2a) and multicast (phase 2b) session keys. By not using the AAA-Key directly to protect data, the secure association protocol protects against compromise of the AAA-Key, and by guaranteeing the freshness of transient session key, assures that session keys are not reused." In Section 2.1.1 add to the end: "As a result, EAP methods should not utilize identifiers associated with a particular usage environment (e.g. MAC addresses)." In Section 2.1.3, change: "Ciphersuite negotiation In practice, an EAP method may not have knowledge of the ciphersuite that has been negotiated between the peer and authenticator." To: "Knowledge of capabilities In practice, an EAP method may not have knowledge of the ciphersuite that has been negotiated between the peer and authenticator." In Section 2.2, change: "EAP Master key (MK) A key derived between the EAP client and server during the EAP authentication process, and that is kept local to the EAP method and not exported or made available to a third party. Since the MK is a residue of a successful EAP authentication exchange, it is possible to shorten future EAP exchanges between an EAP peer and server by providing proof of MK possesion, a technique known as "fast resume". Master Session Key (MSK) Keying material (at least 64 octets) that is derived between the EAP client and server and exported by the EAP method. Whenever a full EAP authentication is performed (not fast handoff), the MSK is chosen as the AAA-Key (see Appendix E for details)." To: "EAP Master key (MK) A key derived between the EAP client and server during the EAP authentication process, and that is kept local to the EAP method and not exported or made available to a third party." Master Session Key (MSK) Keying material (at least 64 octets) that is derived between the EAP client and server and exported by the EAP method." In Section 2.2, change: "Extended Master Session Key (EMSK) Additional keying material (64 octets) derived between the EAP client and server that is exported by the EAP method. Unlike the MSK which is transported from the authentication server to the authenticator, the EMSK is known only to the EAP peer and server and is not provided to a third party. The EMSK therefore is not transported by the backend authentication server to the authenticator, although quantities derived from it may be used as the AAA-Key in situations in which EAP authentication is bypassed (e.g. fast handoff). Currently 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, man-in-the-middle vulnerability protection, etc." to: "Extended Master Session Key (EMSK) Additional keying material (64 octets) derived between the EAP client and server that is exported by the EAP method. The EMSK is known only to the EAP peer and server and is not provided to a third party." In Section 3.5, delete: "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." Move the contents of Section 2.4 to the beginning of Section 4.1. In Section 4.1, delete: "If the authenticator and backend authentication server do not mutually authenticate, then the peer will be vulnerable to rogue backend authentication servers, authenticators, or both. If there is no per- packet authentication, integrity and replay protection between the authenticator and backend authentication server, then an attacker can spoof or modify packets in transit." In Section 4.2.2, change: "Session Keys AAA protocols used for transport of EAP keying material MUST implement and SHOULD use session keys, as in Diameter EAP [DiamEAP] and RADIUS over IPsec [RFC3579], rather than using a static key, as originally defined in RADIUS [RFC2865]." To: "Session Keys AAA protocols used for transport of EAP keying material MUST implement and SHOULD use dynamic key management in order to derive fresh session keys, as in Diameter EAP [DiamEAP] and RADIUS over IPsec [RFC3579], rather than using a static key, as originally defined in RADIUS [RFC2865]." In Section 4.2.2, change: "Forgery protection AAA protocols used for transport of EAP keying material SHOULD provide protection against rogue authenticators masquerading as other authenticators." To: "Authorization AAA protocols used for transport of EAP keying material SHOULD provide protection against rogue authenticators masquerading as other authenticators." In Section 7.1, change: "[RFC2284bis] Blunk, L., et al. "Extensible Authentication Protocol (EAP)", Internet draft (work in progress), draft-ietf- eap-rfc2284bis-04.txt, June 2003." To: "[RFC2284bis] Blunk, L., et al. "Extensible Authentication Protocol (EAP)", Internet draft (work in progress), draft-ietf- eap-rfc2284bis-06.txt, October 2003." In Section 7.2, delete: "[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998." (already listed in Section 7.1) In Section 7.2, change: "[DiamBASE] Calhoun, P., et al., "Diameter Base Protocol", Internet draft (work in progress), draft-ietf-aaa-diameter-17.txt, December 2002." To: "[DiamBASE] Calhoun, P., et al., "Diameter Base Protocol", RFC 3588, September 2003." In Section 7.2, change: "[IEEE80211i] IEEE Draft 802.11I/D5.0, "Draft Supplement to STANDARD FOR Telecommunications and Information Exchange between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security", August 2003." to: "[IEEE80211i] IEEE Draft 802.11I/D6.1, "Draft Supplement to STANDARD FOR Telecommunications and Information Exchange between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security", August 2003." -------------------------------------------------------- Issue 178: Review of Key Framework Document Submitter name: Tschofenig Hannes Submitter email address: hannes.tschofenig@siemens.com Date first submitted: 9/29/2003 Reference: http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=http://www.levkowetz.com/ietf/drafts/eap/keying/review_hannes-aboba-pppext-key-problem-07.txt&comments=hannes: Document: Keyframe-07 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: I have compiled some comments for the eap key management framework draft. you find the comments at: http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=http://www.levkowetz.com/ietf/drafts/eap/keying/review_hannes-aboba-pppext-key-problem-07.txt&comments=hannes: _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 9 10:11: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 KAA21181 for ; Thu, 9 Oct 2003 10:11:08 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9E2AB580012; Thu, 9 Oct 2003 09:11:07 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78BAA580019; Thu, 9 Oct 2003 09:11:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CFA5580019 for ; Thu, 9 Oct 2003 09:10:28 -0500 (CDT) Received: from mta09.mail.mel.aone.net.au (mta09.mail.au.uu.net [203.2.192.90]) by mail.frascone.com (Postfix) with ESMTP id 81FA8580012 for ; Thu, 9 Oct 2003 09:10:26 -0500 (CDT) Received: from pc1 ([203.61.126.92]) by mta09.mail.mel.aone.net.au with ESMTP id <20031009140922.CQJP523.mta09.mail.mel.aone.net.au@pc1> for ; Fri, 10 Oct 2003 00:09:22 +1000 From: "Ehsan Sakhaee" To: Message-ID: <000601c38e6e$e5578210$5c7e3dcb@pc1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C38EC2.B7039210" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] authentication of EAP-Logoff 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, 10 Oct 2003 00:08:57 +1000 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C38EC2.B7039210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit How can a EAP-Logoff message be authenticated ? Like how would an AP know that the EAP-Logoff is coming from the legitimate client and not from a rogue one which is trying to cause a denial of service attack ? Regards, Ehsan ------=_NextPart_000_0007_01C38EC2.B7039210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How can a EAP-Logoff = message be authenticated ? =

Like how would an AP = know that the EAP-Logoff is coming from the legitimate client and not from a = rogue one which is trying to cause a denial of service attack ?

 

Regards,

 

Ehsan =

 

------=_NextPart_000_0007_01C38EC2.B7039210-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 9 10:26: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 KAA22372 for ; Thu, 9 Oct 2003 10:26:01 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7280958010A; Thu, 9 Oct 2003 09:26:07 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1006580019; Thu, 9 Oct 2003 09:26:01 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA065580019 for ; Thu, 9 Oct 2003 09:25:07 -0500 (CDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id AE739580012 for ; Thu, 9 Oct 2003 09:25:06 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id h99EP5k4004484; Thu, 9 Oct 2003 10:25:05 -0400 (EDT) From: Nick Petroni To: Ehsan Sakhaee Cc: Subject: Re: [eap] authentication of EAP-Logoff In-Reply-To: <000601c38e6e$e5578210$5c7e3dcb@pc1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 9 Oct 2003 10:25:05 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I believe you are talking about the EAPOL-Logoff message, correct? > How can a EAP-Logoff message be authenticated ? It can't unless the underlying medium provids some sort of protection. > Like how would an AP know that the EAP-Logoff is coming from the > legitimate client and not from a rogue one which is trying to cause a > denial of service attack ? 802-1X-REV-d7-0, section 7.9 states 802.1X takes no steps to provide either reliable authentication or data confidentiality in a shared medium environment. Attempting to use EAPOL in a shared medium environment that does not support reliable authentication and/or data confidentiality renders Port-based network access control highly vulnerable to attack; for example, station A can mount a successful denial of service attack on station B simply by issuing an EAPOL-Logoff packet using station B's individual MAC address. Nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 9 10:27:27 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 KAA22422 for ; Thu, 9 Oct 2003 10:27:07 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C49FF580012; Thu, 9 Oct 2003 09:27:07 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 155E8580027; Thu, 9 Oct 2003 09:27:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 76546580029 for ; Thu, 9 Oct 2003 09:26:52 -0500 (CDT) 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 32426580012 for ; Thu, 9 Oct 2003 09:26:43 -0500 (CDT) Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 09 Oct 2003 07:27:31 -0700 Received: from dhala-w2k01.cisco.com (dhcp-64-101-220-196.cisco.com [64.101.220.196]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h99EQQ5h029231; Thu, 9 Oct 2003 10:26:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20031009102440.05f1eb28@unitas.cisco.com> X-Sender: dhala@unitas.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: stds-802-11@ieee.org, ieee-802-11-tgi@majordomo.rsasecurity.com From: David Halasz Cc: aboba@internaut.com, jari.arkko@piuha.net, eap@frascone.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] ANNOUNCEMENT, TGi Interim Meeting, 14-16 October, 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: Thu, 09 Oct 2003 10:26:26 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Another reminder about the Herndon meeting on October 14-16. Also, for planning purposes, if you plan on attending, please send an email too: dhala@cisco.com, apotter@icsalabs.com Dave H. >X-Sender: dhala@unitas.cisco.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >Date: Fri, 03 Oct 2003 15:18:29 -0400 >To: stds-802-11@ieee.org, ieee-802-11-tgi@majordomo.rsasecurity.com >From: David Halasz >Subject: Fwd: Re: [802-11Technical] ANNOUNCEMENT, TGi Interim Meeting, > 14-16 October, Herndon, VA >Cc: aboba@internaut.com, jari.arkko@piuha.net, eap@frascone.com >Sender: owner-ieee-802-11-tgi@rsa.com > >A reminder about the Herndon meeting on October 14-16. > >Also, for planning purposes, if you plan on attending, please send an >email too: > dhala@cisco.com, apotter@icsalabs.com > > Dave H. > >>Date: Thu, 25 Sep 2003 19:43:18 -0400 >>To: stds-802-11@ieee.org, ieee-802-11-tgi@majordomo.rsasecurity.com >>From: David Halasz >>Subject: Re: [802-11Technical] ANNOUNCEMENT, TGi Interim Meeting, 14-16 >>October, Herndon, VA >>Cc: aboba@internaut.com, jari.arkko@piuha.net >> >>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 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 Thu Oct 9 19:01: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 TAA16077 for ; Thu, 9 Oct 2003 19:01:05 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F27F580013; Thu, 9 Oct 2003 18:01:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 52469580029; Thu, 9 Oct 2003 18:01:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A192D580029 for ; Thu, 9 Oct 2003 18:00:47 -0500 (CDT) Received: from old-n2.infonet.com (old-n2-130.infonet.com [192.157.130.138]) by mail.frascone.com (Postfix) with ESMTP id 47277580013 for ; Thu, 9 Oct 2003 18:00:46 -0500 (CDT) Received: from hubnotes1.infonet.com (hubnotes1 [198.137.76.56]) by old-n2.infonet.com with ESMTP id h99MusU29213 for ; Thu, 9 Oct 2003 22:56:54 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 10/09/2003 04:00:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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, 9 Oct 2003 16:00:43 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I will be out of the office starting 10/09/2003 and will not return until 10/10/2003. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 10 09:40: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 JAA27761 for ; Fri, 10 Oct 2003 09:40:09 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79483580119; Fri, 10 Oct 2003 08:40:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC1B358010A; Fri, 10 Oct 2003 08:40:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 097C158010E for ; Fri, 10 Oct 2003 08:39:51 -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 91B0458010A for ; Fri, 10 Oct 2003 08:39:49 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9AD4gC11543 for ; Fri, 10 Oct 2003 06:04:42 -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 181: Key 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: Fri, 10 Oct 2003 06:04:42 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 181: Key NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 10, 2003 Reference: Document: Keyframe-07 Comment type: E Priority: S Section: 7, Appendices Rationale/Explanation of issue: References section should be numbered: 7. References 7.1 Normative References 7.2 Informative References The [8021XHandoff] reference has got a number of problematic line breaks. In the Appendices, B should have the abbreviation spelled out: Appendix B Transient EAP Key (TEK) Hierarchy The TLS-PRF-X formula has problematic line breaks The Figure B-1 title should be on the same page, and has problematic line breaks. In Appendix C, both the AAA-Key(0,31) and AAA-Key(32.63) formulas have problematic line breaks. Similarly, TLS-PRF-X formula has problematic line breaks. In Appendix C, the Figure C-1 title has problematic line breaks. Appendix F (Acknowledgements) should be moved to before Authors' Addresses. Appendix G (Open Issues) need not be an Appendix. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 10 11:42: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 LAA04113 for ; Fri, 10 Oct 2003 11:42:19 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B3B1580113; Fri, 10 Oct 2003 10:42:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DBC6A580018; Fri, 10 Oct 2003 10:42:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8428580029 for ; Fri, 10 Oct 2003 10:41:24 -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 09494580017 for ; Fri, 10 Oct 2003 10:41:18 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9AF63118399 for ; Fri, 10 Oct 2003 08:06:05 -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 182: Authorization Issues 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, 10 Oct 2003 08:06:03 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 182: Authorization Issues Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 10, 2003 Reference: Document: Keyframe-07 Comment type: T Priority: S Section: 1.4 Rationale/Explanation of issue: Add the following section: "1.4 Authorization issues In a typical network access scenario (dial-in, wireless LAN, etc.) access control mechanisms are typically applied. These mechanisms include user authentication as well as authorization for the offered service. As a part of the authentication process, the AAA network determines the user's authorization profile. The user authorizations are transmitted by the AAA server to the EAP authenticator (also known as the Network Access Server or NAS) included with the AAA-Token, which also contains the AAA-Key, in Phase 1b of the EAP conversation. Typically, the profile is determined based on the user identity, but a certificate presented by the user may also provide authorization information. The AAA server is responsible for making a user authorization decision, answering the following questions: o Is this a legitimate user for this particular network? o Is this user allowed the type of access he or she is requesting? o Are there any specific parameters (mandatory tunneling, bandwidth, filters, and so on) that the access network should be aware of for this user? o Is this user within the subscription rules regarding time of day? o Is this user within his limits for concurrent sessions? o Are there any fraud, credit limit, or other concerns that indicate that access should be denied? While the authorization decision is in principle simple, the process is complicated by the distributed nature of AAA decision making. Where brokering entities or proxies are involved, all of the AAA devices in the chain from the NAS to the home AAA server are involved in the decision. For instance, a broker can disallow access even if the home AAA server would allow it, or a proxy can add authorizations (e.g., bandwidth limits). Decisions can be based on static policy definitions and profiles as well as dynamic state (e.g. time of day or limits on the number of concurrent sessions). In addition to the Accept/Reject decision made by the AAA chain, parameters or constraints can be communicated to the NAS. The criteria for Accept/Reject decisions or the reasons for choosing particular authorizations are typically not communicated to the NAS, only the final result. As a result, the NAS has no way to know what the decision was based on. Was a set of authorization parameters sent because this service is always provided to the user, or was the decision based on the time/day and the capabilities of the requesting NAS device? Within EAP, "fast handoff" is defined as a conversation in which the EAP exchange (phase 1a) and associated AAA passthrough is bypassed, so as to reduce latency. Depending on the fast handoff mechanism, AAA-Key transport (phase 1b) may also be bypassed in favor a context transfer (see [IEEE80211f] and [Context]) or it may be provided in a pre-emptive manner as in [IEEE-03-084] and [I-D.irtf-aaaarch-handoff]. As we will discuss, the introduction of fast handoff creates a new class of security vulnerabilities as well as requirements for the secure handling of authorization context. 1.4.1. Correctness in fast handoff Bypassing all or portions of the AAA conversation creates challenges in ensuring that authorization is properly handled. These include: o Consistent application of session time limits. A fast handoff should not automatically increase the available session time, allowing a user to endlessly extend their network access by changing the point of attachment. o Avoidance of privilege elevation. A fast handoff should not result in a user being granted access to services which they are not entitled to. o Consideration of dynamic state. In situations in which dynamic state is involved in the access decision (day/time, simultaneous session limit) it should be possible to take this state into account either before or after access is granted. Note that consideration of network-wide state such as simultaneous session limits can typically only be taken into account by the AAA server. o Encoding of restrictions. Since a NAS may not be aware of the criteria considered by a AAA server when allowing access, in order to ensure consistent authorization during a fast handoff it may be necessary to explicitly encode the restrictions within the authorizations provided in the AAA-Token. o State validity. The introduction of fast handoff should not render the authentication server incapable of keeping track of network-wide state. A fast handoff mechanism capable of addressing these concerns is said to be "correct". One condition for correctness is as follows: For a fast handoff to be "correct" it MUST establish on the new device the same context as would have been created had the new device completed a AAA conversation with the authentication server. A properly designed fast handoff scheme will only succeed if it is "correct" in this way. If a successful fast handoff would establish "incorrect" state, it is preferable for it to fail, in order to avoid creation of incorrect context. Some AAA server and NAS configurations are incapable of meeting this definition of "correctness". For example, if the old and new device differ in their capabilities, it may be difficult to meet this definition of correctness in a fast handoff mechanism that bypasses AAA. AAA servers often perform conditional evaluation, in which the authorizations returned in an Access-Accept message are contingent on the NAS or on dynamic state such as the time of day or number of simultaneous sessions. For example, in a heterogeneous deployment, the AAA server might return different authorizations depending on the NAS making the request, in order to make sure that the requested service is consistent with the NAS capabilities. If differences between the new and old device would result in the AAA server sending a different set of messages to the new device than were sent to the old device, then if the fast handoff mechanism bypasses AAA, then the fast handoff cannot be carried out correctly. For example, if some NAS devices within a deployment support dynamic VLANs while others do not, then attributes present in the Access-Request (such as the NAS-IP-Address, NAS-Identifier, Vendor-Identifier, etc.) could be examined to determine when VLAN attributes will be returned, as described in [RFC3580]. VLAN support is defined in [IEEE8021Q]. If a fast handoff bypassing the AAA server were to occur between a NAS supporting dynamic VLANs and another NAS which does not, then a guest user with access restricted to a guest VLAN could be given unrestricted access to the network. Similarly, in a network where access is restricted based on the day and time, SSID, Calling-Station-Id or other factors, unless the restrictions are encoded within the authorizations, or a partial AAA conversation is included, then a fast handoff could result in the user bypassing the restrictions. In practice, these considerations limit the situations in which fast handoff mechanisms bypassing AAA can be expected to be successful. Where the deployed devices implement the same set of services, it may be possible to do successful fast handoffs within such mechanisms. However, where the supported services differ between devices, the fast handoff may not succeed. For example, [RFC2865], section 1.1 states: "A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that is unable to offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead." Note that this behavior only applies to attributes that are known, but not implemented. For attributes that are unknown, section of 5 of [RFC2865] states: "A RADIUS server MAY ignore Attributes with an unknown Type. A RADIUS client MAY ignore Attributes with an unknown Type." In order to perform a correct fast handoff, if a new device is provided with RADIUS context for a known but unavailable service, then it MUST process this context the same way it would handle a RADIUS Access-Accept requesting an unavailable service. This MUST cause the fast handoff to fail. However, if a new device is provided with RADIUS context that indicates an unknown attribute, then this attribute MAY be ignored. Although it may seem somewhat counter-intuitive, failure is indeed the "correct" result where a known but unsupported service is requested. Presumably a correctly configured AAA server would not request that a device carry out a service that it does not implement. This implies that if the new device were to complete a AAA conversation that it would be likely to receive different service instructions. In such a case, failure of the fast handoff is the desired result. This will cause the new device to go back to the AAA server in order to receive the appropriate service definition. In practice, this implies that fast handoff mechanisms which bypass AAA are most likely to be successful within a homogeneous device deployment within a single administrative domain. For example, it would not be advisable to carry out a fast handoff bypassing AAA between a NAS providing confidentiality and another NAS that does not support this service. The correct result of such a fast handoff would be a failure, since if the handoff were blindly carried out, then the user would be moved from a secure to an insecure channel without permission from the AAA server. Thus the definition of a "known but unsupported service" MUST encompass requests for unavailable security services. This includes vendor-specific attributes related to security, such as those described in [RFC2548]." Add to the author list: Jari Arkko Add to the reference list: [Context] Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE 802", draft-aboba-802-context-03.txt, Internet draft (work in progress), October 2003. [IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q/D8, January 1998. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 10 11:45: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 LAA04190 for ; Fri, 10 Oct 2003 11:45:06 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22A2D580017; Fri, 10 Oct 2003 10:45:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79CFE580029; Fri, 10 Oct 2003 10:45:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AEC2A580112 for ; Fri, 10 Oct 2003 10:44:48 -0500 (CDT) Received: from ietf.org (unknown [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 6F3A1580017 for ; Fri, 10 Oct 2003 10:44:34 -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 LAA04173 for ; Fri, 10 Oct 2003 11:43:58 -0400 (EDT) Message-Id: <200310101543.LAA04173@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: 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-adrangi-eap-network-discovery-and-selection-00.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, 10 Oct 2003 11:43:58 -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. Title : Network Discovery and Selection within the EAP Framework Author(s) : F. Adrangi Filename : draft-adrangi-eap-network-discovery-and-selection-00.txt Pages : 22 Date : 2003-10-2 This document proposes a solution for Service Network discovery and selection that could be implemented within the existing EAP specification framework. The purpose of Service Network discovery and selection here is to help a WLAN client using EAP for authentication to decide whether or not to connect to a WLAN Access Network, and help it select the most appropriate Mediating Network as a next hop for routing AAA packets in roaming situations where the WLAN Access Network has agreements with more than one Mediating Network affiliated with the clientÆs Home Service Network. The proposed solution has 3 components: a delivery mechanism for conveying Access Network and Service Network Information to a WLAN client, a data model/syntax for structuring the information in a generic manner, and a method by which the WLAN client can indicate its selection to the WLAN Access Network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-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-adrangi-eap-network-discovery-and-selection-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-adrangi-eap-network-discovery-and-selection-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-10-10103436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-adrangi-eap-network-discovery-and-selection-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-10103436.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 13 09:11: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 JAA02944 for ; Mon, 13 Oct 2003 09:11:11 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 73D16580024; Mon, 13 Oct 2003 08:11:11 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0358E58001D; Mon, 13 Oct 2003 08:11:05 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F18DB58001C for ; Mon, 13 Oct 2003 08:10:10 -0500 (CDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id C7C51580016 for ; Mon, 13 Oct 2003 08:10:09 -0500 (CDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D04B06A905; Mon, 13 Oct 2003 16:10:06 +0300 (EEST) Message-ID: <3F8AA342.5040908@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 182: Authorization Issues References: In-Reply-To: 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: Mon, 13 Oct 2003 16:06:10 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > A fast handoff mechanism capable of addressing these concerns is said to > be "correct". One condition for correctness is as follows: I really like this formulation of the requirements for fast handoff! > In practice, this implies that fast handoff mechanisms which bypass AAA > are most likely to be successful within a homogeneous device deployment > within a single administrative domain. Yes. I would add that we probably need an explicit statement from the backend authentication server that dynamic state or per-NAS rules do not prevent fast handoff. Even if the APs are exactly similar, it may be that the server has different rules e.g. due to their location. That is, an "Allow-Fast-Handoff" AVP may be needed. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 13 15:56: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 PAA23921 for ; Mon, 13 Oct 2003 15:56:07 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8941C580010; Mon, 13 Oct 2003 14:56:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3C12D58001D; Mon, 13 Oct 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 6887F580016 for ; Mon, 13 Oct 2003 14:55:39 -0500 (CDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 74E67580010 for ; Mon, 13 Oct 2003 14:55:37 -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 PAA23822; Mon, 13 Oct 2003 15:55:27 -0400 (EDT) Message-Id: <200310131955.PAA23822@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-keying-00.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, 13 Oct 2003 15:55:26 -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 : EAP Key Management Framework Author(s) : B. Aboba, et. al. Filename : draft-ietf-eap-keying-00.txt Pages : 55 Date : 2003-10-13 This document provides a framework for EAP key management, including a statement of applicability and guidelines for generation, transport and usage of EAP keying material. Algorithms for key derivation or mechanisms for key transport are not specified in this document. Rather, this document provides a framework within which algorithms and transport mechanisms can be discussed and evaluated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-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-keying-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-keying-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-10-13145451.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-keying-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-keying-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-13145451.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 13 16:38: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 QAA27563 for ; Mon, 13 Oct 2003 16:38:19 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 46B78580010; Mon, 13 Oct 2003 15:38:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DCA0A580016; Mon, 13 Oct 2003 15:38:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 993F7580016 for ; Mon, 13 Oct 2003 15:37:48 -0500 (CDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 869EF580010 for ; Mon, 13 Oct 2003 15:37:47 -0500 (CDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6DA4F6A905 for ; Mon, 13 Oct 2003 23:37:46 +0300 (EEST) Message-ID: <3F8B0C2E.3060602@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 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] REMINDER: EAP WG interim meeting in Herndon, October 15th 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, 13 Oct 2003 23:33:50 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Details available at http://www.drizzle.com/~aboba/EAP/interim.txt -- Jari & Bernard _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 14 18:38: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 SAA08060 for ; Tue, 14 Oct 2003 18:38:02 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38E64580029; Tue, 14 Oct 2003 17:38:10 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E3156580109; Tue, 14 Oct 2003 17:38:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 83DF3580029 for ; Tue, 14 Oct 2003 17:37:16 -0500 (CDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 68F5C580010 for ; Tue, 14 Oct 2003 17:37:15 -0500 (CDT) Received: from www.piuha.net (localhost [127.0.0.1]) by p2.piuha.net (Postfix) with SMTP id 6AF906A903 for ; Wed, 15 Oct 2003 01:37:13 +0300 (EEST) Received: from 66.255.177.162 (SquirrelMail authenticated user jarkko) by www.piuha.net with HTTP; Wed, 15 Oct 2003 01:37:13 +0300 (EEST) Message-ID: <32800.66.255.177.162.1066171033.squirrel@www.piuha.net> From: jari.arkko@piuha.net To: eap@frascone.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Agenda for the EAP WG interim meeting in Herndon, October 15th 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, 15 Oct 2003 01:37:13 +0300 (EEST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 8bit Here is the agenda for the 10/15/03 EAP WG Interim meeting (morning) and joint 802.11i/EAP WG discussion (afternoon). -------------------------------------------------------- Extensible Authentication Protocol (eap) Interim Meeting Herndon, VA October 15, 2003 0900 - 1700 Information: http://www.drizzle.com/~aboba/EAP/interim.txt Chair(s): Bernard Aboba Jari Arkko Morning Agenda (0900 - 1200) -------------- Preliminaries (10 minutes) Agenda Bashing Bluesheets Minutes Document Status EAP Key Framework I (80 minutes) Open Issues (10 minutes) Bernard Aboba http://www.drizzle.com/~aboba/EAP/eapissues.html Conversation Overview (20 minutes) - Pasi Eronen Security Associations (50 minutes) - Pasi Eronen Break (10 minutes) EAP Key Framework II (60 minutes) Key Scoping & Fast Handoff (20 minutes - Bernard ABoba Authorization & Fast handoff (20 minutes) - Jari Arkko Diameter EAP (20 minutes) - Pasi Eronen & Jari Arkko Afternoon Agenda (1300 - 1700) ------------------------------ Preliminaries (10 minutes) Agenda Bashing Bluesheets Minutes IETF Document Status and Process (15 minutes), Jari Arkko & Bernard Aboba IEEE Document Status and Process (15 minutes), Dave Halaz Security Associations sync (50 minutes) - Pasi Eronen Break (10 minutes) Key Scoping & Fast Handoff (30 minutes - Bernard Aboba Authorization & Fast Handoff (20 minutes) - Jari Arkko Reading Materials ----------------- EAP Key Framework http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-00.txt EAP State Machine http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-00.txt http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-00.pdf RFC 2284bis http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.txt IEEE Drafts ----------- Userid: p8021 password: go_wildcats IEEE 802.11i D6.0 http://grouper.ieee.org/groups/802/11/private/Draft_Standards/11i/802.11i-D6.0.pdf IEEE 802.1X-REV-D7.1 http://www.ieee802.org/1/files/private/x-REV-drafts/d7/802-1X-REV-d7-1.pdf _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 14 19:04: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 TAA08657 for ; Tue, 14 Oct 2003 19:03:06 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 77022580027; Tue, 14 Oct 2003 18:03:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DEB2F580029; Tue, 14 Oct 2003 18:03:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F330580029 for ; Tue, 14 Oct 2003 18:02:48 -0500 (CDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id C6048580027 for ; Tue, 14 Oct 2003 18:02:46 -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.8) with ESMTP id h9EN2iX10116 for ; Wed, 15 Oct 2003 02:02:44 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 15 Oct 2003 02:02:44 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 02:02:44 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 02:02:43 +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: <052E0C61B69C3741AFA5FE88ACC775A6010C384C@esebe023.ntc.nokia.com> Thread-Topic: Issue: New text about conversation phases Thread-Index: AcOSp0VO+gwtE/usSHiqJbD42crcsQ== From: To: X-OriginalArrivalTime: 14 Oct 2003 23:02:43.0937 (UTC) FILETIME=[46ABE510:01C392A7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue: New text about conversation phases 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, 15 Oct 2003 02:02:43 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable New text about conversation phases Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: October 14, 2003 Reference:=20 Document: Keying framework Comment type: T Priority: 1 Section: 1.3 Rationale/Explanation of issue: Here is a proposed replacement for section 1.3 of the keying framework (note that this will most likely be=20 revised during/after the interim meeting). 1.3. Conversation Overview Where EAP key derivation is supported, EAP authentication is typically a component of a four phase exchange: Discovery (phase 0) EAP authentication (phase 1a) Access authorization (phase 1b) Service authentication (phase 2) =20 In the discovery phase (phase 0), the parties locate and contact each, and then exchange some information about the service to be provided. For instance, one of the parties may indicate its willingness to provide a service (and to perform the EAP authenticator role), and the other party requests access to that service (assuming the EAP peer role). Next, the EAP peer and backend authentication server authenticate each other (phase 1a) and derive a shared session key (later called Authorization Key). In this phase, the authenticator just forwards EAP packets between the peer and backend authentication server (note that in some cases, the authenticator and backend authentication server can be colocated in the same physical node). This feature of EAP enables deployment of new authentication methods without requiring development of new code on the authenticator. =20 Partially overlapping with this exchange is a second exchange (phase 1b), between the authenticator and the backend authentication server. In this exchange, the authenticator and backend authentication server authenticate each other (using some other mechanism than EAP), and authenticator sends information about the service requested by the peer (typically inside some AAA protocol attributes). When the phase 1a has finished, the backend authentication server sends the authenticator information about whether the service should be provided or not, a key for protecting service communication (Authorization Key), and optionally more detailed instructions about the service to be provided. After both phases 1a and 1b are complete, the authenticator signals the peer it will allow access to the service (phase 2). Next, the peer and authenticator typically exchange more parameters about the service to be provided (most likely some were already exchanged during phase 0), protect at least some of these parameters using the Authorization Key, and agree about keys used to protect subsequent communication. The goal is to ensure that an attacker not knowing the Authorization Key cannot modify the protected parameters or calculate the keys that will be subsequently used. The phases and the relationship between the parties is illustrated below. EAP peer Authenticator Auth. Server -------- ------------- ------------ <----------------------------> Discovery (phase 0) <------------------------------------------------------> EAP authentication (phase 1a) =20 <-------------------------> Access authorization (phase 1b) <----------------------------> Service authentication (phase 2) =20 1.3.1 A concrete example: IEEE 802.11i ESS (Details to be added; this is just a sketch) =20 o Phase 0: Typically, the client (peer) discovers the access point (authenticator) by listening to Beacon messages, and requests access by sending an Assocation Request message. The service parameters exchanged in phase 0 include the SSID, data rates, supported ciphersuites, hop patterns (and other PHY parameters). The AP initiates phase 1a by sending an EAP Identity Request, encapsulated inside an EAPOL frame (though in some cases, the AP requests the backend authentication server to send this). o In phase 1a, the client and backend authentication server authenticate each other. For instance, if EAP-TLS is used, they both exchange certificates, verify that the certificates are valid and belong to the expected party, and prove=20 that they know the corresponding private keys. This exchange also generates a shared key between them. o Phase 1b typically uses RADIUS. The RADIUS packets are authenticated either with RADIUS's own shared secret mechanism (Message-Authenticator), or IPsec. The access point sends an Access-Request message containing various service parameters (such as Service-Type, Calling-Station-Id, and Called-Station-Id). When phase 1a has finished, the backend authentication server gives permission for the service (Access-Accept), and sends e.g. Authorization Key and Session-Timeout. o Phase 2 includes the four-way handshake and group key=20 handshake. These exchanges protect various service parameters (MAC addresses, RSN IE, selected ciphersuite) and produce keys for encrypting the actual traffic. =20 After phase 2, the parties protect the 802.11 data frames with TKIP or CCMP (basically, encryption and MAC using the keys negotiated in phase 2, and sequence numbers for replay protection). 1.3.2 Second example: IKEv2/IPsec This example assumes a "road warrior VPN gateway" type situation where the IKEv2 SA is authenticated solely using EAP (no certificates are necessary). o Phase 0: IKEv2 doesn't usually use "discovery" in strict sense; instead, the client (initiator) is configured with the IPsec gateway's address or DNS name. The client contacts the gateway and they exchange Diffie-Hellman parameters, nonces and select an IKEv2 ciphersuite. The client also indicates the willingness to use EAP by leaving out the AUTH payload from the third message. =20 o Phase 1a is similar as above (although it is likely that some other EAP method than EAP-TLS would be used). o Phase 1b is also very similar. Although no "RADIUS guidelines for IKEv2" document exists yet, RADIUS could be used with very small modifications (perhaps a new value for Service-Type and agreement about what to put in Calling-Station-Id/Called-Station-Id attributes). o Phase 2: In this phase, the client and the gateway=20 authenticate the IKEv2 SA by using Authorization Key to compute a MAC of the Diffie-Hellman parameters and nonces (and some other information) exchanged in phase 0. This implicitly protects other parameters and the rest of the conversation as well. The service parameters negotiated next include details about client IP addresses, what IP traffic will be protected, what ciphersuites will be used, and so on. After this, the traffic is typically protected with ESP or AH. 1.3.3 Repeating the conversation=20 There are several reasons why a service might require new phase 1a/1b conversation. =20 o The service may require periodic reauthentication (and reauthorization): A new phase 1a/1b is used to check that the client still has the correct credentials, and the authorization granted by the backend authentication server is still valid. =20 o Service parameters may have changed in a way that requires new authorization granted by the backend authentication=20 server. =20 For instance, suppose that the peer is allowed WLAN access with 802.11g physical layer; is the user allowed to switch to 802.11b? In this case, the answer is most likely yes--the backend authentication server isn't concerned with such small details. The peer and authenticator can negotiate this change in service parameters without having a new phase 1a/1b exchange. However, if the user is accessing SSID "Joe's HotSpot", does this authorization also give access to SSID "Example Inc. Intranet"? Most likely no--this is a detail the backend authentication server would like to know about. =20 Depending on the service, there are service parameters between these two extremes: some of them matter when authorizing access, some are small details that can be negotiated freely between the peer and the authenticator. See Section X.X for more discussion about the authorization issues. o The authenticator has lost the state associated with this service, or the state is no longer synchronized. This may occur if, for instance, the authenticator is rebooted, or if the the service is moved to a different physical service element (see Sections X.X.X (TBD: correctness=20 of fast handoff) and 3.3.3 for more discussion about this). 1.4 Conversation limitations It is worthwhile to point out two important limitations. The first one is rather trivial, and applies only to some phase 2 protocols. However, the second one is much less obvious, and is more a fundamental limitation of the EAP design. 1.4.1 Protection of service parameters in phase 2 Typically, phase 2 does not protect all parameters about the service. That is, even an attacker who does not know the Authorization Key can cause the parties to have a different idea of some service parameters. For instance, MPPE [RFC3078] does not protect the selected ciphersuite, potentially allowing a "downgrade attack" in which an attacker causes a weaker ciphersuite to be selected than would have been otherwise. To take a second example, IEEE 802.11i does not protect the SSID, capability information, data rates and PHY-specific parameters sent in Beacon messages. Of course, not all parameters necessarily need protection, since they are not useful in any practical attacks. Selecting what parameters to protect is a design decision in the phase 2 protocol, not a fundamental property of the EAP design. 1.4.2 Independence of phases 1a and 1b Currently, phases 1a and 1b are (almost) independent of each other. They are usually carried inside the same RADIUS packets, but in an important sense they are still independent. (At least in theory, it would be possible to have a system where the EAP packets would not go through the authenticator at all). The most important consequence of this is that the backend authentication server cannot restrict the service parameters used by the authenticator. A malicious or compromised authenticator (that is trusted by the backend authentication server) can present any set of service parameters it wants to the peer. The parameters can be protected at phase 2, but at this point they are protected using a key known to the authenticator. Leaving the service parameters to the authenticator actually makes sense in many situations. For instance, in WLANs the authenticator (AP) knows best what data rates, hop patterns or ciphersuites it supports. It would probably not be wise to require the backend authenticator server to know about these. However, there are situations where the backend authentication server might want to restrict some particular service parameters. For instance, currently a WLAN access point offering service for SSID "Joe's Hotspot" could also claim to offer service for SSID "Harry's Hotspot" or "Example Inc. Intranet". To take a second example, an IKEv2 gateway could claim to offer WLAN service, and if the IKEv2 session is authenticated solely using EAP (without any certificates), a WLAN access point could claim to offer IKEv2 services. 1.4.3 Connecting phases 1a and 1b The separation of phases 1a and 1b is a fundamental limitation of current EAP design. There have been discussions whether this limitation is actually a significant problem or not, and if so, how it could be solved. It seems that any solution involves three necessary components: 1) The backend authentication server has to get the values for those parameters. 2) The backend authentication server has to check that=20 the authenticator it is sending the Authorization Key to is=20 actually authorized to use those values.=20 This most likely involves a database on the backend authentication server, connecting the authenticated identity of the authenticator (AAA SA, see Section 3.4)=20 to the authorized values (such as SSID). =20 3) The authenticator has to be prevented from telling different values to the peer and backend authentication server.=20 a) The values could communicated inside the EAP exchange, protected using keys known only to the peer and the backend authentication server (EAPv2 or Archie). b) The backend authentication server (and the peer) could include the values of these parameters when deriving the Authorization Key (from keys known only to the peer and the backend authentication server). Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 14 19:10:38 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 TAA08862 for ; Tue, 14 Oct 2003 19:10:05 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 26D11580109; Tue, 14 Oct 2003 18:10:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2417058010A; Tue, 14 Oct 2003 18:10:04 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 07E35580109 for ; Tue, 14 Oct 2003 18:09:05 -0500 (CDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 5C441580029 for ; Tue, 14 Oct 2003 18:09:03 -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.8) with ESMTP id h9EN91X15751 for ; Wed, 15 Oct 2003 02:09:01 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 15 Oct 2003 02:09:01 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 02:09:00 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 02:09:00 +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: <052E0C61B69C3741AFA5FE88ACC775A6010C384D@esebe023.ntc.nokia.com> Thread-Topic: Issue: Security associations Thread-Index: AcOSqCWenDmYuXmVQ8+zRwgvcr1HkA== From: To: X-OriginalArrivalTime: 14 Oct 2003 23:09:00.0242 (UTC) FILETIME=[26F77B20:01C392A8] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue: Security associations 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, 15 Oct 2003 02:09:00 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Oops, the previous e-mail wasn't actually a new issue; it was=20 an update of issue 180 which has a wrong name (it should be something else than "SA Descriptions"--the new issue in THIS message is about SAs). Security associations Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: October 14, 2003 Reference:=20 Document: Keying framework Comment type: T Priority: 1 Section: 3 Rationale/Explanation of issue: Here is proposed replacement for Section 3 of the keying framework (will be updated during/after interim, especially the 802.11i specific parts!). 3. Security Associations The EAP model has four types of security associations (SAs): [1] Long-term EAP SA. This is an SA between the peer and backend authentication server, and it allows them to authenticate each other. [2] Short-term EAP method SA. This SA is also between the peer and backend authentication server. It stores state that can be used for "fast resume" or other functionality=20 in some EAP methods. Not all EAP methods have this SA. [3] Service SA(s). These SAs are between the peer and authenticator, and they are created as a result of phases 0-2 of the conversation (see Section 1.3). [4] AAA SA(s). These SAs are between the authenticator and the backend authentication server. They allow the parties to authenticate each other and protect the communications between them.=20 3.1 Long-term EAP SA (peer - backend authentication server) =20 In order for the peer and backend authentication server to authenticate each other, they need to store some information. =20 The authentication can be based on different mechanisms, such as shared secrets or certificates. If the authentication is based on a shared secret key, the parties store the EAP method to be used and the key. The backend authentication server also stores the peer's identity and/or other information necessary to decide whether access to some service should be granted. The peer stores information necessary to choose which secret to use for which service. (TBD: Possibility of "alternate means of access") 3.2 Short-term EAP method SA (peer - backend authentication server) An EAP method may store some state on the peer and backend authentication server even after phase 1a has completed. =20 Typically, this is used for "fast resume": the peer and backend authentication server can confirm that they are still talking to the same party, perhaps using fewer roundtrips or less computational power. In this case, the EAP method SA is essentially a cache for performance optimization, and either party may remove the SA from its cache at any point. Another purpose for an EAP method to keep state is for pseudonym-based identity protection. This usually works as a cache as well (the information will be recreated if the original EAP method SA is lost), but may be stored for longer periods of time. The EAP method SA is not restricted to some particular service type or authenticator; indeed, these EAP method SAs are especially useful when the peer often accesses services from many different authenticators. Each EAP method should specify how the parties select if an existing EAP method SA should be used, and which EAP method SA should be used (if several are maintained). Note that in case there are multiple different backend authentication servers, the EAP method SAs are not typically synchronized between them. EAP methods should also consider how long the SA is stored. The "fast resume" typically assumes that the information needed (primarily the keys in the EAP method SA) hasn't been compromised. In case the original authentication was carried out using, for instance, a smart card, it may be easier to compromise the EAP method SA (stored on the PC, for instance), so typically the EAP method SAs have a limited lifetime. 3.2.1 Example: EAP-TLS In EAP-TLS, after the EAP authentication the client (peer) and server (backend authentication server) can store the following information: o Implicitly, the EAP method this method SA refers to (EAP-TLS) o Session identifier (a random value selected by the server) o Certificate of the other party (server stores the clients's=20 certificate and vice versa) o Cipher spec and compression method o Master secret (a secret key) o Some kind of lifetime information (ensuring that the SA is not stored forever) o If the client has multiple different credentials (certificates and corresponding private keys), pointer to those credentials When the server initiates EAP-TLS, the client can look up the EAP-TLS SA based on the credentials it was going to use (certificate and private key), and the expected credentials (certificate or name) of the server. If an EAP-TLS SA exists, and it is not too old, the client informs the server about the existence of this SA by including its Session-Id in the TLS ClientHello message. The server then looks up the correct SA based on the Session-Id (or detects that it doesn't yet have one). 3.2.2 Example: EAP-AKA In EAP-AKA, after the EAP authentication the client and server can store the following information:=20 o Implicitly, the EAP method this method SA refers to (EAP-AKA) o A re-authentication pseudonym=20 o The server stores the client's permanent identity (IMSI) o Replay protection counter o Authentication key (K_aut) o Encryption key (K_encr) o Original Master Key (MK) When the server initiates EAP-AKA, the client can look up the EAP-AKA SA based on the credentials it was going to use (permanent identity). If an EAP-AKA SA exists, and it is not too old, the client informs the server about the existence of this SA by sending its re-authentication pseudonym as its identity in EAP Identity Response message, instead of its permanent identity. The server then looks up the correct SA based on this identity. 3.3 Service SA(s) (peer - authenticator) The service SA stores information about the service being provided. This includes: o Service parameters (or at least those parameters that are still needed) o On the authenticator, service authorization information=20 received from the backend authentication server (or=20 necessary parts of it) o On the peer, usually locally configured service authorization information. o Keys used to protect the communication=20 o Possibly also the Authorization Key, if there is a possibility=20 that it will be needed again (to refresh and/or resynchronize=20 other keys, or sequence numbers, or something else) The information in the service SA can be grouped into several different SAs. This would make sense if, for instance, the=20 service provided is naturally divided into several different subconversations with different parameters. =20 How exactly the relevant service SA is chosen at each point depends on the protocol; see below for examples. 3.3.1 Example: 802.11i=20 =20 Note that this example is intended to be informative, and it does not necessarily include all information stored. o PMKSA - Key (PMK) - PMKID=20 - SSID - Supplicant and authenticator group addresses (PMKSA can be=20 used if the SSID and group addresses stay the same) - Key replay counters (for EAPOL-Key messages) - Lifetime information (that can be different client and AP) - Reference to PTKSA (if any), needed for: - to delete it (e.g. AAA server-initiated disconnect) - to replace it when a new four-way handshake is done after reauthentication - Authorization information. On the authenticator, this can be locally configured or received from the backend authentication server. On the peer, this is usually locally configured. =20 - Reference to accounting context (the details of which depend=20 on the accounting protocol used, and various implementation=20 and administrative details. In RADIUS, this could include=20 e.g. packet and octet counters, and Acct-Multi-Session-Id). =20 o PTKSA The PTKSA is created based on the four-way handshake. When receiving or sending a packet, the correct PTKSA is looked up based on TA and RA (Transmitter/Received Address). - Key (PTK) - Selected ciphersuite - MAC addresses of the parties - Replay counters, and ciphersuite specific state - Reference to PMKSA: This is needed for - If a new four-way handshake is needed (lifetime, TKIP countermeasures), we need to know which PMKSA to use - Via the reference to PMKSA, or copied here:=20 - SSID (to select VLAN tags) - Authorization information (such as L2 packet filters) - Reference to accounting context (right counters etc.) o GTKSA The GTKSA is created based on the four-way handshake, or the four-way handshake and a separate group key handshake. When receiving a packet, the correct GTKSA is looked up based on source MAC address. When sending a packet, this is looked up by own MAC address and SSID. - Direction bit - Key (GTK) - Sender (AP) MAC address=20 - Selected cipher suite - Ciphersuite-specific data - Via reference to PMKSA, or copied here: - SSID (to select VLAN tags) - Reference to accounting context 3.3.2 Example: IKEv2/IPsec =20 Note that this example is intended to be informative, and it does not necessarily include all information stored. o IKEv2 SA - Protocol version=20 - Identitites of the parties - IKEv2 SPIs - Selected ciphersuite - Replay protection counters (Message ID) - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er) - Key for deriving keys for IPsec SAs (SK_d) - Lifetime information - On the authenticator, service authorization information=20 received from the backend authentication server. When processing an incoming message, the correct SA is looked up based on the SPIs.=20 o IPsec SAs/SPD=20 - Traffic selectors - Replay protection counters - Selected ciphersuite=20 - IPsec SPI - Keys =20 - Lifetime information - Protocol mode (tunnel or transport) The correct SA is looked up based on SPI (for inbound packets), or SPD traffic selectors (for outbound traffic). A separate IPsec SA exists for each direction. 3.3.3 Sharing service SAs A single service may be provided by multiple logical or physical service elements. Each service is responsible for specifying how changing service elements is handled. Some approaches include: o Transparent sharing: If the service parameters visible to the other party (either peer or authenticator) do not change, the service can be moved without requiring cooperation from the other party. =20 Whether such a move should be supported or used depends on implementation and administrative considerations. For instance, an administrator may decide to configure a group of IKEv2/IPsec gateways in a cluster for high-availability purposes, if the implementation used supports this. The peer does not necessarily have any way of knowing when the change occurs. o No sharing: If the service parameters require changing, some changes may require terminating the old service, and starting a new conversation from phase 0. This approach is used by all services for at least some parameters, and it doesn't require any protocol for transferring the service SA between the service elements. The service may support keeping the old service element active while the new conversation takes phase, to decrease the time the service is not available. o Some sharing: The service may allow changing some parameters by simply agreeing about the new values. This may involve a similar exchange as in phase 2, or perhaps a shorter conversation. This option usually requires some protocol for transferring the service SA between the elements. An administrator may decide not to enable this feature at all, and typically the sharing is restricted to some particular service elements (defined either by a service parameter, or simple administrative decision). If the old and new service element do not support such "context transfer", this approach falls back to the previous option (no transfer). Services supporting this feature should also consider what changes require new authorization from the backend authentication server (see Section 1.7). Note that these considerations are not limited to service parameters related to the authenticator--they apply to peer's parameters as well.=20 3.4 AAA SA(s) (authenticator - backend authentication server) In order for the authenticator and backend authentication server to authenticate each other, they need to store some information. In case the authenticator and backend authentication server are colocated in the same node, and they communicate using, for instance, local procedure calls or shared memory, this SA does not necessarily contain any information. 3.4.1 Example: RADIUS In RADIUS, the parties store the other party's IP address and the shared secret. This shared secret is used to calculate Response Authenticator and Message-Authenticator values, and to encrypt some attributes (such as Authorization key). 3.4.2 Example: Diameter with TLS If using Diameter protected by TLS, the parties store information necessary to authenticate the other party (e.g., certificate, or trust anchors and a name). Running the TLS handshake results in a short-term TLS SA that contains information used to protect the actual communications (session keys, selected TLS ciphersuite, etc.). Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 15 09:57: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 JAA29810 for ; Wed, 15 Oct 2003 09:57:18 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8DF5A580019; Wed, 15 Oct 2003 08:57:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E2485580012; Wed, 15 Oct 2003 08:57:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7105A580012 for ; Wed, 15 Oct 2003 08:56:58 -0500 (CDT) Received: from junkmail.cs.umd.edu (junkmail.cs.umd.edu [128.8.128.69]) by mail.frascone.com (Postfix) with ESMTP id 47FFF580010 for ; Wed, 15 Oct 2003 08:56:57 -0500 (CDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by junkmail.cs.umd.edu (8.12.10/8.12.5) with ESMTP id h9FDuuPi024257 for ; Wed, 15 Oct 2003 09:56:56 -0400 (EDT) Received: from localhost ([127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id h9FDut0W002706 for ; Wed, 15 Oct 2003 09:56:55 -0400 (EDT) From: Nick Petroni To: 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] EAP Keying Framework Editorial 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: Wed, 15 Oct 2003 09:56:55 -0400 (EDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Typos/grammar errors in draft-ietf-eap-keying-00 Submitter name: Nick Petroni Submitter email address: npetroni@cs.umd.edu Date first submitted: October 15, 2003 Reference: Document: Keying Framework Comment type: E Priority: S Section: 2.1.2, 3.1 Rationale/Explanation of issue: Incorrect language, simple changes enclosed. Requested change: In section 2.1.2, second paragraph, change "cannot" to "can" In fact, the authenticator is not required to implement any EAP methods at all, nor cannot it be assumed to implement code specific to any EAP method. to In fact, the authenticator is not required to implement any EAP methods at all, nor can it be assumed to implement code specific to any EAP method. Requested change: In section 3.1, second full paragraph, change "may be" to "may" Some methods may be support "fast resume" by caching EAP SA state on the EAP peer and server. to Some methods may support "fast resume" by caching EAP SA state on the EAP peer and server. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 15 14:11: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 OAA13761 for ; Wed, 15 Oct 2003 14:11:02 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D306A580010; Wed, 15 Oct 2003 13:11:07 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD22A580014; Wed, 15 Oct 2003 13:11:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B4F57580016 for ; Wed, 15 Oct 2003 13:10:13 -0500 (CDT) Received: from old-n2.infonet.com (old-n2-130.infonet.com [192.157.130.138]) by mail.frascone.com (Postfix) with ESMTP id 15150580010 for ; Wed, 15 Oct 2003 13:10:11 -0500 (CDT) Received: from hubnotes1.infonet.com (hubnotes1 [198.137.76.56]) by old-n2.infonet.com with ESMTP id h9FI6BA12508 for ; Wed, 15 Oct 2003 18:06:11 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 10/15/2003 11:10:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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: Wed, 15 Oct 2003 11:10:02 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I will be out of the office starting 10/15/2003 and will not return until 10/16/2003. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Oct 19 12:25: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 MAA11966 for ; Sun, 19 Oct 2003 12:25:01 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9E5B158001C; Sun, 19 Oct 2003 11:25:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 57A76580024; Sun, 19 Oct 2003 11:25:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D2B49580024 for ; Sun, 19 Oct 2003 11:24:46 -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 658FF58001C for ; Sun, 19 Oct 2003 11:24:45 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9JFmk007734 for ; Sun, 19 Oct 2003 08:48:47 -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] Call for Agenda Items 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, 19 Oct 2003 08:48:46 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) If you've got a potential agenda item for the EAP WG at IETF 58, please send it to me and Jari. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Oct 19 13:05: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 NAA12806 for ; Sun, 19 Oct 2003 13:05:01 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DEB1058010E; Sun, 19 Oct 2003 12:05:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 413CD580024; Sun, 19 Oct 2003 12:05:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 74DE2580024 for ; Sun, 19 Oct 2003 12:04:16 -0500 (CDT) Received: from fw2.gdm.de (fw2.gdm.de [193.108.184.154]) by mail.frascone.com (Postfix) with ESMTP id D2A8A58001C for ; Sun, 19 Oct 2003 12:04:14 -0500 (CDT) Received: by fw2.gdm.de (8.11.6p2G/8.11.6) id h9JH4D720955 for eap@frascone.com; Sun, 19 Oct 2003 19:04:13 +0200 (CEST) Received: (from localhost) by fw2.gdm.de (MSCAN) id 2/fw2.gdm.de/smtp-gw/mscan; Sun Oct 19 19:04:13 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 19.10.2003 19:00:25 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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: Sun, 19 Oct 2003 19:01:17 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Ich werde ab 17.10.2003 nicht im B=FCro sein. Ich kehre zur=FCck am 23.10.2003. I am away from my email. I will respond to your message when back on October 23th.= _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 20 04:42: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 EAA17779 for ; Mon, 20 Oct 2003 04:42:05 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4664D58001E; Mon, 20 Oct 2003 03:42:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 11703580027; Mon, 20 Oct 2003 03:42:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4EE58580027 for ; Mon, 20 Oct 2003 03:41:35 -0500 (CDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id B89D158001E for ; Mon, 20 Oct 2003 03:41:33 -0500 (CDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9K8fVd05793 for ; Mon, 20 Oct 2003 11:41:31 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 20 Oct 2003 11:41:31 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 11:41:30 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 11:41:30 +0300 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.6487.1 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3853@esebe023.ntc.nokia.com> Thread-Topic: Proposed resolution of issue 161: State machine demultiplexing Thread-Index: AcOW5fVFVLhs9wA7Q1qDkhvmDzPLNA== From: To: X-OriginalArrivalTime: 20 Oct 2003 08:41:30.0883 (UTC) FILETIME=[F59C1530:01C396E5] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed resolution of issue 161: State machine demultiplexing 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, 20 Oct 2003 11:41:30 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Add to state machine doc, section 2, before the last paragraph: Some environments where EAP is used, such as PPP, may support peer-to-peer operation. That is, both parties act as peers and authenticators at the same time, in two simultaneous and independent EAP conversations. In this case, the lower layer to at each node has to perform demultiplexing of incoming EAP packets.=20 EAP packets with Code set to Response are delivered to the=20 Authenticator state machine, and all other EAP packets are=20 delivered to the Peer state machine. Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 20 14:56: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 OAA07624 for ; Mon, 20 Oct 2003 14:56:04 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 89B47580027; Mon, 20 Oct 2003 13:56:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3C8E580109; Mon, 20 Oct 2003 13:56:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 25FE5580109 for ; Mon, 20 Oct 2003 13:56:01 -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 A07C6580027 for ; Mon, 20 Oct 2003 13:55:59 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9KIJtk01726 for ; Mon, 20 Oct 2003 11:19:55 -0700 From: Bernard Aboba To: eap@frascone.com In-Reply-To: <20031020170003.6282.30877.Mailman@wolverine> Message-ID: References: <20031020170003.6282.30877.Mailman@wolverine> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: resolution to issue 161 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, 20 Oct 2003 11:19:55 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Add to state machine doc, section 2, before the last paragraph: > > Some environments where EAP is used, such as PPP, may support > peer-to-peer operation. That is, both parties act as peers and > authenticators at the same time, in two simultaneous and > independent EAP conversations. In this case, the lower layer to at > each node has to perform demultiplexing of incoming EAP packets. > EAP packets with Code set to Response are delivered to the > Authenticator state machine, and all other EAP packets are > delivered to the Peer state machine. What are the link layer requirements for support of EAP peer-to-peer operation? I ask this because there is nothing in RFC 2248bis Section 2.4 or 3.1 that discusses these requirements. For example, if there a requirement for the link layer to be able to demultiplex the EAP conversations in each direction, wouldn't that imply the need for a field in the link layer header with which to do this demultiplexing? For example, IPv4/IPv6 packets are demultiplexed by different EtherType values, not really by the IP version number. In Section 3.2.1 of RFC 2284bis the PPP Authentication Protocol format is defined. EAP packets are encapsulated with an Authentication Protocol value of C227 (Hex). Similarly, in IEEE 802.1X an Ethertype is assigned to 802.1X packets. Neither of these encapsulations can demultiplex EAP conversations occurring in different directions. For example, there is no different Authentication Protocol value or Ethertype for this. Since neither of these encapsulations demultiplexes EAP conversations in either direction, and the link layer does not look at frames deeper in the packet, such as the EAP Code or Type fields, I don't think that this explanation can be correct. If there is demultiplexing, then this would need to occur in the EAP layer, not in the link layer, no? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 20 15:09: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 PAA11183 for ; Mon, 20 Oct 2003 15:09:02 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E6BA3580027; Mon, 20 Oct 2003 14:09:06 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7724158010A; Mon, 20 Oct 2003 14:09:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90DCF58010A for ; Mon, 20 Oct 2003 14:09:00 -0500 (CDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 1D717580027 for ; Mon, 20 Oct 2003 14:08:59 -0500 (CDT) Subject: Re: [eap] Re: resolution to issue 161 From: Alper Yegin To: Bernard Aboba , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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: Mon, 20 Oct 2003 12:08:53 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit >> Add to state machine doc, section 2, before the last paragraph: >> >> Some environments where EAP is used, such as PPP, may support >> peer-to-peer operation. That is, both parties act as peers and >> authenticators at the same time, in two simultaneous and >> independent EAP conversations. In this case, the lower layer to at >> each node has to perform demultiplexing of incoming EAP packets. >> EAP packets with Code set to Response are delivered to the >> Authenticator state machine, and all other EAP packets are >> delivered to the Peer state machine. > > What are the link layer requirements for support of EAP peer-to-peer > operation? I ask this because there is nothing in RFC 2248bis Section > 2.4 or 3.1 that discusses these requirements. > > For example, if there a requirement for the link layer to be able to > demultiplex the EAP conversations in each direction, wouldn't that imply > the need for a field in the link layer header with which to do this > demultiplexing? For example, IPv4/IPv6 packets are demultiplexed by > different EtherType values, not really by the IP version number. > > In Section 3.2.1 of RFC 2284bis the PPP Authentication Protocol format is > defined. EAP packets are encapsulated with an Authentication Protocol > value of C227 (Hex). Similarly, in IEEE 802.1X an Ethertype is assigned > to 802.1X packets. Neither of these encapsulations can demultiplex EAP > conversations occurring in different directions. For example, there is no > different Authentication Protocol value or Ethertype for this. > > Since neither of these encapsulations demultiplexes EAP conversations in > either direction, and the link layer does not look at frames deeper in the > packet, such as the EAP Code or Type fields, I don't think that this > explanation can be correct. If there is demultiplexing, then this would > need to occur in the EAP layer, not in the link layer, no? PANA message type (i.e., request vs. answer) can be used for demultiplexing the payload (EAP message). Alper _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 21 04:50: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 EAA10528 for ; Tue, 21 Oct 2003 04:50:05 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0F5C558001A; Tue, 21 Oct 2003 03:50:10 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 30F0458001E; Tue, 21 Oct 2003 03:50:04 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 75EBD58001E for ; Tue, 21 Oct 2003 03:49:20 -0500 (CDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id E282E58001A for ; Tue, 21 Oct 2003 03:49:18 -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.8) with ESMTP id h9L8nGX06309 for ; Tue, 21 Oct 2003 11:49:17 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 11:49:16 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 21 Oct 2003 11:49:16 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 21 Oct 2003 11:49:16 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 21 Oct 2003 11:49:12 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [eap] Re: resolution to issue 161 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3859@esebe023.ntc.nokia.com> Thread-Topic: [eap] Re: resolution to issue 161 Thread-Index: AcOXPRVmdI2NfXtwTHGJVlOKq3+6DwAcN3yA From: To: , X-OriginalArrivalTime: 21 Oct 2003 08:49:12.0794 (UTC) FILETIME=[3357DBA0:01C397B0] 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: Tue, 21 Oct 2003 11:49:12 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, I agree with you in that the demultiplexing can't (or at least shouldn't) be done at the link layer in e.g. PPP, since it would need to look inside the EAP packets (to check the Code field).=20 More likely it's done by "something" between the link layer and EAP state machines. Would simply changing "lower layer" to "implementation" be sufficient? Best regards, Pasi > -----Original Message----- > From: Bernard Aboba > Sent: Monday, October 20, 2003 9:20 PM > To: eap@frascone.com > Subject: [eap] Re: resolution to issue 161 >=20 > > Add to state machine doc, section 2, before the last paragraph: > > > > Some environments where EAP is used, such as PPP, may support > > peer-to-peer operation. That is, both parties act as peers and > > authenticators at the same time, in two simultaneous and > > independent EAP conversations. In this case, the lower layer to > > at each node has to perform demultiplexing of incoming EAP=20 > > packets. EAP packets with Code set to Response are delivered=20 > > to the Authenticator state machine, and all other EAP packets=20 > > are delivered to the Peer state machine. >=20 > What are the link layer requirements for support of EAP peer-to-peer > operation? I ask this because there is nothing in RFC 2248bis Section > 2.4 or 3.1 that discusses these requirements. >=20 > For example, if there a requirement for the link layer to be > able to demultiplex the EAP conversations in each direction, > wouldn't that imply the need for a field in the link layer > header with which to do this demultiplexing? For example, > IPv4/IPv6 packets are demultiplexed by different EtherType > values, not really by the IP version number. >=20 > In Section 3.2.1 of RFC 2284bis the PPP Authentication > Protocol format is defined. EAP packets are encapsulated with > an Authentication Protocol value of C227 (Hex). Similarly, in > IEEE 802.1X an Ethertype is assigned to 802.1X > packets. Neither of these encapsulations can demultiplex EAP > conversations occurring in different directions. For example, > there is no different Authentication Protocol value or > Ethertype for this. >=20 > Since neither of these encapsulations demultiplexes EAP > conversations in either direction, and the link layer does not > look at frames deeper in the packet, such as the EAP Code or > Type fields, I don't think that this explanation can be > correct. If there is demultiplexing, then this would need to > occur in the EAP layer, not in the link layer, no? >=20 > _______________________________________________ > 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 Oct 21 14:31: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 OAA29486 for ; Tue, 21 Oct 2003 14:31:04 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 25F2F58001A; Tue, 21 Oct 2003 13:31:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 160A558001E; Tue, 21 Oct 2003 13:31:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB5FE58001E for ; Tue, 21 Oct 2003 13:30:30 -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 45B7558001A for ; Tue, 21 Oct 2003 13:30:29 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9LHsD218689; Tue, 21 Oct 2003 10:54:13 -0700 From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: eap@frascone.com Subject: Re: [eap] Re: resolution to issue 161 In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3859@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6010C3859@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Tue, 21 Oct 2003 10:54:13 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I think this is sufficient for the State Machine spec. But I think we may also need to change some text and possibly a figure in RFC 2284bis to make it more clear. For example, if multiplexing occurs on the "Code" field then it implies that an "EAP peer" listener within an EAP implementation will not receive EAP packets with Code=2 (Response) (but packets for all other Codes, including 1, 3, 4). Similarly, the "EAP server" listener will only recieve EAP packets with Code=2 (Request). The implementation behavior therefore differs based on whether there is an "EAP peer" or "EAP server" listener present, or both. This is a bit different than the behavior implied by RFC 2284bis as where it is implied that an "EAP peer" will silently discard a received EAP-Response packet. If there is no "EAP server" listener on the receiving host, or if there is but the EAP method only supports "EAP peer" functionality, then silent discard will occur. However if there is an "EAP server" listener, and an EAP method registered with "EAP server" functionality, then the EAP-Response might be processed. There is therefore some implied multiplexing that occurs based on the Code field, prior to the Type multiplexing which occurs later. This is not shown on the diagrams. On Tue, 21 Oct 2003 Pasi.Eronen@nokia.com wrote: > > Hi, > > I agree with you in that the demultiplexing can't (or at least > shouldn't) be done at the link layer in e.g. PPP, since it would > need to look inside the EAP packets (to check the Code field). > > More likely it's done by "something" between the link layer and > EAP state machines. Would simply changing "lower layer" to > "implementation" be sufficient? > > Best regards, > Pasi > > > -----Original Message----- > > From: Bernard Aboba > > Sent: Monday, October 20, 2003 9:20 PM > > To: eap@frascone.com > > Subject: [eap] Re: resolution to issue 161 > > > > > Add to state machine doc, section 2, before the last paragraph: > > > > > > Some environments where EAP is used, such as PPP, may support > > > peer-to-peer operation. That is, both parties act as peers and > > > authenticators at the same time, in two simultaneous and > > > independent EAP conversations. In this case, the lower layer to > > > at each node has to perform demultiplexing of incoming EAP > > > packets. EAP packets with Code set to Response are delivered > > > to the Authenticator state machine, and all other EAP packets > > > are delivered to the Peer state machine. > > > > What are the link layer requirements for support of EAP peer-to-peer > > operation? I ask this because there is nothing in RFC 2248bis Section > > 2.4 or 3.1 that discusses these requirements. > > > > For example, if there a requirement for the link layer to be > > able to demultiplex the EAP conversations in each direction, > > wouldn't that imply the need for a field in the link layer > > header with which to do this demultiplexing? For example, > > IPv4/IPv6 packets are demultiplexed by different EtherType > > values, not really by the IP version number. > > > > In Section 3.2.1 of RFC 2284bis the PPP Authentication > > Protocol format is defined. EAP packets are encapsulated with > > an Authentication Protocol value of C227 (Hex). Similarly, in > > IEEE 802.1X an Ethertype is assigned to 802.1X > > packets. Neither of these encapsulations can demultiplex EAP > > conversations occurring in different directions. For example, > > there is no different Authentication Protocol value or > > Ethertype for this. > > > > Since neither of these encapsulations demultiplexes EAP > > conversations in either direction, and the link layer does not > > look at frames deeper in the packet, such as the EAP Code or > > Type fields, I don't think that this explanation can be > > correct. If there is demultiplexing, then this would need to > > occur in the EAP layer, not in the link layer, no? > > > > _______________________________________________ > > 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 Oct 22 10:13:19 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 KAA10682 for ; Wed, 22 Oct 2003 10:13:09 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8441B580112; Wed, 22 Oct 2003 09:13:07 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 06795580027; Wed, 22 Oct 2003 09:13:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BAE14580027 for ; Wed, 22 Oct 2003 09:12:45 -0500 (CDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 9384E58001E for ; Wed, 22 Oct 2003 09:12:42 -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.8) with ESMTP id h9MECaq00129 for ; Wed, 22 Oct 2003 17:12:36 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 22 Oct 2003 17:11:30 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 22 Oct 2003 17:11:28 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 22 Oct 2003 17:11:28 +0300 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.6487.1 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C385C@esebe023.ntc.nokia.com> Thread-Topic: Update for issue 183 (Security Associations) Thread-Index: AcOYpmKE24pE2CtSTpindbfmyUBo3Q== From: To: X-OriginalArrivalTime: 22 Oct 2003 14:11:28.0350 (UTC) FILETIME=[62A54FE0:01C398A6] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Update for issue 183 (Security Associations) 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, 22 Oct 2003 17:11:28 +0300 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, We had a lively discussion about the SAs and naming at the interim meeting. It seems the SA description text I sent last week was missing (at least) one SA, and thus we had severe difficulties in naming it :-) Would something like this do? 3.3 EAP key distribution SA This is an SA between the peer and backend authentication server, and it allows them to derive keys to be delivered to authenticators. Current implementations do not actually store this SA after the EAP conversation is over, but future implementations could use this for things such as pre-emptive key distribution. Contains o Name/identifier for this SA o Identities of the parties o EMSK (or some other keys known only to the peer and=20 backend authentication server) o Other yet-unspecified information=20 =20 Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 22 14:37: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 OAA21314 for ; Wed, 22 Oct 2003 14:37:02 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B65B2580014; Wed, 22 Oct 2003 13:37:07 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F272A58001E; Wed, 22 Oct 2003 13:37:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E5476580023 for ; Wed, 22 Oct 2003 13:36:33 -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 7D2D6580014 for ; Wed, 22 Oct 2003 13:36:32 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9MI0Hl05092 for ; Wed, 22 Oct 2003 11:00: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] Preliminary agenda for EAP WG at IETF 58 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, 22 Oct 2003 11:00:17 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Additions, deletions, changes welcome. ----------------------------------------------------- Extensible Authentication Protocol (eap) WG Chair(s): Bernard Aboba Jari Arkko Monday, November 10, 2003 1930 - 2200 Preliminaries (10 minutes) Agenda Bashing Bluesheets Minutes Document Status EAP State Machine (20 minutes), TBD http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.txt Network Selection, Farid Adrangi (10 minutes) http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt EAP Key Framework, Bernard Aboba (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt Roadmap (10 minutes), WG Chairs and ADs _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 23 14:03:53 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 OAA09713 for ; Thu, 23 Oct 2003 14:03:18 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5227E580013; Thu, 23 Oct 2003 13:03:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 951C3580014; Thu, 23 Oct 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 050DE580014 for ; Thu, 23 Oct 2003 13:02:18 -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 06020580013 for ; Thu, 23 Oct 2003 13:02:16 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9NHPt121835 for ; Thu, 23 Oct 2003 10:25:55 -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] Re: proposed resolution to Issue 161 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, 23 Oct 2003 10:25:55 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I went through RFC 2284bis and tried to identify sections affected by the proposed resolution to Issue 161 within the State Machine document. I believe this affects Sections 2.2-2.4. Here are proposed revisions of those sections to address this issue: 2.2 EAP multiplexing model Conceptually, EAP implementations consist of the following components: [a] Lower layer. The lower layer is responsible for transmitting and receiving EAP frames between the peer and authenticator. EAP has been run over a variety of lower layers including PPP; wired IEEE 802 LANs [IEEE-802.1X]; IEEE 802.11 wireless LANs [IEEE-802.11]; UDP (L2TP [RFC2661] and IKEv2 [IKEv2]); and TCP [PIC]. Lower layer behavior is discussed in Section 3. [b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and from the EAP peer and authenticator layers. [c] EAP peer and authenticator layers. Based on the code field, the EAP layer demultiplexes incoming EAP packets to the EAP peer and authenticator layers. It is possible for a host to act as both EAP peer and authenticator, and in this case both EAP peer and authenticator listeners will be present. [d] EAP method layers. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP peer and authenticator layers. Since fragmentation support is not provided by EAP itself, this is the responsibility of EAP methods, which are discussed in Section 5. The EAP multiplexing model is illustrated in Figure 1 below. Note that there is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it. +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | EAP method| EAP method| | EAP method| EAP method| | Type = X | Type = Y | | Type = X | Type = Y | | V | | | ^ | | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! Peer layer | | EAP ! Auth. layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! layer | | EAP ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | Lower ! layer | | Lower ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ ! ! ! Peer ! Authenticator +------------>-------------+ Figure 1: EAP Multiplexing Model Within EAP, the Code field is used much like a protocol number in IP. It is assumed that the EAP layer multiplexes incoming EAP packets according to the Code field. Received EAP packets with Code=1 (Request), 3 (Success) and 4 (Failure) are delivered by the EAP layer to the EAP peer listener, if present. EAP packets with Code=2 (Response) are delivered to the EAP authenticator listener, if present. Within EAP, the Type field functions much like a port number in UDP or TCP. It is assumed that the EAP peer and authenticator layers multiplex incoming EAP packets according to their Type, and deliver them only to the EAP method corresponding to that Type code. Since EAP authentication methods may wish to access the Identity, implementations SHOULD make the Identity Request and Response accessible to authentication methods (Types 4 or greater) in addition to the Identity method. The Identity Type is discussed in Section 5.1. A Notification Response is only used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. It cannot be assumed that the contents of the Notification Request or Response is available to another method. The Notification Type is discussed in Section 5.2. Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes of method negotiation. Peers respond to an initial EAP Request for an unacceptable Type with a Nak Response (Type 3) or Expanded Nak Response (Type 254). It cannot be assumed that the contents of the Nak Response(s) are available to another method. The Nak Type(s) are discussed in Section 5.3. EAP packets with codes of Success or Failure do not include a Type field, and are not delivered to an EAP method. Success and Failure are discussed in Section 4.2. Given these considerations, the Success, Failure, Nak Response(s) and Notification Request/Response messages MUST NOT be used to carry data destined for delivery to other EAP methods. 2.3 Pass-through behavior Where an authenticator operates as a pass-through, it forwards packets back and forth between the peer and a backend authentication server, based on the EAP layer header fields (Code, Identifier, Length). This includes performing checks on the Code, Identifier and Length fields, as described in Section 4.1. Since pass-through authenticators rely on a backend authenticator server to implement methods, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision, except where the authenticator implements one or more authentication methods locally. In this case, the pass-through authenticator may examine the Type field to determine whether to handle the packet itself or forward it. The forwarding model is illustrated in Figure 2. Compliant pass-through authenticator implementations MUST by default be capable of forwarding EAP packets from any EAP method. Pass-through authenticator implementations also MUST be capable of forwarding Response (Code=2) packets to the backend authentication server, and receiving EAP Request (Code=1), Success (Code=3) and Failure (Code=4) packets from the backend authentication server. Where the pass-through device implements an EAP peer listener, it MAY choose not to forward EAP Request (Code=1), Success (Code=3) or Failure (Code=4) packets to the backend authentication server, in order to handle these locally. The use of the RADIUS protocol for encapsulation of EAP in pass-through operation is described in [RFC3579]. Peer Pass-through Authenticator Authentication Server +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | V | | ^ | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | | | | | ! | |EAP ! peer| | EAP peer | EAP Auth. | |EAP !Auth.| | ! | | | | | ! | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | | | | | ! | |EAP !layer| | EAP layer | EAP layer | |EAP !layer| | ! | | +-----+-----+ | | ! | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |Lower!layer| |Lower!layer| AAA ! /IP | | AAA ! /IP | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ ! ! ! ! ! ! ! ! +-------->-----+ +------->------+ Figure 2: Pass-through Authenticator For sessions in which the authenticator acts as a pass-through, it MUST determine the outcome of the authentication solely based on the Accept/Reject indication sent by the backend authentication server; the outcome MUST NOT be determined by the contents of an EAP packet sent along with the Accept/Reject indication, or the absence of such an encapsulated EAP packet. 2.4 Peer-to-Peer Operation Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction (depending on the capabilities of the lower layer). Both peers may act as authenticators and authenticatees at the same time; in this case it is necessary to both peers to implement both EAP authenticator and peer listeners. Although EAP supports peer-to-peer operation, selected EAP methods, AAA protocols and link layers may not support this. For example, EAP-TLS [RFC2716] is a client-server protocol requiring a different certificate profile for the client and server. This implies that a host supporting both the EAP-TLS peer and authenticator roles would need to be provisioned with two distinct certificates, one appropriate for each role. Some EAP methods may support asymmetric authentication, with one type of credential being required for the peer and another type for the authenticator. Hosts supporting peer-to-peer operation with such a method would need to be provisioned with both types of credentials. AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM-EAP] only support "passthrough" operation on behalf of an authenticator, not a peer. As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access-Request encapsulating an EAP-Request with an Access-Reject. Link layers such as IEEE 802.11 may only support uni-directional derivation and transport of transient session keys. For example, the group-key handshake defined in [IEEE-802.11i] is uni-directional, since in IEEE 802.11 only the Access Point (AP) sends multicast traffic. This means that in ad-hoc operation where either peer may send multicast traffic, two uni-directional group-key exchanges are required. Due to constraints imposed by the 4-way unicast key handshake state machine, this also implies two 4-way handshake and EAP method exchanges. Link layers such as IEEE 802.11 adhoc also do not support "tie breaking" wherein two hosts initiating authentication with each other will only go forward with a single authentication. This implies that even if 802.11 were to support a bi-directional group-key handshake, then two authentications, one in each direction, might still occur. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 23 14:29: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 OAA11184 for ; Thu, 23 Oct 2003 14:29:01 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B956580013; Thu, 23 Oct 2003 13:29:08 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D6E1A580017; Thu, 23 Oct 2003 13:29:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 378EA580017 for ; Thu, 23 Oct 2003 13:28:58 -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 6FCDB580013 for ; Thu, 23 Oct 2003 13:28:56 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9NHqaG23361 for ; Thu, 23 Oct 2003 10:52: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] Proposed Resolution to Issue 183 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, 23 Oct 2003 10:52:35 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Here is the proposed Resolution to Issue 183, which involves adding new sections 3-3.4. I'd like to split off the discussion of Service SAs into a separate issue, and will post a proposed resolution to that in a separate mail. Proposed fix: Replace Sections 3, 3.1 and 3.2 with the following: 3. Security Associations EAP key management involves five types of security associations (SAs): [1] EAP SA. This is an SA between the peer and EAP server, which allows them to authenticate each other. [2] EAP method SA. This SA is also between the peer and EAP server. It stores state that can be used for "fast resume" or other functionality in some EAP methods. Not all EAP methods create such an SA. [3] EAP-Key SA. This is an SA between the peer and EAP server, which is used to store the keying material exported by the EAP method. Current EAP server implementations do not retain this SA after the EAP conversation completes, but future implementations could use this SA for pre-emptive key distribution. [4] AAA SA(s). These SAs are between the authenticator and the backend authentication server. They permit the parties to mutually authenticate each other and protect the communications between them. [5] Service SA(s). These SAs are between the peer and authenticator, and they are created as a result of phases 1-2 of the conversation (see Section 1.3). Service SA(s) are required for the derivation of transient session keys (TSKs) as well as for the transmission of unicast and multicast data traffic. 3.1 EAP SA (peer - EAP server) In order for the peer and EAP server to authenticate each other, they need to store some information. The authentication can be based on different mechanisms, such as shared secrets or certificates. If the authentication is based on a shared secret key, the parties store the EAP method to be used and the key. The EAP server also stores the peer's identity and/or other information necessary to decide whether access to some service should be granted. The peer stores information necessary to choose which secret to use for which service. 3.2 EAP method SA (peer - EAP server) An EAP method may store some state on the peer and EAP server even after phase 1a has completed. Typically, this is used for "fast resume": the peer and EAP server can confirm that they are still talking to the same party, perhaps using fewer roundtrips or less computational power. In this case, the EAP method SA is essentially a cache for performance optimization, and either party may remove the SA from its cache at any point. An EAP method may also keep state in order to support pseudonym-based identity protection. This is typically a cache as well (the information can be recreated if the original EAP method SA is lost), but may be stored for longer periods of time. The EAP method SA is not restricted to a particular service or authenticator and is most useful when the peer accesses many different authenticators. An EAP method is responsible for specifying how the parties select if an existing EAP method SA should be used, and if so, which one. Where multiple backend authentication servers are used, EAP method SAs are not typically synchronized between them. EAP method implementations should consider the appropriate lifetime for the EAP method SA. "Fast resume" assumes that the information required (primarily the keys in the EAP method SA) hasn't been compromised. In case the original authentication was carried out using, for instance, a smart card, it may be easier to compromise the EAP method SA (stored on the PC, for instance), so typically the EAP method SAs have a limited lifetime. Contents: o Implicitly, the EAP method this SA refers to o One or more internal (non-exported) keys o EAP method SA name o SA lifetime 3.2.1 Example: EAP-TLS In EAP-TLS [RFC2716], after the EAP authentication the client (peer) and server can store the following information: o Implicitly, the EAP method this SA refers to (EAP-TLS) o Session identifier (a value selected by the server) o Certificate of the other party (server stores the clients's certificate and vice versa) o Ciphersuite and compression method o TLS Master secret (known as the EAP-TLS Master Key or MK) o SA lifetime (ensuring that the SA is not stored forever) o If the client has multiple different credentials (certificates and corresponding private keys), a pointer to those credentials When the server initiates EAP-TLS, the client can look up the EAP-TLS SA based on the credentials it was going to use (certificate and private key), and the expected credentials (certificate or name) of the server. If an EAP-TLS SA exists, and it is not too old, the client informs the server about the existence of this SA by including its Session-Id in the TLS ClientHello message. The server then looks up the correct SA based on the Session-Id (or detects that it doesn't yet have one). 3.2.2 Example: EAP-AKA In EAP-AKA [AKA], after EAP authentication the client and server can store the following information: o Implicitly, the EAP method this SA refers to (EAP-AKA) o A re-authentication pseudonym o The client's permanent identity (IMSI) (server) o Replay protection counter o Authentication key (K_aut) o Encryption key (K_encr) o Original Master Key (MK) o SA lifetime (ensuring that the SA is not stored forever) When the server initiates EAP-AKA, the client can look up the EAP-AKA SA based on the credentials it was going to use (permanent identity). If an EAP-AKA SA exists, and it is not too old, the client informs the server about the existence of this SA by sending its re-authentication pseudonym as its identity in EAP Identity Response message, instead of its permanent identity. The server then looks up the correct SA based on this identity. 3.3 EAP-key SA This is an SA between the peer and EAP server, which is used to store the keying material exported by the EAP method. Current EAP server implementations do not retain this SA after the EAP conversation completes, but future implementations could use this SA for pre-emptive key distribution. Contents: o Name/identifier for this SA o Identities of the parties o MSK and EMSK 3.4 AAA SA(s) (authenticator - backend authentication server) In order for the authenticator and backend authentication server to authenticate each other, they need to store some information. In case the authenticator and backend authentication server are colocated, and they communicate using local procedure calls or shared memory, this SA need not necessarily contain any information. 3.4.1 Example: RADIUS In RADIUS, where shared secret authentication is used, the client and server store each other's IP address and the shared secret, which is used to calculate the Response Authenticator [RFC2865] and Message-Authenticator [RFC3579] values, and to encrypt some attributes (such as the AAA-Key [RFC2548]). Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for key management, the parties store information necessary to authenticate and authorize the other party (e.g. certificates, trust anchors and names). The IKE exchange results in IKE Phase 1 and Phase 2 SAs containing information used to protect the conversation (session keys, selected ciphersuite, etc.) 3.4.2 Example: Diameter with TLS When using Diameter protected by TLS, the parties store information necessary to authenticate and authorize the other party (e.g. certificates, trust anchors and names). The TLS handshake results in a short-term TLS SA that contains information used to protect the actual communications (session keys, selected TLS ciphersuite, etc.). _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 23 17:39: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 RAA20146 for ; Thu, 23 Oct 2003 17:39:01 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9BAA6580023; Thu, 23 Oct 2003 16:39:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2BC6C580018; Thu, 23 Oct 2003 16:39:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B6D35580018 for ; Thu, 23 Oct 2003 16:38:45 -0500 (CDT) Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91]) by mail.frascone.com (Postfix) with ESMTP id 8D04D580017 for ; Thu, 23 Oct 2003 16:38:44 -0500 (CDT) Received: from PascalUrien.libertysurf.fr (212.83.177.62) by mail.libertysurf.net (6.5.026) id 3F84F5FF0034C58C for eap@frascone.com; Thu, 23 Oct 2003 23:38:43 +0200 Message-Id: <5.1.0.14.0.20031023233255.00b4b868@pop.libertysurf.fr> X-Sender: puri0003_1_lsurf@pop.libertysurf.fr (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: eap@frascone.com From: Pascal Urien In-Reply-To: <20031023170003.4157.44069.Mailman@wolverine> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: eap digest, Vol 1 #441 - 1 msg 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, 23 Oct 2003 23:38:28 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Everybody New version of IETF draft "eap support in smartcard" is available at, http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-03.txt I suggest to present its status, Monday, November 10, 2003 Pascal At 12:00 23/10/2003 -0500, you wrote: >Send eap mailing list submissions to > eap@frascone.com > >To subscribe or unsubscribe via the World Wide Web, visit > http://mail.frascone.com/mailman/listinfo/eap >or, via email, send a message with subject or body 'help' to > eap-request@frascone.com > >You can reach the person managing the list at > eap-admin@frascone.com > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of eap digest..." > > >Today's Topics: > > 1. Preliminary agenda for EAP WG at IETF 58 (Bernard Aboba) > >--__--__-- > >Message: 1 >Date: Wed, 22 Oct 2003 11:00:17 -0700 (PDT) >From: Bernard Aboba >To: eap@frascone.com >Subject: [eap] Preliminary agenda for EAP WG at IETF 58 > >Additions, deletions, changes welcome. > >----------------------------------------------------- >Extensible Authentication Protocol (eap) WG > >Chair(s): >Bernard Aboba >Jari Arkko > >Monday, November 10, 2003 >1930 - 2200 > >Preliminaries (10 minutes) > Agenda Bashing > Bluesheets > Minutes > Document Status > >EAP State Machine (20 minutes), TBD >http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf >http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.txt > >Network Selection, Farid Adrangi (10 minutes) >http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt > >EAP Key Framework, Bernard Aboba (20 minutes) >http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt > >Roadmap (10 minutes), WG Chairs and ADs > > >--__--__-- > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap > > >End of eap Digest _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 24 21:54:30 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 VAA09026 for ; Fri, 24 Oct 2003 21:54:08 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C6EF580014; Fri, 24 Oct 2003 20:54:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 07657580018; Fri, 24 Oct 2003 20:54:03 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34EFE580018 for ; Fri, 24 Oct 2003 20:53:49 -0500 (CDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id B5C7B580014 for ; Fri, 24 Oct 2003 20:53:47 -0500 (CDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h9P1sJ46009272 for ; Sat, 25 Oct 2003 01:54:19 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h9P1ltU16322 for ; Sat, 25 Oct 2003 01:47:55 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 M2003102418533421996 ; Fri, 24 Oct 2003 18:53:34 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Oct 2003 18:53:34 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: A few comments on draft-puthenkulam-eap-binding-03.txt Thread-Index: AcN7Z0T+07RZqLRDSPyn7alBgGL1VQfMCQRw From: "Puthenkulam, Jose P" To: "DongGook Park" Cc: "EAP mailing list" X-OriginalArrivalTime: 25 Oct 2003 01:53:34.0686 (UTC) FILETIME=[CCB98FE0:01C39A9A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: 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: Fri, 24 Oct 2003 18:53:34 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dear DongGook Park, Apologies for not being able to respond to you sooner: Here are some responses on your comments. > 1. [Comment] On page 15, the draft describes the Binding=20 > Phase Exchange > with compound keyed MACs. The draft reads "... The validation of the > compound protects against the MITM attack, as the attacker is=20 > 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=20 > protocol (not > as an inner protocol of the tunneled authentication protocol)=20 > which does > not include the additional Binding Phase exchange.=20 >=20 If an additional message exchange without any crypto binding was added, it would not protect from an attacker that can actually also replicate the expected additional message exchange. So the cryptographic binding performed to compute the MAC is critical for it to work. > 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=20 > explain why > it is the case, but rather they only emphasize the importance=20 > of "Stage > 1" countermeasure and the insufficiency of "Stage 2" being=20 > used alone... > I think, rather, readers would expect why the additional=20 > 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=20 > 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=20 > 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. I agree with you on this one partially, from pure protection view point. But from a practical implementation viewpoint, typically policy decisions for authorization are made after a successful authentication. So when a late detection occurs due to decrypt operations failing, it relies on some upper layer to detect such a failure, which is sometimes hard. While an early detection allows authorizations to be not provided at all and early error handling in terms of an unsuccessful authentication. >=20 > 3. [Question] On page 17, Section 3.5 "Solution approaches",=20 > the first > proposed approach for accommodation of Stage 1 or 2 (the=20 > 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=20 > need to have > something like EAP-BindingPhaseExchange in addition to e.g. EAP-TTLS?=20 Yes, but as one of the EAP types within EAP itself like Identity or Notification etc. >=20 > 4. [Question] On page 13, Section 3.2 "Solution Concepts", the > description headed by "[S1]" argues that cryptographic=20 > 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=20 > 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? One could do this if the password is accessible to the key binding process. But at first glance developing a general solution may not be easy. However as you have raised it, I would like to think more about any possibilities here :) Thanks for reviewing the draft. Really appreciate your comments, best regards, jose ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jose Puthenkulam=20 Staff Network Architect=20 Communications Technology Lab=20 Intel R & D=20 Intel Corporation=20 2111 NE 25th Avenue, JF2-58=20 Hillsboro, OR 97124=20 Tel: (503) 264 6121=20 Fax: (503) 264 8154=20 Email: jose.p.puthenkulam@intel.com=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=20 > -----Original Message----- > From: DongGook Park [mailto:dgpark6@kt.co.kr]=20 > Sent: Monday, September 15, 2003 1:56 AM > To: Puthenkulam, Jose P > Cc: EAP mailing list > Subject: A few comments on draft-puthenkulam-eap-binding-03.txt >=20 >=20 > Dear Jose Puthenkulam, >=20 > I have some comments and questions with regard to your recent=20 > IETF draft > entitled " The Compound Authentication Binding Problem" > (draft-puthenkulam-eap-binding-03.txt), which you can find=20 > below in this > mail.=20 >=20 > Best regards, > DongGook Park >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Information Security Research Division > Korea Telecom > 17 WooMyeon-Dong SeoCho-Gu Seoul 137-792=20 > Korea, South > =20 > Telephone: +82 2 526 6173 > Email: dgpark6@kt.co.kr > Homepage: http://home.naver.com/dgpark6/ > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 > ###### A few comments on=20 > draft-puthenkulam-eap-binding-03.txt ####### >=20 > This draft describes MITM attacks against tunneled authentication > protocols, and proposes some countermeasures. I've found a bit > misleading descriptions from the draft: >=20 > 1. [Comment] On page 15, the draft describes the Binding=20 > Phase Exchange > with compound keyed MACs. The draft reads "... The validation of the > compound protects against the MITM attack, as the attacker is=20 > 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=20 > protocol (not > as an inner protocol of the tunneled authentication protocol)=20 > which does > not include the additional Binding Phase exchange.=20 >=20 > 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=20 > explain why > it is the case, but rather they only emphasize the importance=20 > of "Stage > 1" countermeasure and the insufficiency of "Stage 2" being=20 > used alone... > I think, rather, readers would expect why the additional=20 > 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=20 > 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=20 > 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. >=20 > 3. [Question] On page 17, Section 3.5 "Solution approaches",=20 > the first > proposed approach for accommodation of Stage 1 or 2 (the=20 > 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=20 > need to have > something like EAP-BindingPhaseExchange in addition to e.g. EAP-TTLS?=20 >=20 > 4. [Question] On page 13, Section 3.2 "Solution Concepts", the > description headed by "[S1]" argues that cryptographic=20 > 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=20 > 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? >=20 >=20 >=20 >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 24 22:01:02 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 WAA09220 for ; Fri, 24 Oct 2003 22:00:59 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3048F580014; Fri, 24 Oct 2003 21:01:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9AF67580018; Fri, 24 Oct 2003 21:01:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BFA63580018 for ; Fri, 24 Oct 2003 21:00:11 -0500 (CDT) Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id 3B2C0580014 for ; Fri, 24 Oct 2003 21:00:10 -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.6p3/8.11.6) with ESMTP id h9P21mb09050 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 24 Oct 2003 22:03: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 h9P1smfJ001974 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 24 Oct 2003 21:55:06 -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 h9OMEM3m027946; Fri, 24 Oct 2003 18:15:22 -0400 To: Pasi.Eronen@nokia.com Cc: eap@frascone.com Subject: Re: [eap] Issue: New text about conversation phases In-reply-to: Your message of "Wed, 15 Oct 2003 02:02:43 +0300." <052E0C61B69C3741AFA5FE88ACC775A6010C384C@esebe023.ntc.nokia.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <27945.1067033662@marajade.sandelman.ottawa.on.ca> From: Michael Richardson 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: Fri, 24 Oct 2003 18:14:22 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pasi" == Pasi Eronen writes: Pasi> o Phase 1b is also very similar. Although no "RADIUS guidelines for Pasi> IKEv2" document exists yet, RADIUS could be used with very small Pasi> modifications (perhaps a new value for Service-Type and agreement Pasi> about what to put in Calling-Station-Id/Called-Station-Id Pasi> attributes). have you read draft-ietf-ipsec-dhcp-over-ike-radius-00.txt? ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | 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 iQCVAwUBP5mkPYqHRg3pndX9AQHsIgQAkWSgq1p77WuGboReAET2DV6Iii+dbCMK Ctz0Hxwc73ZviVp0AeRoQXdnJcTIEpiAY1dpBLTdG/L5C2+r60Rm/EMacd+/55OI u3hQ16YQFnlHLv7tq5ebNY7gnpXQfUJhvNwMDTnCHFWvwULCMdY3Hxy+I22M4tYr H2mWa4CTV2Y= =P8Ph -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Oct 25 10:17:54 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 KAA06684 for ; Sat, 25 Oct 2003 10:17:10 -0400 (EDT) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38C6B58001D; Sat, 25 Oct 2003 09:17:09 -0500 (CDT) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3B92580018; Sat, 25 Oct 2003 09:17:02 -0500 (CDT) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09AFE580018 for ; Sat, 25 Oct 2003 09:16:07 -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 EB957580014 for ; Sat, 25 Oct 2003 09:16:04 -0500 (CDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9PDdXU12806 for ; Sat, 25 Oct 2003 06:39:34 -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] Re: proposed resolution to Issue 161 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, 25 Oct 2003 06:39:33 -0700 (PDT) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Here is a revision that hopefully addresses Nick's issue... 2.2 EAP multiplexing model Conceptually, EAP implementations consist of the following components: [a] Lower layer. The lower layer is responsible for transmitting and receiving EAP frames between the peer and authenticator. EAP has been run over a variety of lower layers including PPP; wired IEEE 802 LANs [IEEE-802.1X]; IEEE 802.11 wireless LANs [IEEE-802.11]; UDP (L2TP [RFC2661] and IKEv2 [IKEv2]); and TCP [PIC]. Lower layer behavior is discussed in Section 3. [b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and from the EAP peer and authenticator layers. [c] EAP peer and authenticator layers. Based on the Code field, the EAP layer demultiplexes incoming EAP packets to the EAP peer and authenticator layers. It is possible for a host to act as both EAP peer and authenticator, and in this case both EAP peer and authenticator layers will be present. [d] EAP method layers. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP peer and authenticator layers. Since fragmentation support is not provided by EAP itself, this is the responsibility of EAP methods, which are discussed in Section 5. The EAP multiplexing model is illustrated in Figure 1 below. Note that there is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it. +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | EAP method| EAP method| | EAP method| EAP method| | Type = X | Type = Y | | Type = X | Type = Y | | V | | | ^ | | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! Peer layer | | EAP ! Auth. layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! layer | | EAP ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | Lower ! layer | | Lower ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ ! ! ! Peer ! Authenticator +------------>-------------+ Figure 1: EAP Multiplexing Model Within EAP, the Code field is used much like a protocol number in IP. It is assumed that the EAP layer demultiplexes incoming EAP packets according to the Code field. Received EAP packets with Code=1 (Request), 3 (Success) and 4 (Failure) are delivered by the EAP layer to the EAP peer listener, if present. EAP packets with Code=2 (Response) are delivered to the EAP authenticator listener, if present. Within EAP, the Type field functions much like a port number in UDP or TCP. It is assumed that the EAP peer and authenticator layers demultiplex incoming EAP packets according to their Type, and deliver them only to the EAP method corresponding to that Type. Since EAP authentication methods may wish to access the Identity, implementations SHOULD make the Identity Request and Response accessible to authentication methods (Types 4 or greater) in addition to the Identity method. The Identity Type is discussed in Section 5.1. A Notification Response is only used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. It cannot be assumed that the contents of the Notification Request or Response is available to another method. The Notification Type is discussed in Section 5.2. Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes of method negotiation. Peers respond to an initial EAP Request for an unacceptable Type with a Nak Response (Type 3) or Expanded Nak Response (Type 254). It cannot be assumed that the contents of the Nak Response(s) are available to another method. The Nak Type(s) are discussed in Section 5.3. EAP packets with codes of Success or Failure do not include a Type field, and are not delivered to an EAP method. Success and Failure are discussed in Section 4.2. Given these considerations, the Success, Failure, Nak Response(s) and Notification Request/Response messages MUST NOT be used to carry data destined for delivery to other EAP methods. 2.3 Pass-through behavior Where an authenticator operates as a pass-through, it forwards packets back and forth between the peer and a backend authentication server, based on the EAP layer header fields (Code, Identifier, Length). This includes performing checks on the Code, Identifier and Length fields, as described in Section 4.1. Since pass-through authenticators rely on a backend authenticator server to implement methods, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision, except where the authenticator implements one or more authentication methods locally. In this case, the authenticator may examine the Type field to determine whether to act on the packet itself or forward it. The forwarding model is illustrated in Figure 2. Compliant pass-through authenticator implementations MUST by default forward EAP packets of any Type. Pass-through authenticator implementations MUST support forwarding Response (Code=2) packets to the backend authentication server, and receiving EAP Request (Code=1), Success (Code=3) and Failure (Code=4) packets from the backend authentication server. Implementations MAY be capable of forwarding Request (Code=1), Success (Code=3) and Failure (Code=4) packets to the backend authentication server, and receiving EAP Response (Code=2) packets from the backend authentication server. Where the pass-through device implements an EAP peer listener, it will not forward to the backend authentication server EAP Request (Code=1), Success (Code=3) or Failure (Code=4) packets in order to act on them locally. The use of the RADIUS protocol for encapsulation of EAP in pass-through operation is described in [RFC3579]. Peer Pass-through Authenticator Authentication Server +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | V | | ^ | +-+-+-!-+-+-+ +-+-+-!-+-+-+ | ! | | ! | |EAP ! peer| |EAP !Auth.| | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | | | | | ! | |EAP !layer| | EAP layer | EAP layer | |EAP !layer| | ! | | +-----+-----+ | | ! | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |Lower!layer| |Lower!layer| AAA ! /IP | | AAA ! /IP | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ ! ! ! ! ! ! ! ! +-------->-----+ +------->------+ Figure 2: Pass-through Authenticator For sessions in which the authenticator acts as a pass-through, it MUST determine the outcome of the authentication solely based on the Accept/Reject indication sent by the backend authentication server; the outcome MUST NOT be determined by the contents of an EAP packet sent along with the Accept/Reject indication, or the absence of such an encapsulated EAP packet. 2.4 Peer-to-Peer Operation Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction (depending on the capabilities of the lower layer). Both peers may act as authenticators and authenticatees at the same time; in this case it is necessary to both peers to implement both EAP authenticator and peer listeners. Although EAP supports peer-to-peer operation, selected EAP methods, AAA protocols and link layers may not support this. For example, EAP-TLS [RFC2716] is a client-server protocol requiring a different certificate profile for the client and server. This implies that a host supporting both the EAP-TLS peer and authenticator roles would need to be provisioned with two distinct certificates, one appropriate for each role. Some EAP methods may support asymmetric authentication, with one type of credential being required for the peer and another type for the authenticator. Hosts supporting peer-to-peer operation with such a method would need to be provisioned with both types of credentials. AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM-EAP] only support "passthrough" operation on behalf of an authenticator, not a peer. As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access-Request encapsulating an EAP-Request with an Access-Reject. Link layers such as IEEE 802.11 may only support uni-directional derivation and transport of transient session keys. For example, the group-key handshake defined in [IEEE-802.11i] is uni-directional, since in IEEE 802.11 only the Access Point (AP) sends multicast traffic. This means that in ad-hoc operation where either peer may send multicast traffic, two uni-directional group-key exchanges are required. Due to constraints imposed by the 4-way unicast key handshake state machine, this also implies two 4-way handshake and EAP method exchanges. Link layers such as IEEE 802.11 adhoc also do not support "tie breaking" wherein two hosts initiating authentication with each other will only go forward with a single authentication. This implies that even if 802.11 were to support a bi-directional group-key handshake, then two authentications, one in each direction, might still occur. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Oct 26 10:08: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 KAA19069 for ; Sun, 26 Oct 2003 10:08:04 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 11E3D580012; Sun, 26 Oct 2003 09:08:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D374580014; Sun, 26 Oct 2003 09:08:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 57E5F580014 for ; Sun, 26 Oct 2003 09:07:57 -0600 (CST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id E5807580012 for ; Sun, 26 Oct 2003 09:07:55 -0600 (CST) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h9QF8eSN013285 for ; Sun, 26 Oct 2003 15:08:40 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h9QF0YD08398 for ; Sun, 26 Oct 2003 15:00:34 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003102607074110623 for ; Sun, 26 Oct 2003 07:07:41 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 26 Oct 2003 07:07:41 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39BD2.E6D0D92E" Subject: [eap] RFC2284bis-06 draft: Support for sequences X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [eap] RFC2284bis-06 draft: Support for sequences Thread-Index: AcOb0uWlwUgXJN6WQyWpY2VIIEYWAA== From: "Puthenkulam, Jose P" To: "EAP mailing list" Cc: "Adrangi, Farid" , "Lortz, Victor" X-OriginalArrivalTime: 26 Oct 2003 15:07:41.0701 (UTC) FILETIME=[E6F8D350:01C39BD2] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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: Sun, 26 Oct 2003 07:07:41 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C39BD2.E6D0D92E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 After reading the latest RFC2284bis (http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.txt), the following para does not seem to be clear. =20 See section 2.1 Support for Sequences : para 2 reproduced below: =20 "Once a peer has sent a Response of the same Type as the initial Request, an authenticator MUST NOT send a Request of a different Type prior to completion of the final round of a given method (with the exception of a Notification-Request) and MUST NOT send a Request for an additional method of any Type after completion of the initial authentication method; a peer receiving such Requests MUST treat them as invalid, and silently discard them. As a result, Identity Requery is not supported." 1. In this text "MUST NOT send a Request for an additional method of any Type after completion of the initial authentication method;"=20 =20 shouldn't it say "before completion of the initial authentication method" =20 2. When we say "As a result, Identity Requery is not supported",=20 =20 does it imply that two successive Identity requests cannot be issued by the Authenticator? =20 =20 Any clarifications will be helpful, =20 best regards, jose =20 =20 ------_=_NextPart_001_01C39BD2.E6D0D92E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 All,
 
After = reading the=20 latest RFC2284bis (http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.txt= ),=20 the following para does not seem to be clear.
 
See = section 2.1=20 Support for Sequences : para 2 reproduced below:
 
   "Once a peer = has sent a=20 Response of the same Type as the initial
   Request, an=20 authenticator MUST NOT send a Request of a different = Type
   prior=20 to completion of the final round of a given method (with = the
  =20 exception of a Notification-Request) and MUST NOT send a Request=20 for
   an additional method of any Type after completion of = the=20 initial
   authentication method; a peer receiving such = Requests=20 MUST treat them
   as invalid, and silently discard them. = As a=20 result, Identity Requery
   is not supported."
1. In this text=20 "MUST NOT send a Request = for  an=20 additional method of any Type after completion of the initial =20 authentication method;" 
 
    shouldn't = it say "before=20 completion of the initial authentication = method"
 
2. = When we say=20 "As a result, Identity = Requery is not=20 supported",
 
   does it imply that two = successive=20 Identity requests cannot be issued by the=20 Authenticator?
 
 
Any = clarifications=20 will be helpful,
 
best=20 regards,
jose
 
 
=00 ------_=_NextPart_001_01C39BD2.E6D0D92E-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Oct 26 11:00: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 LAA20657 for ; Sun, 26 Oct 2003 11:00:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D9EF580014; Sun, 26 Oct 2003 10:00:11 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3A24580016; Sun, 26 Oct 2003 10:00:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF442580016 for ; Sun, 26 Oct 2003 09:59:09 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id C8004580014 for ; Sun, 26 Oct 2003 09:59:08 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4A9C36A902; Sun, 26 Oct 2003 17:59:06 +0200 (EET) Message-ID: <3F9BEE53.4050507@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: "Puthenkulam, Jose P" Cc: EAP mailing list , "Adrangi, Farid" , "Lortz, Victor" Subject: Re: [eap] RFC2284bis-06 draft: Support for sequences References: In-Reply-To: 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: Sun, 26 Oct 2003 17:54:59 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Puthenkulam, Jose P wrote: > Section 2.1 Support for Sequences : para 2 reproduced below: > > "Once a peer has sent a Response of the same Type as the initial > Request, an authenticator MUST NOT send a Request of a different Type > prior to completion of the final round of a given method (with the > exception of a Notification-Request) and MUST NOT send a Request for > an additional method of any Type after completion of the initial > authentication method; a peer receiving such Requests MUST treat them > as invalid, and silently discard them. As a result, Identity Requery > is not supported." > 1. In this text "MUST NOT send a Request for an additional method of > any Type after completion of the initial authentication method;" > > shouldn't it say "before completion of the initial authentication > method" Hmm... I had to reread the text multiple times and I agree its complicated. But it does appear to say what was decided: *during* a method you can't send any other method, except maybe Notification. And *after* the first _auth_ method you can't send any method at all, period. > 2. When we say "As a result, Identity Requery is not supported", > > does it imply that two successive Identity requests cannot be issued > by the Authenticator? I think it means that you can't do Id - Method - Id but you can still do Id - Id - Method. Or am I missing something? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Oct 26 11:20:53 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 LAA21041 for ; Sun, 26 Oct 2003 11:20:12 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E9AB9580016; Sun, 26 Oct 2003 10:20:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D964580018; Sun, 26 Oct 2003 10:20:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0236E580018 for ; Sun, 26 Oct 2003 10:19:05 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 42A28580016 for ; Sun, 26 Oct 2003 10:19:03 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D4F446A902; Sun, 26 Oct 2003 18:19:01 +0200 (EET) Message-ID: <3F9BF2FE.9090304@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: Pasi.Eronen@nokia.com, eap@frascone.com Subject: Re: [eap] Re: resolution to issue 161 References: <052E0C61B69C3741AFA5FE88ACC775A6010C3859@esebe023.ntc.nokia.com> In-Reply-To: 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: Sun, 26 Oct 2003 18:14:54 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > I think this is sufficient for the State Machine spec. But I think we may Agreed. > also need to change some text and possibly a figure in RFC 2284bis to > make it more clear. > > For example, if multiplexing occurs on the "Code" field then it implies > that an "EAP peer" listener within an EAP implementation will not receive > EAP packets with Code=2 (Response) (but packets for all other Codes, > including 1, 3, 4). Similarly, the "EAP server" listener will only > recieve EAP packets with Code=2 (Request). The implementation behavior > therefore differs based on whether there is an "EAP peer" or "EAP server" > listener present, or both. Right. I'm happy with your proposed text from yesterday. Some comments inline though: > 2.2 EAP multiplexing model > > Conceptually, EAP implementations consist of the following > components: > > [a] Lower layer. The lower layer is responsible for transmitting and > receiving EAP frames between the peer and authenticator. EAP has > been run over a variety of lower layers including PPP; wired IEEE > 802 LANs [IEEE-802.1X]; IEEE 802.11 wireless LANs [IEEE-802.11]; > UDP (L2TP [RFC2661] and IKEv2 [IKEv2]); and TCP [PIC]. Lower > layer behavior is discussed in Section 3. > > [b] EAP layer. The EAP layer receives and transmits EAP packets via > the lower layer, implements duplicate detection and > retransmission, and delivers and receives EAP messages to and > from the EAP peer and authenticator layers. > > [c] EAP peer and authenticator layers. Based on the Code field, the > EAP layer demultiplexes incoming EAP packets to the EAP peer and > authenticator layers. It is possible for a host to act as both > EAP peer and authenticator, and in this case both EAP peer and > authenticator layers will be present. > > [d] EAP method layers. EAP methods implement the authentication > algorithms and receive and transmit EAP messages via the EAP peer > and authenticator layers. Since fragmentation support is not > provided by EAP itself, this is the responsibility of EAP methods, > which are discussed in Section 5. > > The EAP multiplexing model is illustrated in Figure 1 below. Note > that there is no requirement that an implementation conform to this > model, as long as the on-the-wire behavior is consistent with it. > > > +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ > | | | | | | > | EAP method| EAP method| | EAP method| EAP method| > | Type = X | Type = Y | | Type = X | Type = Y | > | V | | | ^ | | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > | ! | | ! | > | EAP ! Peer layer | | EAP ! Auth. layer | > | ! | | ! | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > | ! | | ! | > | EAP ! layer | | EAP ! layer | > | ! | | ! | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > | ! | | ! | > | Lower ! layer | | Lower ! layer | > | ! | | ! | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > ! ! > ! Peer ! Authenticator > +------------>-------------+ > > Figure 1: EAP Multiplexing Model > > Within EAP, the Code field is used much like a protocol number in > IP. It is assumed that the EAP layer demultiplexes incoming EAP > packets according to the Code field. Received EAP packets > with Code=1 (Request), 3 (Success) and 4 (Failure) are > delivered by the EAP layer to the EAP peer listener, if > present. EAP packets with Code=2 (Response) are delivered > to the EAP authenticator listener, if present. Since the EAP peer/auth listener terms are used in the below text a number of times, do we need a definition for them? > Within EAP, the Type field functions much like a port number in UDP > or TCP. It is assumed that the EAP peer and authenticator layers > demultiplex incoming EAP packets according to their Type, and deliver > them only to the EAP method corresponding to that Type. > > Since EAP authentication methods may wish to access the Identity, > implementations SHOULD make the Identity Request and Response > accessible to authentication methods (Types 4 or greater) in addition > to the Identity method. The Identity Type is discussed in Section > 5.1. > > A Notification Response is only used as confirmation that the peer > received the Notification Request, not that it has processed it, or > displayed the message to the user. It cannot be assumed that the > contents of the Notification Request or Response is available to > another method. The Notification Type is discussed in Section 5.2. > > Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes > of method negotiation. Peers respond to an initial EAP Request for > an unacceptable Type with a Nak Response (Type 3) or Expanded Nak > Response (Type 254). It cannot be assumed that the contents of the > Nak Response(s) are available to another method. The Nak Type(s) are > discussed in Section 5.3. > > EAP packets with codes of Success or Failure do not include a Type > field, and are not delivered to an EAP method. Success and Failure are > discussed in Section 4.2. > > Given these considerations, the Success, Failure, Nak Response(s) and > Notification Request/Response messages MUST NOT be used to carry data > destined for delivery to other EAP methods. > > 2.3 Pass-through behavior > > Where an authenticator operates as a pass-through, it forwards > packets back and forth between the peer and a backend authentication > server, based on the EAP layer header fields (Code, Identifier, > Length). This includes performing checks on the Code, > Identifier and Length fields, as described in Section 4.1. > > Since pass-through authenticators rely on a backend authenticator > server to implement methods, the EAP method layer header fields > (Type, Type-Data) are not examined as part of the forwarding > decision, except where the authenticator implements one or more > authentication methods locally. In this case, the authenticator > may examine the Type field to determine whether to act on the > packet itself or forward it. > > The forwarding model is illustrated in Figure 2. Compliant > pass-through authenticator implementations MUST by default > forward EAP packets of any Type. Pass-through authenticator > implementations MUST support forwarding Response (Code=2) > packets to the backend authentication server, and receiving > EAP Request (Code=1), Success (Code=3) and Failure (Code=4) packets > from the backend authentication server. Implementations MAY be > capable of forwarding Request (Code=1), Success (Code=3) and > Failure (Code=4) packets to the backend authentication server, and > receiving EAP Response (Code=2) packets from the backend authentication > server. > > Where the pass-through device implements an EAP peer listener, > it will not forward to the backend authentication server > EAP Request (Code=1), Success (Code=3) or Failure (Code=4) > packets in order to act on them locally. The use of the > RADIUS protocol for encapsulation of EAP in pass-through > operation is described in [RFC3579]. I had to read the above paragraph a few times to understand what you are saying. So this is an EAP peer-side passthrough? Or an EAP passthrough authenticator with an EAP peer side to the other direction? Anyway, I don't have any change request. Except maybe that talking about peer-side passthroughs and RFC 3579 in the same paragraph may be misleading, given that it only supports authenticator side passthrough. At least break the last sentence into its own paragraph. > > Peer Pass-through Authenticator Authentication > Server > > +-+-+-+-+-+-+ +-+-+-+-+-+-+ > | | | | > |EAP method | |EAP method | > | V | | ^ | > +-+-+-!-+-+-+ +-+-+-!-+-+-+ > | ! | | ! | > |EAP ! peer| |EAP !Auth.| > | ! | | ! | > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > | ! | | | | | ! | > |EAP !layer| | EAP layer | EAP layer | |EAP !layer| > | ! | | +-----+-----+ | | ! | > | ! | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ > | ! | | ! | ! | | ! | > |Lower!layer| |Lower!layer| AAA ! /IP | | AAA ! /IP | > | ! | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ > ! ! ! ! > ! ! ! ! > +-------->-----+ +------->------+ > > Figure 2: Pass-through Authenticator > > For sessions in which the authenticator acts as a pass-through, it > MUST determine the outcome of the authentication solely based on the > Accept/Reject indication sent by the backend authentication server; > the outcome MUST NOT be determined by the contents of an EAP packet > sent along with the Accept/Reject indication, or the absence of such > an encapsulated EAP packet. > > 2.4 Peer-to-Peer Operation > > Since EAP is a peer-to-peer protocol, an independent and simultaneous > authentication may take place in the reverse direction (depending on > the capabilities of the lower layer). Both peers may act as > authenticators and authenticatees at the same time; in this case it > is necessary to both peers to implement both EAP authenticator and > peer listeners. > > Although EAP supports peer-to-peer operation, selected EAP methods, > AAA protocols and link layers may not support this. For example, > EAP-TLS [RFC2716] is a client-server protocol requiring a different > certificate profile for the client and server. This implies that a > host supporting both the EAP-TLS peer and authenticator roles would > need to be provisioned with two distinct certificates, one > appropriate for each role. > > Some EAP methods may support asymmetric authentication, with one type > of credential being required for the peer and another type for the > authenticator. Hosts supporting peer-to-peer operation with such a > method would need to be provisioned with both types of credentials. Maybe put the EAP-TLS after this paragraph? > AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP > [DIAM-EAP] only support "passthrough" operation on behalf of an > authenticator, not a peer. As noted in [RFC3579] Section > 2.6.2, a RADIUS server responds to an Access-Request encapsulating an > EAP-Request with an Access-Reject. > > Link layers such as IEEE 802.11 may only support uni-directional > derivation and transport of transient session keys. For example, the > group-key handshake defined in [IEEE-802.11i] is uni-directional, > since in IEEE 802.11 only the Access Point (AP) sends multicast > traffic. This means that in ad-hoc operation where either peer may > send multicast traffic, two uni-directional group-key exchanges are > required. Due to constraints imposed by the 4-way unicast key > handshake state machine, this also implies two 4-way handshake and > EAP method exchanges. > > Link layers such as IEEE 802.11 adhoc also do not support "tie > breaking" wherein two hosts initiating authentication with each other > will only go forward with a single authentication. This implies that > even if 802.11 were to support a bi-directional group-key handshake, > then two authentications, one in each direction, might still occur. Otherwise your text looks very good. THanks! --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Oct 26 11:39:02 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 LAA21339 for ; Sun, 26 Oct 2003 11:38:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3765D580027; Sun, 26 Oct 2003 10:39:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7954258001C; Sun, 26 Oct 2003 10:39:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFB0458001C for ; Sun, 26 Oct 2003 10:38:53 -0600 (CST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 97BEC580018 for ; Sun, 26 Oct 2003 10:38:52 -0600 (CST) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h9QGdaSN006568 for ; Sun, 26 Oct 2003 16:39:36 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h9QGX9E01214 for ; Sun, 26 Oct 2003 16:33:09 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 M2003102608384910325 ; Sun, 26 Oct 2003 08:38:49 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 26 Oct 2003 08:38:49 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] RFC2284bis-06 draft: Support for sequences Message-ID: Thread-Topic: [eap] RFC2284bis-06 draft: Support for sequences Thread-Index: AcOb2hlFPEid8OuPQamPs2CbofblmwABCkLg From: "Puthenkulam, Jose P" To: Cc: "EAP mailing list" , "Adrangi, Farid" , "Lortz, Victor" X-OriginalArrivalTime: 26 Oct 2003 16:38:49.0644 (UTC) FILETIME=[A21EB6C0:01C39BDF] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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: Sun, 26 Oct 2003 08:38:49 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Jari, See comments below > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Sunday, October 26, 2003 7:55 AM > To: Puthenkulam, Jose P > Cc: EAP mailing list; Adrangi, Farid; Lortz, Victor > Subject: Re: [eap] RFC2284bis-06 draft: Support for sequences >=20 >=20 > Puthenkulam, Jose P wrote: >=20 > > Section 2.1 Support for Sequences : para 2 reproduced below: > > =20 > > "Once a peer has sent a Response of the same Type as the initial > > Request, an authenticator MUST NOT send a Request of a=20 > different Type > > prior to completion of the final round of a given method=20 > (with the > > exception of a Notification-Request) and MUST NOT send a=20 > Request for > > an additional method of any Type after completion of the initial > > authentication method; a peer receiving such Requests=20 > MUST treat them > > as invalid, and silently discard them. As a result,=20 > Identity Requery > > is not supported." > > 1. In this text "MUST NOT send a Request for an additional=20 > method of=20 > > any Type after completion of the initial authentication method;"=20 > > =20 > > shouldn't it say "before completion of the initial=20 > authentication=20 > > method" >=20 > Hmm... I had to reread the text multiple times and I agree=20 > its complicated. > But it does appear to say what was decided: *during* a method=20 > you can't send > any other method, except maybe Notification. And *after* the=20 > first _auth_ method > you can't send any method at all, period. >=20 Same here, it confused me too. I agree with the principle of not supporting open ended sequences, however the mixed use of the word "method" which includes Identity Type method and "authentication method" which excludes it, seems to complicate the interpretation. > > 2. When we say "As a result, Identity Requery is not supported", > > =20 > > does it imply that two successive Identity requests=20 > cannot be issued=20 > > by the Authenticator? >=20 > I think it means that you can't do Id - Method - Id but you can still > do Id - Id - Method. Or am I missing something? It would help, if we made this interpretation explicit. As you point out, already in section 5.1 in the Implementation Note, it does support Id-Id-Method. >=20 > --Jari >=20 thanks, jose=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Oct 26 20:01: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 UAA06795 for ; Sun, 26 Oct 2003 20:01:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2978D58001D; Sun, 26 Oct 2003 19:01:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB863580016; Sun, 26 Oct 2003 19:01:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4553F580016 for ; Sun, 26 Oct 2003 19:00:05 -0600 (CST) Received: from filter1.kt.co.kr (unknown [147.6.42.145]) by mail.frascone.com (Postfix) with ESMTP id 9AAF9580012 for ; Sun, 26 Oct 2003 19:00:02 -0600 (CST) Received: from external ([147.6.9.133]) by filter1 (1.0) id h9R0v4I33975; Mon, 27 Oct 2003 09:57:04 +0900 From: "DongGook Park" To: Cc: "EAP mailing list" Message-ID: <001e01c39c25$a0798f70$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 In-Reply-To: <20031026180003.1401.57295.Mailman@wolverine> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: RE: 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, 27 Oct 2003 09:59:51 +0900 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dear Jose, Thanks for your response and answers. >> 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. >> > If an additional message exchange without any crypto binding was added, > it would not protect from an attacker that can actually also replicate > the expected additional message exchange. So the cryptographic binding > performed to compute the MAC is critical for it to work. I might sound rather splitting hairs... Of course, there is no need to say that the additional message "with" the cryptographic binding is a must for the countermeasure to succeed. What I mean may be rather subtle. Think about that, in the MITM attack, the attacker was "able" to derive a cryptographic response from the victim user in spite of "not" being able to access the required key. In other words, we have the following two observations: 1) The attacker does "not" know the key; but he is able to get the necessary message to play the MITM attack (of course in the case of the original situation not fixed) 2) The attacker does "not" know the key; and hence he is not able to get the necessary message to complete the attack. I think, at this point, you have unmistakably read me... >> 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. > I agree with you on this one partially, from pure protection view point. > But from a practical implementation viewpoint, typically policy > decisions for authorization are made after a successful authentication. > So when a late detection occurs due to decrypt operations failing, it > relies on some upper layer to detect such a failure, which is sometimes > hard. While an early detection allows authorizations to be not provided > at all and early error handling in terms of an unsuccessful > authentication. I couldn't agree more! But I think you hit me wrong. :-) What I meant is that you are expected to give a specific explanation why the implicit countermeasure (Stage 2 as in the draft) is needed on top of the more explicit countermeasure (Sage 1 as in the draft). Best regards, DongGook _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 27 01:16:55 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 BAA14540 for ; Mon, 27 Oct 2003 01:16:14 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3C9DB580010; Mon, 27 Oct 2003 00:16:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35B38580016; Mon, 27 Oct 2003 00:16:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92E7B580016 for ; Mon, 27 Oct 2003 00:15:04 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6F33A580010 for ; Mon, 27 Oct 2003 00:15:02 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9R5cPJ07928 for ; Sun, 26 Oct 2003 21:38:25 -0800 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] Re: proposed resolution to Issue 161 -- Take Three 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, 26 Oct 2003 21:38:24 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Nick -- Thought about this a bit more. Given that the Code field allows the EAP layer to demultiplex packets destined to an authenticator versus peer listener, a "pass-through authenticator" will only receive EAP packets destined for the authenticator listener, that is, packets with Code=2 (Response). Unless the NAS also has a peer listener, it will silently discard packets with other Code values. Since RADIUS and Diameter do not support a "pass-through peer", there is no way in practice that EAP packets of Codes other than 2 can be forwarded to the backend authentication server. Here is another pass at the text in an attempt to get this straight. Bernard 2.2 EAP multiplexing model Conceptually, EAP implementations consist of the following components: [a] Lower layer. The lower layer is responsible for transmitting and receiving EAP frames between the peer and authenticator. EAP has been run over a variety of lower layers including PPP; wired IEEE 802 LANs [IEEE-802.1X]; IEEE 802.11 wireless LANs [IEEE-802.11]; UDP (L2TP [RFC2661] and IKEv2 [IKEv2]); and TCP [PIC]. Lower layer behavior is discussed in Section 3. [b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and from the EAP peer and authenticator layers. [c] EAP peer and authenticator layers. Based on the Code field, the EAP layer demultiplexes incoming EAP packets to the EAP peer and authenticator layers. Typically an EAP implementation on a given host will support either peer or authenticator functionality, but it is possible for a host to act as both an EAP peer and authenticator. In such an implementation both EAP peer and authenticator layers will be present. [d] EAP method layers. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP peer and authenticator layers. Since fragmentation support is not provided by EAP itself, this is the responsibility of EAP methods, which are discussed in Section 5. The EAP multiplexing model is illustrated in Figure 1 below. Note that there is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it. +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | EAP method| EAP method| | EAP method| EAP method| | Type = X | Type = Y | | Type = X | Type = Y | | V | | | ^ | | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! Peer layer | | EAP ! Auth. layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! layer | | EAP ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | Lower ! layer | | Lower ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ ! ! ! Peer ! Authenticator +------------>-------------+ Figure 1: EAP Multiplexing Model Within EAP, the Code field functions much like a protocol number in IP. It is assumed that the EAP layer demultiplexes incoming EAP packets according to the Code field. Received EAP packets with Code=1 (Request), 3 (Success) and 4 (Failure) are delivered by the EAP layer to the EAP peer listener, if present. EAP packets with Code=2 (Response) are delivered to the EAP authenticator listener, if present. Within EAP, the Type field functions much like a port number in UDP or TCP. It is assumed that the EAP peer and authenticator layers demultiplex incoming EAP packets according to their Type, and deliver them only to the EAP method corresponding to that Type. An EAP method implementation on a host may register to receive packets from the peer or authenticator listener, or both. Since EAP authentication methods may wish to access the Identity, implementations SHOULD make the Identity Request and Response accessible to authentication methods (Types 4 or greater) in addition to the Identity method. The Identity Type is discussed in Section 5.1. A Notification Response is only used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. It cannot be assumed that the contents of the Notification Request or Response is available to another method. The Notification Type is discussed in Section 5.2. Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes of method negotiation. Peers respond to an initial EAP Request for an unacceptable Type with a Nak Response (Type 3) or Expanded Nak Response (Type 254). It cannot be assumed that the contents of the Nak Response(s) are available to another method. The Nak Type(s) are discussed in Section 5.3. EAP packets with codes of Success or Failure do not include a Type field, and are not delivered to an EAP method. Success and Failure are discussed in Section 4.2. Given these considerations, the Success, Failure, Nak Response(s) and Notification Request/Response messages MUST NOT be used to carry data destined for delivery to other EAP methods. 2.3 Pass-through behavior Where operating as a "pass-through authenticator" an authenticator forwards EAP packets destined to its authenticator listener to the backend authentication server, and forwards packets received from the backend authentication server to the peer. The forwarding decision is based on examination of the Code, Identifier and Length fields. Since a "pass-through authenticator" only forwards EAP packets destined for its authenticator listener, pass-through authenticator implementations MUST forward Response (Code=2) packets to the backend authentication server. They also MUST be capable of receiving and forwarding to the peer Request (Code=1), Success (Code=3) and Failure (Code=4) packets. Since pass-through authenticators rely on a backend authenticator server to implement methods, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision, except where the authenticator implements one or more authentication methods locally. In this case, the authenticator may examine the Type field to determine whether to act on the packet itself or forward it. The forwarding model is illustrated in Figure 2. Compliant pass-through authenticator implementations MUST by default forward EAP packets of any Type. Since EAP packets received with Code=1 (Request), Code=3 (Success), and Code=4 (Failure) are demultiplexed by the EAP layer and delivered to the peer listener, unless a NAS implements an EAP peer listener, these packets will be silently discarded. Since the behavior of a "pass-through peer" is undefined, where an EAP peer listener is implemented, the NAS will typically act on these packets locally. The use of the RADIUS protocol for encapsulation of EAP in pass-through operation is described in [RFC3579]. Peer Pass-through Authenticator Authentication Server +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | V | | ^ | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | | | | | ! | | ! | |EAP Auth. | EAP Auth. | | ! | |EAP ! peer| | +-----------+ | |EAP !Auth.| | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |EAP !layer| |EAP !layer| EAP !layer| |EAP !layer| | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |Lower!layer| |Lower!layer| AAA ! /IP | | AAA ! /IP | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ ! ! ! ! ! ! ! ! +-------->-----+ +------->------+ Figure 2: Pass-through Authenticator For sessions in which the authenticator acts as a pass-through, it MUST determine the outcome of the authentication solely based on the Accept/Reject indication sent by the backend authentication server; the outcome MUST NOT be determined by the contents of an EAP packet sent along with the Accept/Reject indication, or the absence of such an encapsulated EAP packet. 2.4 Peer-to-Peer Operation Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction (depending on the capabilities of the lower layer). Both peers may act as authenticators and authenticatees at the same time; in this case it is necessary to both peers to implement both EAP authenticator and peer listeners. In addition, the EAP method implementations on both peers must support both authenticator and peer functionality. Although EAP supports peer-to-peer operation, some EAP implementations, methods, AAA protocols and link layers may not support this. For example, EAP-TLS [RFC2716] is a client-server protocol requiring a different certificate profile for the client and server. This implies that a host supporting both the EAP-TLS peer and authenticator roles would need to implement both peer and authenticator listeners; would need to support both the peer and authenticator roles in the EAP-TLS implementation; would need to be provisioned with two distinct certificates, one appropriate for each role. Some EAP methods may support asymmetric authentication, with one type of credential being required for the peer and another type for the authenticator. Hosts supporting peer-to-peer operation with such a method would need to be provisioned with both types of credentials. AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM-EAP] only support "passthrough authenticator" operation. As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access-Request encapsulating an EAP-Request, Success or Failure packet with an Access-Reject. There is therefore no support for "passthrough peer" operation. Link layers such as IEEE 802.11 may only support uni-directional derivation and transport of transient session keys. For example, the group-key handshake defined in [IEEE-802.11i] is uni-directional, since in IEEE 802.11 only the Access Point (AP) sends multicast traffic. This means that in ad-hoc operation where either peer may send multicast traffic, two uni-directional group-key exchanges are required. Due to constraints imposed by the 4-way unicast key handshake state machine, this also implies two 4-way handshake and EAP method exchanges. Link layers such as IEEE 802.11 adhoc also do not support "tie breaking" wherein two hosts initiating authentication with each other will only go forward with a single authentication. This implies that even if 802.11 were to support a bi-directional group-key handshake, then two authentications, one in each direction, might still occur. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 27 01:54:02 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 BAA15538 for ; Mon, 27 Oct 2003 01:54:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF1A858001C; Mon, 27 Oct 2003 00:54:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C7E0580018; Mon, 27 Oct 2003 00:54:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D055580018 for ; Mon, 27 Oct 2003 00:53:32 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 2A7B8580010 for ; Mon, 27 Oct 2003 00:53:31 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9R6Grp10204 for ; Sun, 26 Oct 2003 22:16:53 -0800 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] Strawman agenda for EAP WG at IETF 58 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, 26 Oct 2003 22:16:53 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Extensible Authentication Protocol (eap) WG Chair(s): Bernard Aboba Jari Arkko Monday, November 10, 2003 1930 - 2200 Preliminaries (10 minutes) Agenda Bashing Bluesheets Minutes Document Status EAP State Machine (20 minutes), TBD http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.txt Network Selection, Farid Adrangi (10 minutes) http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt EAP Key Framework, Bernard Aboba (40 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-00.txt EAP SIM/AKA, TBD (10 minutes) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-11.txt http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-10.txt PEAP, Joe Salowey (10 minutes) http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-07.txt EAP Smartcard, Pascal Urien (10 minutes) http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-03.txt Roadmap (10 minutes), WG Chairs and ADs _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 27 04:39: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 EAA03565 for ; Mon, 27 Oct 2003 04:39:06 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 493B5580010; Mon, 27 Oct 2003 03:39:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B90B580016; Mon, 27 Oct 2003 03:39:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A87B580016 for ; Mon, 27 Oct 2003 03:38:15 -0600 (CST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id C3B30580010 for ; Mon, 27 Oct 2003 03:38:13 -0600 (CST) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h9R9cxDw004796 for ; Mon, 27 Oct 2003 09:38:59 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h9R9WUp15349 for ; Mon, 27 Oct 2003 09:32:30 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003102701381123188 ; Mon, 27 Oct 2003 01:38:11 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 27 Oct 2003 01:38:11 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] RE: RE: A few comments on draft-puthenkulam-eap-binding-03.txt Message-ID: Thread-Topic: [eap] RE: RE: A few comments on draft-puthenkulam-eap-binding-03.txt Thread-Index: AcOcJeD8bwnzsYH1QpKnB5zvD0X+hQACxndQ From: "Puthenkulam, Jose P" To: "DongGook Park" , Cc: "EAP mailing list" X-OriginalArrivalTime: 27 Oct 2003 09:38:11.0058 (UTC) FILETIME=[0929DD20:01C39C6E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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: Mon, 27 Oct 2003 01:38:10 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Dear DongGook, Thanks for further clarifying. See responses below. > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]=20 > On Behalf Of DongGook Park > Sent: Sunday, October 26, 2003 5:00 PM > To: eap@frascone.com > Cc: EAP mailing list > Subject: [eap] RE: RE: A few comments on=20 > draft-puthenkulam-eap-binding-03.txt >=20 >=20 > Dear Jose, >=20 > Thanks for your response and answers.=20 >=20 > >> 1. [Comment] On page 15, the draft describes the Binding=20 > >> Phase Exchange > >> with compound keyed MACs. The draft reads "... The=20 > validation of the > >> compound protects against the MITM attack, as the attacker is=20 > >> unable to > >> get any of the inner method keys. ..." This description=20 > 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=20 > method keys, > >> but because the new additional message exchange of=20 > "Binding Phase" is > >> not expected message from the viewpoint of the victim=20 > entity. For the > >> victim entity has simply executed a legacy authentication=20 > >> protocol (not > >> as an inner protocol of the tunneled authentication protocol)=20 > >> which does > >> not include the additional Binding Phase exchange.=20 > >>=20 >=20 > > If an additional message exchange without any crypto binding was > added, > > it would not protect from an attacker that can actually=20 > also replicate > > the expected additional message exchange. So the=20 > cryptographic binding > > performed to compute the MAC is critical for it to work. >=20 > I might sound rather splitting hairs... Of course, there is=20 > no need to > say that the additional message "with" the cryptographic binding is a > must for the countermeasure to succeed. What I mean may be rather > subtle. Think about that, in the MITM attack, the attacker=20 > was "able" to > derive a cryptographic response from the victim user in spite of "not" > being able to access the required key. In other words, we have the > following two observations: >=20 > 1) The attacker does "not" know the key; but he is able to get the > necessary message to play the MITM attack (of course in the=20 > case of the > original situation not fixed) So this is the attack success case. >=20 > 2) The attacker does "not" know the key; and hence he is not=20 > able to get > the necessary message to complete the attack. So this is the attack failure case. >=20 > I think, at this point, you have unmistakably read me...=20 One can always say that one does not need to know the key for the attack to succeed or fail. But at the sametime, one could say that the attack can be made to fail if one does know the keys (inner method keys). So we rely on this reliable test of key knowledge to prove that an (a) attack never occurred or when there is no proof that (b) an attack might have occurred or is possible to occur. (a) is needed to consider the compound authentication to be secure (b) essentially says that the compound authentication is not secure as a attack possbility exists without really asserting that a successful attack is a certainty every single time. >=20 >=20 > >> 2. [Comment] On page 18, before the start of Section 3,4, the > authors > >> argue that "Stage 2" is REQUIRED for additional protection=20 > on top of > >> "Stage 1" protection. Strangely, however, the draft does not=20 > >> explain why > >> it is the case, but rather they only emphasize the importance=20 > >> of "Stage > >> 1" countermeasure and the insufficiency of "Stage 2" being=20 > >> used alone... > >> I think, rather, readers would expect why the additional=20 > >> 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=20 > >> Stage 1 as far > >> as the man-in-the-middle attack is concerned. IMHO, each=20 > stage can be > >> considered as a selective countermeasure; Stage 1 as a=20 > >> 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. >=20 > > I agree with you on this one partially, from pure protection view > point. > > But from a practical implementation viewpoint, typically policy > > decisions for authorization are made after a successful > authentication. > > So when a late detection occurs due to decrypt operations=20 > failing, it > > relies on some upper layer to detect such a failure, which is > sometimes > > hard. While an early detection allows authorizations to be not > provided > > at all and early error handling in terms of an unsuccessful > > authentication. >=20 > I couldn't agree more! But I think you hit me wrong. :-) What I meant > is that you are expected to give a specific explanation why=20 > the implicit > countermeasure (Stage 2 as in the draft) is needed on top of the more > explicit countermeasure (Sage 1 as in the draft). >=20 Probably I did not address your comments fully :(. I have added the following text to clarify this in the 04 draft. "The main reason for Stage 2 is to allow each tunnel packet privacy protection to also be=20 cryptographically bound to the inner methods it carries."=20 This essentially helps the per tunnel packet authentication to be based on all the methods that were part of the compound authentication. >=20 > Best regards, > DongGook >=20 best regards, jose _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 27 07:46: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 HAA10305 for ; Mon, 27 Oct 2003 07:46:11 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80F3258001A; Mon, 27 Oct 2003 06:46:13 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53AF1580016; Mon, 27 Oct 2003 06:46:08 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 327D2580016 for ; Mon, 27 Oct 2003 06:45:12 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 00324580010 for ; Mon, 27 Oct 2003 06:44:59 -0600 (CST) 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.8) with ESMTP id h9RCiwI15193 for ; Mon, 27 Oct 2003 14:44:58 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 27 Oct 2003 14:44:56 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Oct 2003 14:44:56 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 27 Oct 2003 14:44:55 +0200 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.6487.1 Message-ID: Thread-Topic: New EAP-SIM and EAP-AKA are out Thread-Index: AcOciB9EZwCamf00RIeLmWr+t3zmCQ== From: To: X-OriginalArrivalTime: 27 Oct 2003 12:44:55.0904 (UTC) FILETIME=[1FC5AE00:01C39C88] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] New EAP-SIM and EAP-AKA are out 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, 27 Oct 2003 14:44:54 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hello, We have submitted new versions of EAP-SIM and EAP-AKA=20 (draft-haverinen-pppext-eap-sim-12.txt and = draft-arkko-pppext-eap-aka-11.txt) to the IETF directories. They should be available shortly. The drafts contain some technical changes, but we expect implementations of these versions to be compatible with implementations of older versions. The changes are mostly based on Glen Zorn's review and comments from Pasi Eronen, Tom Porcher, and Michael Richardson. Many thanks to all who have commented and contributed. There are no open issues with the drafts. EAP-SIM version 12: - new behaviour in error cases. Instead of silent discard, explicit = error=20 packets are sent. - new error case: if peer thinks that RANDs are not fresh it sends an error packet to terminate the exchange. - server must use at least two triplets=20 - example packets in Annex A added - Username decoration considerations - NAI realm portion not mandated anymore - clarifications on the cases when the server can re-use triplets and = when it must obtain fresh triplets. Triplets can only be re-used in certain unsuccessful cases. - AT_CHECKCODE removed - new document structure and a lot of editorial improvements EAP-AKA version 11: - new behaviour in error cases. Instead of silent discard, explicit = error=20 packets are sent. - Username decoration considerations - NAI realm portion not mandated anymore - new document structure and a lot of editorial improvements Best regards, Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 27 12:08:19 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 MAA25511 for ; Mon, 27 Oct 2003 12:08:07 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5D6E1580023; Mon, 27 Oct 2003 11:08:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9568E580019; Mon, 27 Oct 2003 11:08:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EFDE9580018 for ; Mon, 27 Oct 2003 11:07:37 -0600 (CST) Received: from dns2.tilab.com (dns2.tilab.com [163.162.42.5]) by mail.frascone.com (Postfix) with ESMTP id 5DAC6580010 for ; Mon, 27 Oct 2003 11:07:36 -0600 (CST) Received: from iowa2k01b.cselt.it ([163.162.242.204]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0HNF00J2YE4KJ5@dns2.cselt.it> for eap@frascone.com; Mon, 27 Oct 2003 18:05:08 +0100 (MET) Received: from iowa2k01b.cselt.it ([163.162.242.204]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Mon, 27 Oct 2003 18:07:34 +0100 Received: from EXC2K05A.cselt.it ([163.162.36.101]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Mon, 27 Oct 2003 18:07:34 +0100 From: Caprella Ettore To: eap@frascone.com, aboba@internaut.com, Jari.Arkko@ericsson.com Message-id: <27023D70F51C384B97C251D89CA4AF9A34AC0B@EXC2K05A.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: normal Priority: normal Thread-Topic: Proposal for key management in 802.11 networks Thread-Index: AcOcrM0XV8n/LBmgQqSL4GykiY1uCw== Content-Class: urn:content-classes:message X-OriginalArrivalTime: 27 Oct 2003 17:07:34.0089 (UTC) FILETIME=[D061E390:01C39CAC] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposal for key management in 802.11 networks 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, 27 Oct 2003 18:07:33 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dear Mr. Chairman, we would like to submit to the EAP working group a proposal for a new key management method, which is based on the generalization of the Diffie-Hellman protocol to multicast groups. We think that this approach could be effective in the context of the IEEE 802.11 networks, in particular for the Ad-Hoc scenario. The Generalized Diffie-Hellman protocol for a closed group has been successfully used and deployed in the context of IP secure multicast; this algorithm allow a set of independent peers to derive a shared secret key using only publicly exchanged data and a private information [1][2][3][4]. Our idea is to use Generalized Diffie-Hellman protocol as a mechanism for deriving the shared WEP key to secure the communications occurring in a 802.11 Network. This algorithm is particularly fitting for small network (like home network or small SOHO network) because it can be easily deployed without using a centralized authentication server. This approach can be also used when the Authentication Server is not directly reachable on the local 802.11 network; for example, this may occur in a MANET scenario, where the topology is subject to unpredictable changes. Of course, the approach also presents some drawbacks; in particular, it may be necessary to exchange several packets to perform a complete key exchange; moreover, the size of the packets could possibly exceed the Maximum Transfer Unit (MTU) for a 802.11 network, especially for networks having a large number of users. The proposed mechanism fits nicely within the 802.1x standard for authentication, and provides an alternative mechanism for WEP key generation. All the authentication methods available within the EAP framework can be used without modification. We are currently working on a prototype implementation to better understand the advantages and limitations of our solution. We know that it is unfeasible to discuss thoroughly this issue in the upcoming IETF Meeting; however, as we plan to attend the meeting, we think that this could be an excellent chance to receive some feedback about this proposal and understand if there could be any interest for this working group. Thanks in advance for your kind attention, -Ettore Caprella -Federico Frosali -Gerardo Lamastra [1] M. Steiner, G. Tsudik and M. Waidner "Diffie-Hellman Key Distribution Extended to Groups" 1996 ACM Conference on Computer and Communications Security, March 1996 http://www.ics.uci.edu/~gts/paps/stw96.ps.gz [2] G. Ateniese, O. Chevassut, D. Hasse, Y. Kim and G. Tsudik "The Design of a Group Key Management API" DARPA DISCEX'2000, January 2000 http://www.ics.uci.edu/~gts/paps/achkt99.ps.gz [3] Y. Kim. A. Perrig and G. Tsudik "Simple and Fault-Tolerant Key Agreement for Dynamic Collaborative Groups" ACM CCS'2000, November 2000, kpt2000.pdf http://www.ics.uci.edu/~gts/paps/kpt2000.pdf [4] D. Wallner, E. Harder, R. Agee "Key Management for Multicast: Issues and Architectures" June 1999, http://www.ietf.org/rfc/rfc2627.txt _______________________________________________ Telecom Italia Lab - Telecom Italia Via G. Reiss Romoli, 274 10148 Torino - ITALY Phone: +39 011 228.6012 Fax: +39 011 228.6360 E-Mail: ettoreelio.caprella@telecomitalia.it ________________________________________________ ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you ==================================================================== _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 27 14:34:02 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 OAA02669 for ; Mon, 27 Oct 2003 14:34:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 59575580010; Mon, 27 Oct 2003 13:34:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5DD3B580018; Mon, 27 Oct 2003 13:34:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B0D5E580010 for ; Mon, 27 Oct 2003 13:33:41 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id D6351580018 for ; Mon, 27 Oct 2003 13:33:39 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9RIuxl22858 for ; Mon, 27 Oct 2003 10:56:59 -0800 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] EAP WG agenda for IETF 58, Take Two 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, 27 Oct 2003 10:56:59 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Extensible Authentication Protocol (eap) WG Chair(s): Bernard Aboba Jari Arkko Monday, November 10, 2003 1930 - 2200 Preliminaries (10 minutes) Agenda Bashing Bluesheets Minutes Document Status RFC 2284bis (10 minutes), Henrik Lefkowetz http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.txt EAP State Machine (20 minutes), TBD http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.txt Network Selection, Farid Adrangi (10 minutes) http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt EAP Key Framework, Bernard Aboba (40 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-00.txt EAP SIM/AKA, TBD (10 minutes) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-11.txt http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-10.txt PEAP, Joe Salowey (10 minutes) http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-07.txt EAP Smartcard, Pascal Urien (10 minutes) http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-03.txt Roadmap (10 minutes), WG Chairs and ADs _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 27 15:24: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 PAA06800 for ; Mon, 27 Oct 2003 15:23:10 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D3F558001C; Mon, 27 Oct 2003 14:23:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8DA79580018; Mon, 27 Oct 2003 14:23:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF60F58001A for ; Mon, 27 Oct 2003 14:22:28 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id D5E58580010 for ; Mon, 27 Oct 2003 14:22:22 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id h9RKMLBf004290; Mon, 27 Oct 2003 15:22:21 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Subject: Re: [eap] Re: proposed resolution to Issue 161 -- Take Three In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Mon, 27 Oct 2003 15:22:21 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Thanks Bernard. I think this makes more sense and I like this more. The diagram I was trying to describe previously looks something like the following, but I am happy with yours as it reads. thanks, nick Peer Pass-through Authenticator Authentication Server +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | V | | ^ | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | |EAP | EAP | | | ! | | ! | |Peer | Auth.| EAP Auth. | | ! | |EAP ! peer| | | +-----------+ | |EAP !Auth.| | ! | | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer| | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ ! ! ! ! ! ! ! ! +-------->--------+ +--------->-------+ On Sun, 26 Oct 2003, Bernard Aboba wrote: > Nick -- > > Thought about this a bit more. Given that the Code field allows the EAP > layer to demultiplex packets destined to an authenticator versus peer > listener, a "pass-through authenticator" will only receive EAP > packets destined for the authenticator listener, that is, packets > with Code=2 (Response). Unless the NAS also has a peer listener, > it will silently discard packets with other Code values. Since > RADIUS and Diameter do not support a "pass-through peer", there > is no way in practice that EAP packets of Codes other than 2 can be > forwarded to the backend authentication server. > > Here is another pass at the text in an attempt to get this straight. > > Bernard > > > 2.2 EAP multiplexing model > > Conceptually, EAP implementations consist of the following > components: > > [a] Lower layer. The lower layer is responsible for transmitting and > receiving EAP frames between the peer and authenticator. EAP has > been run over a variety of lower layers including PPP; wired IEEE > 802 LANs [IEEE-802.1X]; IEEE 802.11 wireless LANs [IEEE-802.11]; > UDP (L2TP [RFC2661] and IKEv2 [IKEv2]); and TCP [PIC]. Lower > layer behavior is discussed in Section 3. > > [b] EAP layer. The EAP layer receives and transmits EAP packets via > the lower layer, implements duplicate detection and > retransmission, and delivers and receives EAP messages to and > from the EAP peer and authenticator layers. > > [c] EAP peer and authenticator layers. Based on the Code field, the > EAP layer demultiplexes incoming EAP packets to the EAP peer and > authenticator layers. Typically an EAP implementation on a given > host will support either peer or authenticator functionality, but > it is possible for a host to act as both an EAP peer and > authenticator. In such an implementation both EAP peer and > authenticator layers will be present. > > [d] EAP method layers. EAP methods implement the authentication > algorithms and receive and transmit EAP messages via the EAP peer > and authenticator layers. Since fragmentation support is not > provided by EAP itself, this is the responsibility of EAP methods, > which are discussed in Section 5. > > The EAP multiplexing model is illustrated in Figure 1 below. Note > that there is no requirement that an implementation conform to this > model, as long as the on-the-wire behavior is consistent with it. > > +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ > | | | | | | > | EAP method| EAP method| | EAP method| EAP method| > | Type = X | Type = Y | | Type = X | Type = Y | > | V | | | ^ | | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > | ! | | ! | > | EAP ! Peer layer | | EAP ! Auth. layer | > | ! | | ! | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > | ! | | ! | > | EAP ! layer | | EAP ! layer | > | ! | | ! | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > | ! | | ! | > | Lower ! layer | | Lower ! layer | > | ! | | ! | > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > ! ! > ! Peer ! Authenticator > +------------>-------------+ > > Figure 1: EAP Multiplexing Model > > Within EAP, the Code field functions much like a protocol number in > IP. It is assumed that the EAP layer demultiplexes incoming EAP > packets according to the Code field. Received EAP packets > with Code=1 (Request), 3 (Success) and 4 (Failure) are > delivered by the EAP layer to the EAP peer listener, if > present. EAP packets with Code=2 (Response) are delivered > to the EAP authenticator listener, if present. > > Within EAP, the Type field functions much like a port number in UDP > or TCP. It is assumed that the EAP peer and authenticator layers > demultiplex incoming EAP packets according to their Type, and deliver > them only to the EAP method corresponding to that Type. An > EAP method implementation on a host may register to receive > packets from the peer or authenticator listener, or both. > > Since EAP authentication methods may wish to access the Identity, > implementations SHOULD make the Identity Request and Response > accessible to authentication methods (Types 4 or greater) in addition > to the Identity method. The Identity Type is discussed in Section > 5.1. > > A Notification Response is only used as confirmation that the peer > received the Notification Request, not that it has processed it, or > displayed the message to the user. It cannot be assumed that the > contents of the Notification Request or Response is available to > another method. The Notification Type is discussed in Section 5.2. > > Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes > of method negotiation. Peers respond to an initial EAP Request for > an unacceptable Type with a Nak Response (Type 3) or Expanded Nak > Response (Type 254). It cannot be assumed that the contents of the > Nak Response(s) are available to another method. The Nak Type(s) are > discussed in Section 5.3. > > EAP packets with codes of Success or Failure do not include a Type > field, and are not delivered to an EAP method. Success and Failure are > discussed in Section 4.2. > > Given these considerations, the Success, Failure, Nak Response(s) and > Notification Request/Response messages MUST NOT be used to carry data > destined for delivery to other EAP methods. > > 2.3 Pass-through behavior > > Where operating as a "pass-through authenticator" an > authenticator forwards EAP packets destined to its authenticator > listener to the backend authentication server, and forwards > packets received from the backend authentication server to the > peer. > > The forwarding decision is based on examination of the > Code, Identifier and Length fields. Since a "pass-through > authenticator" only forwards EAP packets destined for its > authenticator listener, pass-through authenticator > implementations MUST forward Response (Code=2) packets > to the backend authentication server. They also MUST be > capable of receiving and forwarding to the peer Request > (Code=1), Success (Code=3) and Failure (Code=4) packets. > > Since pass-through authenticators rely on a backend authenticator > server to implement methods, the EAP method layer header fields > (Type, Type-Data) are not examined as part of the forwarding > decision, except where the authenticator implements one or more > authentication methods locally. In this case, the authenticator > may examine the Type field to determine whether to act on the > packet itself or forward it. > > The forwarding model is illustrated in Figure 2. Compliant > pass-through authenticator implementations MUST by default > forward EAP packets of any Type. > > Since EAP packets received with Code=1 (Request), Code=3 (Success), > and Code=4 (Failure) are demultiplexed by the EAP layer and > delivered to the peer listener, unless a NAS implements > an EAP peer listener, these packets will be silently > discarded. Since the behavior of a "pass-through peer" is > undefined, where an EAP peer listener is implemented, the > NAS will typically act on these packets locally. > > The use of the RADIUS protocol for encapsulation of EAP in > pass-through operation is described in [RFC3579]. > > > Peer Pass-through Authenticator Authentication > Server > > +-+-+-+-+-+-+ +-+-+-+-+-+-+ > | | | | > |EAP method | |EAP method | > | V | | ^ | > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > | ! | | | | | ! | > | ! | |EAP Auth. | EAP Auth. | | ! | > |EAP ! peer| | +-----------+ | |EAP !Auth.| > | ! | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > | ! | | ! | ! | | ! | > |EAP !layer| |EAP !layer| EAP !layer| |EAP !layer| > | ! | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ > | ! | | ! | ! | | ! | > |Lower!layer| |Lower!layer| AAA ! /IP | | AAA ! /IP | > | ! | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ > ! ! ! ! > ! ! ! ! > +-------->-----+ +------->------+ > > Figure 2: Pass-through Authenticator > > For sessions in which the authenticator acts as a pass-through, it > MUST determine the outcome of the authentication solely based on the > Accept/Reject indication sent by the backend authentication server; > the outcome MUST NOT be determined by the contents of an EAP packet > sent along with the Accept/Reject indication, or the absence of such > an encapsulated EAP packet. > > 2.4 Peer-to-Peer Operation > > Since EAP is a peer-to-peer protocol, an independent and simultaneous > authentication may take place in the reverse direction (depending on > the capabilities of the lower layer). Both peers may act as > authenticators and authenticatees at the same time; in this case it > is necessary to both peers to implement both EAP authenticator and > peer listeners. In addition, the EAP method implementations on > both peers must support both authenticator and peer functionality. > > Although EAP supports peer-to-peer operation, some EAP > implementations, methods, AAA protocols and link layers may not > support this. For example, EAP-TLS [RFC2716] is a client-server > protocol requiring a different certificate profile for the client and > server. This implies that a host supporting both the EAP-TLS peer and > authenticator roles would need to implement both peer and > authenticator listeners; would need to support both the peer and > authenticator roles in the EAP-TLS implementation; would need to be > provisioned with two distinct certificates, one appropriate for each > role. > > Some EAP methods may support asymmetric authentication, with one type > of credential being required for the peer and another type for the > authenticator. Hosts supporting peer-to-peer operation with such a > method would need to be provisioned with both types of credentials. > > AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP > [DIAM-EAP] only support "passthrough authenticator" operation. > As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an > Access-Request encapsulating an EAP-Request, Success or Failure > packet with an Access-Reject. There is therefore no support for > "passthrough peer" operation. > > Link layers such as IEEE 802.11 may only support uni-directional > derivation and transport of transient session keys. For example, the > group-key handshake defined in [IEEE-802.11i] is uni-directional, > since in IEEE 802.11 only the Access Point (AP) sends multicast > traffic. This means that in ad-hoc operation where either peer may > send multicast traffic, two uni-directional group-key exchanges are > required. Due to constraints imposed by the 4-way unicast key > handshake state machine, this also implies two 4-way handshake and > EAP method exchanges. > > Link layers such as IEEE 802.11 adhoc also do not support "tie > breaking" wherein two hosts initiating authentication with each other > will only go forward with a single authentication. This implies that > even if 802.11 were to support a bi-directional group-key handshake, > then two authentications, one in each direction, might still occur. > _______________________________________________ > 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 Oct 27 15:39: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 PAA08455 for ; Mon, 27 Oct 2003 15:39:04 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1E51580010; Mon, 27 Oct 2003 14:39:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A5A0580018; Mon, 27 Oct 2003 14:39:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 54DEF580018 for ; Mon, 27 Oct 2003 14:38:42 -0600 (CST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 8B7A0580010 for ; Mon, 27 Oct 2003 14:38:33 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08268; Mon, 27 Oct 2003 15:38:19 -0500 (EST) Message-Id: <200310272038.PAA08268@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-statemachine-01.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: Mon, 27 Oct 2003 15:38:19 -0500 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 : State Machines for EAP Peer and Authenticator Author(s) : J. Vollbrecht Filename : draft-ietf-eap-statemachine-01.txt,.ps,.pdf Pages : 37 Date : 2003-10-27 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-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-statemachine-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-statemachine-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27155601.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-statemachine-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-statemachine-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27155601.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 27 16:38:53 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 QAA13773 for ; Mon, 27 Oct 2003 16:38:10 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F34E6580010; Mon, 27 Oct 2003 15:38:12 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 47905580019; Mon, 27 Oct 2003 15:38:07 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 01991580010 for ; Mon, 27 Oct 2003 15:37:16 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 1616C580019 for ; Mon, 27 Oct 2003 15:37:13 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9RL0TE30180; Mon, 27 Oct 2003 13:00:29 -0800 From: Bernard Aboba To: Nick Petroni Cc: eap@frascone.com Subject: Re: [eap] Re: proposed resolution to Issue 161 -- Take Three In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Mon, 27 Oct 2003 13:00:29 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Yes, I think your diagram says it best. Mind if I steal it? :) On Mon, 27 Oct 2003, Nick Petroni wrote: > Thanks Bernard. I think this makes more sense and I like this more. The > diagram I was trying to describe previously looks something like the > following, but I am happy with yours as it reads. > > thanks, > nick > > > Peer Pass-through Authenticator Authentication > Server > > +-+-+-+-+-+-+ +-+-+-+-+-+-+ > | | | | > |EAP method | |EAP method | > | V | | ^ | > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > | ! | |EAP | EAP | | | ! | > | ! | |Peer | Auth.| EAP Auth. | | ! | > |EAP ! peer| | | +-----------+ | |EAP !Auth.| > | ! | | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ > | ! | | ! | ! | | ! | > |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer| > | ! | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ > | ! | | ! | ! | | ! | > |Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP | > | ! | | ! | ! | | ! | > +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ > ! ! ! ! > ! ! ! ! > +-------->--------+ +--------->-------+ > > > > On Sun, 26 Oct 2003, Bernard Aboba wrote: > > > Nick -- > > > > Thought about this a bit more. Given that the Code field allows the EAP > > layer to demultiplex packets destined to an authenticator versus peer > > listener, a "pass-through authenticator" will only receive EAP > > packets destined for the authenticator listener, that is, packets > > with Code=2 (Response). Unless the NAS also has a peer listener, > > it will silently discard packets with other Code values. Since > > RADIUS and Diameter do not support a "pass-through peer", there > > is no way in practice that EAP packets of Codes other than 2 can be > > forwarded to the backend authentication server. > > > > Here is another pass at the text in an attempt to get this straight. > > > > Bernard > > > > > > 2.2 EAP multiplexing model > > > > Conceptually, EAP implementations consist of the following > > components: > > > > [a] Lower layer. The lower layer is responsible for transmitting and > > receiving EAP frames between the peer and authenticator. EAP has > > been run over a variety of lower layers including PPP; wired IEEE > > 802 LANs [IEEE-802.1X]; IEEE 802.11 wireless LANs [IEEE-802.11]; > > UDP (L2TP [RFC2661] and IKEv2 [IKEv2]); and TCP [PIC]. Lower > > layer behavior is discussed in Section 3. > > > > [b] EAP layer. The EAP layer receives and transmits EAP packets via > > the lower layer, implements duplicate detection and > > retransmission, and delivers and receives EAP messages to and > > from the EAP peer and authenticator layers. > > > > [c] EAP peer and authenticator layers. Based on the Code field, the > > EAP layer demultiplexes incoming EAP packets to the EAP peer and > > authenticator layers. Typically an EAP implementation on a given > > host will support either peer or authenticator functionality, but > > it is possible for a host to act as both an EAP peer and > > authenticator. In such an implementation both EAP peer and > > authenticator layers will be present. > > > > [d] EAP method layers. EAP methods implement the authentication > > algorithms and receive and transmit EAP messages via the EAP peer > > and authenticator layers. Since fragmentation support is not > > provided by EAP itself, this is the responsibility of EAP methods, > > which are discussed in Section 5. > > > > The EAP multiplexing model is illustrated in Figure 1 below. Note > > that there is no requirement that an implementation conform to this > > model, as long as the on-the-wire behavior is consistent with it. > > > > +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ > > | | | | | | > > | EAP method| EAP method| | EAP method| EAP method| > > | Type = X | Type = Y | | Type = X | Type = Y | > > | V | | | ^ | | > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > | ! | | ! | > > | EAP ! Peer layer | | EAP ! Auth. layer | > > | ! | | ! | > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > | ! | | ! | > > | EAP ! layer | | EAP ! layer | > > | ! | | ! | > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > | ! | | ! | > > | Lower ! layer | | Lower ! layer | > > | ! | | ! | > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > ! ! > > ! Peer ! Authenticator > > +------------>-------------+ > > > > Figure 1: EAP Multiplexing Model > > > > Within EAP, the Code field functions much like a protocol number in > > IP. It is assumed that the EAP layer demultiplexes incoming EAP > > packets according to the Code field. Received EAP packets > > with Code=1 (Request), 3 (Success) and 4 (Failure) are > > delivered by the EAP layer to the EAP peer listener, if > > present. EAP packets with Code=2 (Response) are delivered > > to the EAP authenticator listener, if present. > > > > Within EAP, the Type field functions much like a port number in UDP > > or TCP. It is assumed that the EAP peer and authenticator layers > > demultiplex incoming EAP packets according to their Type, and deliver > > them only to the EAP method corresponding to that Type. An > > EAP method implementation on a host may register to receive > > packets from the peer or authenticator listener, or both. > > > > Since EAP authentication methods may wish to access the Identity, > > implementations SHOULD make the Identity Request and Response > > accessible to authentication methods (Types 4 or greater) in addition > > to the Identity method. The Identity Type is discussed in Section > > 5.1. > > > > A Notification Response is only used as confirmation that the peer > > received the Notification Request, not that it has processed it, or > > displayed the message to the user. It cannot be assumed that the > > contents of the Notification Request or Response is available to > > another method. The Notification Type is discussed in Section 5.2. > > > > Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes > > of method negotiation. Peers respond to an initial EAP Request for > > an unacceptable Type with a Nak Response (Type 3) or Expanded Nak > > Response (Type 254). It cannot be assumed that the contents of the > > Nak Response(s) are available to another method. The Nak Type(s) are > > discussed in Section 5.3. > > > > EAP packets with codes of Success or Failure do not include a Type > > field, and are not delivered to an EAP method. Success and Failure are > > discussed in Section 4.2. > > > > Given these considerations, the Success, Failure, Nak Response(s) and > > Notification Request/Response messages MUST NOT be used to carry data > > destined for delivery to other EAP methods. > > > > 2.3 Pass-through behavior > > > > Where operating as a "pass-through authenticator" an > > authenticator forwards EAP packets destined to its authenticator > > listener to the backend authentication server, and forwards > > packets received from the backend authentication server to the > > peer. > > > > The forwarding decision is based on examination of the > > Code, Identifier and Length fields. Since a "pass-through > > authenticator" only forwards EAP packets destined for its > > authenticator listener, pass-through authenticator > > implementations MUST forward Response (Code=2) packets > > to the backend authentication server. They also MUST be > > capable of receiving and forwarding to the peer Request > > (Code=1), Success (Code=3) and Failure (Code=4) packets. > > > > Since pass-through authenticators rely on a backend authenticator > > server to implement methods, the EAP method layer header fields > > (Type, Type-Data) are not examined as part of the forwarding > > decision, except where the authenticator implements one or more > > authentication methods locally. In this case, the authenticator > > may examine the Type field to determine whether to act on the > > packet itself or forward it. > > > > The forwarding model is illustrated in Figure 2. Compliant > > pass-through authenticator implementations MUST by default > > forward EAP packets of any Type. > > > > Since EAP packets received with Code=1 (Request), Code=3 (Success), > > and Code=4 (Failure) are demultiplexed by the EAP layer and > > delivered to the peer listener, unless a NAS implements > > an EAP peer listener, these packets will be silently > > discarded. Since the behavior of a "pass-through peer" is > > undefined, where an EAP peer listener is implemented, the > > NAS will typically act on these packets locally. > > > > The use of the RADIUS protocol for encapsulation of EAP in > > pass-through operation is described in [RFC3579]. > > > > > > Peer Pass-through Authenticator Authentication > > Server > > > > +-+-+-+-+-+-+ +-+-+-+-+-+-+ > > | | | | > > |EAP method | |EAP method | > > | V | | ^ | > > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > > | ! | | | | | ! | > > | ! | |EAP Auth. | EAP Auth. | | ! | > > |EAP ! peer| | +-----------+ | |EAP !Auth.| > > | ! | | ! | ! | | ! | > > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > > | ! | | ! | ! | | ! | > > |EAP !layer| |EAP !layer| EAP !layer| |EAP !layer| > > | ! | | ! | ! | | ! | > > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ > > | ! | | ! | ! | | ! | > > |Lower!layer| |Lower!layer| AAA ! /IP | | AAA ! /IP | > > | ! | | ! | ! | | ! | > > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ > > ! ! ! ! > > ! ! ! ! > > +-------->-----+ +------->------+ > > > > Figure 2: Pass-through Authenticator > > > > For sessions in which the authenticator acts as a pass-through, it > > MUST determine the outcome of the authentication solely based on the > > Accept/Reject indication sent by the backend authentication server; > > the outcome MUST NOT be determined by the contents of an EAP packet > > sent along with the Accept/Reject indication, or the absence of such > > an encapsulated EAP packet. > > > > 2.4 Peer-to-Peer Operation > > > > Since EAP is a peer-to-peer protocol, an independent and simultaneous > > authentication may take place in the reverse direction (depending on > > the capabilities of the lower layer). Both peers may act as > > authenticators and authenticatees at the same time; in this case it > > is necessary to both peers to implement both EAP authenticator and > > peer listeners. In addition, the EAP method implementations on > > both peers must support both authenticator and peer functionality. > > > > Although EAP supports peer-to-peer operation, some EAP > > implementations, methods, AAA protocols and link layers may not > > support this. For example, EAP-TLS [RFC2716] is a client-server > > protocol requiring a different certificate profile for the client and > > server. This implies that a host supporting both the EAP-TLS peer and > > authenticator roles would need to implement both peer and > > authenticator listeners; would need to support both the peer and > > authenticator roles in the EAP-TLS implementation; would need to be > > provisioned with two distinct certificates, one appropriate for each > > role. > > > > Some EAP methods may support asymmetric authentication, with one type > > of credential being required for the peer and another type for the > > authenticator. Hosts supporting peer-to-peer operation with such a > > method would need to be provisioned with both types of credentials. > > > > AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP > > [DIAM-EAP] only support "passthrough authenticator" operation. > > As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an > > Access-Request encapsulating an EAP-Request, Success or Failure > > packet with an Access-Reject. There is therefore no support for > > "passthrough peer" operation. > > > > Link layers such as IEEE 802.11 may only support uni-directional > > derivation and transport of transient session keys. For example, the > > group-key handshake defined in [IEEE-802.11i] is uni-directional, > > since in IEEE 802.11 only the Access Point (AP) sends multicast > > traffic. This means that in ad-hoc operation where either peer may > > send multicast traffic, two uni-directional group-key exchanges are > > required. Due to constraints imposed by the 4-way unicast key > > handshake state machine, this also implies two 4-way handshake and > > EAP method exchanges. > > > > Link layers such as IEEE 802.11 adhoc also do not support "tie > > breaking" wherein two hosts initiating authentication with each other > > will only go forward with a single authentication. This implies that > > even if 802.11 were to support a bi-directional group-key handshake, > > then two authentications, one in each direction, might still occur. > > _______________________________________________ > > 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 Oct 27 17:15:23 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 RAA20220 for ; Mon, 27 Oct 2003 17:14:32 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 105DF580018; Mon, 27 Oct 2003 16:14:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A2D258010A; Mon, 27 Oct 2003 16:14:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D311658010A for ; Mon, 27 Oct 2003 16:13:42 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 98358580018 for ; Mon, 27 Oct 2003 16:13:41 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id h9RMDfBf007520; Mon, 27 Oct 2003 17:13:41 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Subject: Re: [eap] Re: proposed resolution to Issue 161 -- Take Three In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Mon, 27 Oct 2003 17:13:40 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) sounds like a plan. Thanks, nick Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni On Mon, 27 Oct 2003, Bernard Aboba wrote: > Yes, I think your diagram says it best. Mind if I steal it? :) > > On Mon, 27 Oct 2003, Nick Petroni wrote: > > > Thanks Bernard. I think this makes more sense and I like this more. The > > diagram I was trying to describe previously looks something like the > > following, but I am happy with yours as it reads. > > > > thanks, > > nick > > > > > > Peer Pass-through Authenticator Authentication > > Server > > > > +-+-+-+-+-+-+ +-+-+-+-+-+-+ > > | | | | > > |EAP method | |EAP method | > > | V | | ^ | > > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > > | ! | |EAP | EAP | | | ! | > > | ! | |Peer | Auth.| EAP Auth. | | ! | > > |EAP ! peer| | | +-----------+ | |EAP !Auth.| > > | ! | | | ! | ! | | ! | > > +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ > > | ! | | ! | ! | | ! | > > |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer| > > | ! | | ! | ! | | ! | > > +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ > > | ! | | ! | ! | | ! | > > |Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP | > > | ! | | ! | ! | | ! | > > +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ > > ! ! ! ! > > ! ! ! ! > > +-------->--------+ +--------->-------+ > > > > > > > > On Sun, 26 Oct 2003, Bernard Aboba wrote: > > > > > Nick -- > > > > > > Thought about this a bit more. Given that the Code field allows the EAP > > > layer to demultiplex packets destined to an authenticator versus peer > > > listener, a "pass-through authenticator" will only receive EAP > > > packets destined for the authenticator listener, that is, packets > > > with Code=2 (Response). Unless the NAS also has a peer listener, > > > it will silently discard packets with other Code values. Since > > > RADIUS and Diameter do not support a "pass-through peer", there > > > is no way in practice that EAP packets of Codes other than 2 can be > > > forwarded to the backend authentication server. > > > > > > Here is another pass at the text in an attempt to get this straight. > > > > > > Bernard > > > > > > > > > 2.2 EAP multiplexing model > > > > > > Conceptually, EAP implementations consist of the following > > > components: > > > > > > [a] Lower layer. The lower layer is responsible for transmitting and > > > receiving EAP frames between the peer and authenticator. EAP has > > > been run over a variety of lower layers including PPP; wired IEEE > > > 802 LANs [IEEE-802.1X]; IEEE 802.11 wireless LANs [IEEE-802.11]; > > > UDP (L2TP [RFC2661] and IKEv2 [IKEv2]); and TCP [PIC]. Lower > > > layer behavior is discussed in Section 3. > > > > > > [b] EAP layer. The EAP layer receives and transmits EAP packets via > > > the lower layer, implements duplicate detection and > > > retransmission, and delivers and receives EAP messages to and > > > from the EAP peer and authenticator layers. > > > > > > [c] EAP peer and authenticator layers. Based on the Code field, the > > > EAP layer demultiplexes incoming EAP packets to the EAP peer and > > > authenticator layers. Typically an EAP implementation on a given > > > host will support either peer or authenticator functionality, but > > > it is possible for a host to act as both an EAP peer and > > > authenticator. In such an implementation both EAP peer and > > > authenticator layers will be present. > > > > > > [d] EAP method layers. EAP methods implement the authentication > > > algorithms and receive and transmit EAP messages via the EAP peer > > > and authenticator layers. Since fragmentation support is not > > > provided by EAP itself, this is the responsibility of EAP methods, > > > which are discussed in Section 5. > > > > > > The EAP multiplexing model is illustrated in Figure 1 below. Note > > > that there is no requirement that an implementation conform to this > > > model, as long as the on-the-wire behavior is consistent with it. > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | | | | | > > > | EAP method| EAP method| | EAP method| EAP method| > > > | Type = X | Type = Y | | Type = X | Type = Y | > > > | V | | | ^ | | > > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > > | ! | | ! | > > > | EAP ! Peer layer | | EAP ! Auth. layer | > > > | ! | | ! | > > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > > | ! | | ! | > > > | EAP ! layer | | EAP ! layer | > > > | ! | | ! | > > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > > | ! | | ! | > > > | Lower ! layer | | Lower ! layer | > > > | ! | | ! | > > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > > ! ! > > > ! Peer ! Authenticator > > > +------------>-------------+ > > > > > > Figure 1: EAP Multiplexing Model > > > > > > Within EAP, the Code field functions much like a protocol number in > > > IP. It is assumed that the EAP layer demultiplexes incoming EAP > > > packets according to the Code field. Received EAP packets > > > with Code=1 (Request), 3 (Success) and 4 (Failure) are > > > delivered by the EAP layer to the EAP peer listener, if > > > present. EAP packets with Code=2 (Response) are delivered > > > to the EAP authenticator listener, if present. > > > > > > Within EAP, the Type field functions much like a port number in UDP > > > or TCP. It is assumed that the EAP peer and authenticator layers > > > demultiplex incoming EAP packets according to their Type, and deliver > > > them only to the EAP method corresponding to that Type. An > > > EAP method implementation on a host may register to receive > > > packets from the peer or authenticator listener, or both. > > > > > > Since EAP authentication methods may wish to access the Identity, > > > implementations SHOULD make the Identity Request and Response > > > accessible to authentication methods (Types 4 or greater) in addition > > > to the Identity method. The Identity Type is discussed in Section > > > 5.1. > > > > > > A Notification Response is only used as confirmation that the peer > > > received the Notification Request, not that it has processed it, or > > > displayed the message to the user. It cannot be assumed that the > > > contents of the Notification Request or Response is available to > > > another method. The Notification Type is discussed in Section 5.2. > > > > > > Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes > > > of method negotiation. Peers respond to an initial EAP Request for > > > an unacceptable Type with a Nak Response (Type 3) or Expanded Nak > > > Response (Type 254). It cannot be assumed that the contents of the > > > Nak Response(s) are available to another method. The Nak Type(s) are > > > discussed in Section 5.3. > > > > > > EAP packets with codes of Success or Failure do not include a Type > > > field, and are not delivered to an EAP method. Success and Failure are > > > discussed in Section 4.2. > > > > > > Given these considerations, the Success, Failure, Nak Response(s) and > > > Notification Request/Response messages MUST NOT be used to carry data > > > destined for delivery to other EAP methods. > > > > > > 2.3 Pass-through behavior > > > > > > Where operating as a "pass-through authenticator" an > > > authenticator forwards EAP packets destined to its authenticator > > > listener to the backend authentication server, and forwards > > > packets received from the backend authentication server to the > > > peer. > > > > > > The forwarding decision is based on examination of the > > > Code, Identifier and Length fields. Since a "pass-through > > > authenticator" only forwards EAP packets destined for its > > > authenticator listener, pass-through authenticator > > > implementations MUST forward Response (Code=2) packets > > > to the backend authentication server. They also MUST be > > > capable of receiving and forwarding to the peer Request > > > (Code=1), Success (Code=3) and Failure (Code=4) packets. > > > > > > Since pass-through authenticators rely on a backend authenticator > > > server to implement methods, the EAP method layer header fields > > > (Type, Type-Data) are not examined as part of the forwarding > > > decision, except where the authenticator implements one or more > > > authentication methods locally. In this case, the authenticator > > > may examine the Type field to determine whether to act on the > > > packet itself or forward it. > > > > > > The forwarding model is illustrated in Figure 2. Compliant > > > pass-through authenticator implementations MUST by default > > > forward EAP packets of any Type. > > > > > > Since EAP packets received with Code=1 (Request), Code=3 (Success), > > > and Code=4 (Failure) are demultiplexed by the EAP layer and > > > delivered to the peer listener, unless a NAS implements > > > an EAP peer listener, these packets will be silently > > > discarded. Since the behavior of a "pass-through peer" is > > > undefined, where an EAP peer listener is implemented, the > > > NAS will typically act on these packets locally. > > > > > > The use of the RADIUS protocol for encapsulation of EAP in > > > pass-through operation is described in [RFC3579]. > > > > > > > > > Peer Pass-through Authenticator Authentication > > > Server > > > > > > +-+-+-+-+-+-+ +-+-+-+-+-+-+ > > > | | | | > > > |EAP method | |EAP method | > > > | V | | ^ | > > > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > > > | ! | | | | | ! | > > > | ! | |EAP Auth. | EAP Auth. | | ! | > > > |EAP ! peer| | +-----------+ | |EAP !Auth.| > > > | ! | | ! | ! | | ! | > > > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > > > | ! | | ! | ! | | ! | > > > |EAP !layer| |EAP !layer| EAP !layer| |EAP !layer| > > > | ! | | ! | ! | | ! | > > > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ > > > | ! | | ! | ! | | ! | > > > |Lower!layer| |Lower!layer| AAA ! /IP | | AAA ! /IP | > > > | ! | | ! | ! | | ! | > > > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ > > > ! ! ! ! > > > ! ! ! ! > > > +-------->-----+ +------->------+ > > > > > > Figure 2: Pass-through Authenticator > > > > > > For sessions in which the authenticator acts as a pass-through, it > > > MUST determine the outcome of the authentication solely based on the > > > Accept/Reject indication sent by the backend authentication server; > > > the outcome MUST NOT be determined by the contents of an EAP packet > > > sent along with the Accept/Reject indication, or the absence of such > > > an encapsulated EAP packet. > > > > > > 2.4 Peer-to-Peer Operation > > > > > > Since EAP is a peer-to-peer protocol, an independent and simultaneous > > > authentication may take place in the reverse direction (depending on > > > the capabilities of the lower layer). Both peers may act as > > > authenticators and authenticatees at the same time; in this case it > > > is necessary to both peers to implement both EAP authenticator and > > > peer listeners. In addition, the EAP method implementations on > > > both peers must support both authenticator and peer functionality. > > > > > > Although EAP supports peer-to-peer operation, some EAP > > > implementations, methods, AAA protocols and link layers may not > > > support this. For example, EAP-TLS [RFC2716] is a client-server > > > protocol requiring a different certificate profile for the client and > > > server. This implies that a host supporting both the EAP-TLS peer and > > > authenticator roles would need to implement both peer and > > > authenticator listeners; would need to support both the peer and > > > authenticator roles in the EAP-TLS implementation; would need to be > > > provisioned with two distinct certificates, one appropriate for each > > > role. > > > > > > Some EAP methods may support asymmetric authentication, with one type > > > of credential being required for the peer and another type for the > > > authenticator. Hosts supporting peer-to-peer operation with such a > > > method would need to be provisioned with both types of credentials. > > > > > > AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP > > > [DIAM-EAP] only support "passthrough authenticator" operation. > > > As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an > > > Access-Request encapsulating an EAP-Request, Success or Failure > > > packet with an Access-Reject. There is therefore no support for > > > "passthrough peer" operation. > > > > > > Link layers such as IEEE 802.11 may only support uni-directional > > > derivation and transport of transient session keys. For example, the > > > group-key handshake defined in [IEEE-802.11i] is uni-directional, > > > since in IEEE 802.11 only the Access Point (AP) sends multicast > > > traffic. This means that in ad-hoc operation where either peer may > > > send multicast traffic, two uni-directional group-key exchanges are > > > required. Due to constraints imposed by the 4-way unicast key > > > handshake state machine, this also implies two 4-way handshake and > > > EAP method exchanges. > > > > > > Link layers such as IEEE 802.11 adhoc also do not support "tie > > > breaking" wherein two hosts initiating authentication with each other > > > will only go forward with a single authentication. This implies that > > > even if 802.11 were to support a bi-directional group-key handshake, > > > then two authentications, one in each direction, might still occur. > > > _______________________________________________ > > > 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 > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 27 17:20: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 RAA21172 for ; Mon, 27 Oct 2003 17:19:10 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E95D58001A; Mon, 27 Oct 2003 16:19:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7545758001D; Mon, 27 Oct 2003 16:19:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B05458001A for ; Mon, 27 Oct 2003 16:18:37 -0600 (CST) Received: from intolerance.mr.itd.umich.edu (intolerance.mr.itd.umich.edu [141.211.14.78]) by mail.frascone.com (Postfix) with ESMTP id 945C258001D for ; Mon, 27 Oct 2003 16:18:34 -0600 (CST) Received: from [10.0.1.2] (pm470-32.dialip.mich.net [207.75.178.90]) by intolerance.mr.itd.umich.edu (smtp) with ESMTP id h9RMIJ5U027422; Mon, 27 Oct 2003 17:18:21 -0500 From: John Vollbrecht To: Nick Petroni , Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Re: proposed resolution to Issue 161 -- Take Three Message-ID: <1570639.1067275098@[10.0.1.2]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: Mon, 27 Oct 2003 17:18:19 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit This looks very nice to me as well. -- john --On Monday, October 27, 2003 5:13 PM -0500 Nick Petroni wrote: > sounds like a plan. > > Thanks, > nick > > Nick L. Petroni, Jr. > Graduate Student, Computer Science > Maryland Information Systems Security Lab > University of Maryland > http://www.cs.umd.edu/~npetroni > > On Mon, 27 Oct 2003, Bernard Aboba wrote: > > > Yes, I think your diagram says it best. Mind if I steal it? :) > > > > On Mon, 27 Oct 2003, Nick Petroni wrote: > > > > > Thanks Bernard. I think this makes more sense and I like this more. > > > The diagram I was trying to describe previously looks something like > > > the following, but I am happy with yours as it reads. > > > > > > thanks, > > > nick > > > > > > > > > Peer Pass-through Authenticator Authentication > > > Server > > > > > > +-+-+-+-+-+-+ +-+-+-+-+-+-+ > > > | | | | > > > | EAP method | |EAP method | > > > | V | | ^ | > > > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > > > | ! | |EAP | EAP | | | ! | > > > | ! | |Peer | Auth.| EAP Auth. | | ! | > > > | EAP ! peer| | | +-----------+ | |EAP !Auth.| > > > | ! | | | ! | ! | | ! | > > > +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ > > > | ! | | ! | ! | | ! | > > > | EAP !layer| | EAP !layer| EAP !layer | |EAP !layer| > > > | ! | | ! | ! | | ! | > > > +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ > > > | ! | | ! | ! | | ! | > > > | Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP | > > > | ! | | ! | ! | | ! | > > > +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ > > > ! ! ! ! > > > ! ! ! ! > > > +-------->--------+ +--------->-------+ > > > > > > > > > > > > On Sun, 26 Oct 2003, Bernard Aboba wrote: > > > > > > > Nick -- > > > > > > > > Thought about this a bit more. Given that the Code field allows > > > > the EAP layer to demultiplex packets destined to an authenticator > > > > versus peer listener, a "pass-through authenticator" will only > > > > receive EAP packets destined for the authenticator listener, that > > > > is, packets with Code=2 (Response). Unless the NAS also has a peer > > > > listener, it will silently discard packets with other Code values. > > > > Since RADIUS and Diameter do not support a "pass-through peer", > > > > there is no way in practice that EAP packets of Codes other than 2 > > > > can be forwarded to the backend authentication server. > > > > > > > > Here is another pass at the text in an attempt to get this straight. > > > > > > > > Bernard > > > > > > > > > > > > 2.2 EAP multiplexing model > > > > > > > > Conceptually, EAP implementations consist of the following > > > > components: > > > > > > > > [a] Lower layer. The lower layer is responsible for > > > > transmitting and receiving EAP frames between the peer and > > > > authenticator. EAP has been run over a variety of lower > > > > layers including PPP; wired IEEE 802 LANs [IEEE-802.1X]; > > > > IEEE 802.11 wireless LANs [IEEE-802.11]; UDP (L2TP [RFC2661] > > > > and IKEv2 [IKEv2]); and TCP [PIC]. Lower layer behavior is > > > > discussed in Section 3. > > > > > > > > [b] EAP layer. The EAP layer receives and transmits EAP packets > > > > via the lower layer, implements duplicate detection and > > > > retransmission, and delivers and receives EAP messages to and > > > > from the EAP peer and authenticator layers. > > > > > > > > [c] EAP peer and authenticator layers. Based on the Code field, > > > > the EAP layer demultiplexes incoming EAP packets to the EAP peer > > > > and authenticator layers. Typically an EAP implementation > > > > on a given host will support either peer or authenticator > > > > functionality, but it is possible for a host to act as both > > > > an EAP peer and authenticator. In such an implementation > > > > both EAP peer and authenticator layers will be present. > > > > > > > > [d] EAP method layers. EAP methods implement the authentication > > > > algorithms and receive and transmit EAP messages via the EAP > > > > peer and authenticator layers. Since fragmentation support > > > > is not provided by EAP itself, this is the responsibility of > > > > EAP methods, which are discussed in Section 5. > > > > > > > > The EAP multiplexing model is illustrated in Figure 1 below. Note > > > > that there is no requirement that an implementation conform to > > > > this model, as long as the on-the-wire behavior is consistent > > > > with it. > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | | | | | | > > > > | EAP method| EAP method| | EAP method| EAP method| > > > > | Type = X | Type = Y | | Type = X | Type = Y | > > > > | V | | | ^ | | > > > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > > > | ! | | ! | > > > > | EAP ! Peer layer | | EAP ! Auth. layer | > > > > | ! | | ! | > > > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > > > | ! | | ! | > > > > | EAP ! layer | | EAP ! layer | > > > > | ! | | ! | > > > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > > > | ! | | ! | > > > > | Lower ! layer | | Lower ! layer | > > > > | ! | | ! | > > > > +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ > > > > ! ! > > > > ! Peer ! Authenticator > > > > +------------>-------------+ > > > > > > > > Figure 1: EAP Multiplexing Model > > > > > > > > Within EAP, the Code field functions much like a protocol number > > > > in IP. It is assumed that the EAP layer demultiplexes incoming > > > > EAP packets according to the Code field. Received EAP packets > > > > with Code=1 (Request), 3 (Success) and 4 (Failure) are > > > > delivered by the EAP layer to the EAP peer listener, if > > > > present. EAP packets with Code=2 (Response) are delivered > > > > to the EAP authenticator listener, if present. > > > > > > > > Within EAP, the Type field functions much like a port number in > > > > UDP or TCP. It is assumed that the EAP peer and authenticator > > > > layers demultiplex incoming EAP packets according to their Type, > > > > and deliver them only to the EAP method corresponding to that > > > > Type. An EAP method implementation on a host may register to > > > > receive packets from the peer or authenticator listener, or both. > > > > > > > > Since EAP authentication methods may wish to access the Identity, > > > > implementations SHOULD make the Identity Request and Response > > > > accessible to authentication methods (Types 4 or greater) in > > > > addition to the Identity method. The Identity Type is discussed > > > > in Section 5.1. > > > > > > > > A Notification Response is only used as confirmation that the > > > > peer received the Notification Request, not that it has > > > > processed it, or displayed the message to the user. It cannot > > > > be assumed that the contents of the Notification Request or > > > > Response is available to another method. The Notification Type > > > > is discussed in Section 5.2. > > > > > > > > Nak (Type 3) or Expanded Nak (Type 254) are utilized for the > > > > purposes of method negotiation. Peers respond to an initial EAP > > > > Request for an unacceptable Type with a Nak Response (Type 3) or > > > > Expanded Nak Response (Type 254). It cannot be assumed that the > > > > contents of the Nak Response(s) are available to another method. > > > > The Nak Type(s) are discussed in Section 5.3. > > > > > > > > EAP packets with codes of Success or Failure do not include a > > > > Type field, and are not delivered to an EAP method. Success and > > > > Failure are discussed in Section 4.2. > > > > > > > > Given these considerations, the Success, Failure, Nak > > > > Response(s) and Notification Request/Response messages MUST NOT > > > > be used to carry data destined for delivery to other EAP methods. > > > > > > > > 2.3 Pass-through behavior > > > > > > > > Where operating as a "pass-through authenticator" an > > > > authenticator forwards EAP packets destined to its authenticator > > > > listener to the backend authentication server, and forwards > > > > packets received from the backend authentication server to the > > > > peer. > > > > > > > > The forwarding decision is based on examination of the > > > > Code, Identifier and Length fields. Since a "pass-through > > > > authenticator" only forwards EAP packets destined for its > > > > authenticator listener, pass-through authenticator > > > > implementations MUST forward Response (Code=2) packets > > > > to the backend authentication server. They also MUST be > > > > capable of receiving and forwarding to the peer Request > > > > (Code=1), Success (Code=3) and Failure (Code=4) packets. > > > > > > > > Since pass-through authenticators rely on a backend authenticator > > > > server to implement methods, the EAP method layer header fields > > > > (Type, Type-Data) are not examined as part of the forwarding > > > > decision, except where the authenticator implements one or more > > > > authentication methods locally. In this case, the authenticator > > > > may examine the Type field to determine whether to act on the > > > > packet itself or forward it. > > > > > > > > The forwarding model is illustrated in Figure 2. Compliant > > > > pass-through authenticator implementations MUST by default > > > > forward EAP packets of any Type. > > > > > > > > Since EAP packets received with Code=1 (Request), Code=3 > > > > (Success), and Code=4 (Failure) are demultiplexed by the EAP > > > > layer and delivered to the peer listener, unless a NAS > > > > implements an EAP peer listener, these packets will be silently > > > > discarded. Since the behavior of a "pass-through peer" is > > > > undefined, where an EAP peer listener is implemented, the > > > > NAS will typically act on these packets locally. > > > > > > > > The use of the RADIUS protocol for encapsulation of EAP in > > > > pass-through operation is described in [RFC3579]. > > > > > > > > > > > > Peer Pass-through Authenticator Authentication > > > > Server > > > > > > > > +-+-+-+-+-+-+ +-+-+-+-+-+-+ > > > > | | | | > > > > | EAP method | |EAP method | > > > > | V | | ^ | > > > > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > > > > | ! | | | | | ! | > > > > | ! | |EAP Auth. | EAP Auth. | | ! | > > > > | EAP ! peer| | +-----------+ | |EAP !Auth.| > > > > | ! | | ! | ! | | ! | > > > > +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ > > > > | ! | | ! | ! | | ! | > > > > | EAP !layer| |EAP !layer| EAP !layer| |EAP !layer| > > > > | ! | | ! | ! | | ! | > > > > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ > > > > | ! | | ! | ! | | ! | > > > > | Lower!layer| |Lower!layer| AAA ! /IP | | AAA ! /IP | > > > > | ! | | ! | ! | | ! | > > > > +-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+ > > > > ! ! ! ! > > > > ! ! ! ! > > > > +-------->-----+ +------->------+ > > > > > > > > Figure 2: Pass-through Authenticator > > > > > > > > For sessions in which the authenticator acts as a pass-through, > > > > it MUST determine the outcome of the authentication solely based > > > > on the Accept/Reject indication sent by the backend > > > > authentication server; the outcome MUST NOT be determined by the > > > > contents of an EAP packet sent along with the Accept/Reject > > > > indication, or the absence of such an encapsulated EAP packet. > > > > > > > > 2.4 Peer-to-Peer Operation > > > > > > > > Since EAP is a peer-to-peer protocol, an independent and > > > > simultaneous authentication may take place in the reverse > > > > direction (depending on the capabilities of the lower layer). > > > > Both peers may act as authenticators and authenticatees at the > > > > same time; in this case it is necessary to both peers to > > > > implement both EAP authenticator and peer listeners. In > > > > addition, the EAP method implementations on both peers must > > > > support both authenticator and peer functionality. > > > > > > > > Although EAP supports peer-to-peer operation, some EAP > > > > implementations, methods, AAA protocols and link layers may not > > > > support this. For example, EAP-TLS [RFC2716] is a client-server > > > > protocol requiring a different certificate profile for the > > > > client and server. This implies that a host supporting both the > > > > EAP-TLS peer and authenticator roles would need to implement > > > > both peer and authenticator listeners; would need to support > > > > both the peer and authenticator roles in the EAP-TLS > > > > implementation; would need to be provisioned with two distinct > > > > certificates, one appropriate for each role. > > > > > > > > Some EAP methods may support asymmetric authentication, with one > > > > type of credential being required for the peer and another type > > > > for the authenticator. Hosts supporting peer-to-peer operation > > > > with such a method would need to be provisioned with both types > > > > of credentials. > > > > > > > > AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP > > > > [DIAM-EAP] only support "passthrough authenticator" operation. > > > > As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to > > > > an Access-Request encapsulating an EAP-Request, Success or > > > > Failure packet with an Access-Reject. There is therefore no > > > > support for "passthrough peer" operation. > > > > > > > > Link layers such as IEEE 802.11 may only support uni-directional > > > > derivation and transport of transient session keys. For > > > > example, the group-key handshake defined in [IEEE-802.11i] is > > > > uni-directional, since in IEEE 802.11 only the Access Point (AP) > > > > sends multicast traffic. This means that in ad-hoc operation > > > > where either peer may send multicast traffic, two > > > > uni-directional group-key exchanges are required. Due to > > > > constraints imposed by the 4-way unicast key handshake state > > > > machine, this also implies two 4-way handshake and EAP method > > > > exchanges. > > > > > > > > Link layers such as IEEE 802.11 adhoc also do not support "tie > > > > breaking" wherein two hosts initiating authentication with each > > > > other will only go forward with a single authentication. This > > > > implies that even if 802.11 were to support a bi-directional > > > > group-key handshake, then two authentications, one in each > > > > direction, might still occur. > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ > 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 Oct 27 18:01: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 SAA25733 for ; Mon, 27 Oct 2003 18:01:04 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 68145580109; Mon, 27 Oct 2003 17:01:13 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C6B0D58001D; Mon, 27 Oct 2003 17:01:07 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 631C058001A for ; Mon, 27 Oct 2003 17:00:47 -0600 (CST) Received: from intolerance.mr.itd.umich.edu (intolerance.mr.itd.umich.edu [141.211.14.78]) by mail.frascone.com (Postfix) with ESMTP id 376E4580019 for ; Mon, 27 Oct 2003 17:00:46 -0600 (CST) Received: from [10.0.1.2] (pm470-32.dialip.mich.net [207.75.178.90]) by intolerance.mr.itd.umich.edu (smtp) with ESMTP id h9RN0g5U001283; Mon, 27 Oct 2003 18:00:44 -0500 From: John Vollbrecht To: Pasi.Eronen@nokia.com, eap@frascone.com Subject: Re: [eap] Update for issue 183 (Security Associations) Message-ID: <1723278.1067277642@[10.0.1.2]> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C385C@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6010C385C@esebe023.ntc.nokia.com > X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: Mon, 27 Oct 2003 18:00:43 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit --On Wednesday, October 22, 2003 5:11 PM +0300 Pasi.Eronen@nokia.com wrote: > Hi, > > We had a lively discussion about the SAs and naming at the > interim meeting. It seems the SA description text I sent > last week was missing (at least) one SA, and thus we > had severe difficulties in naming it :-) > True - we did have a lively discusssion. I like what you have here, but I am wondering about the difference between a PublicKey and Symetric key model. If the symetric key exists, I am not sure it could not be used for key distribution, and so does not need a different name (it already has one e.g. master key in kerberos). Is this to have an additional name? Or is there a difference between a master key and an "EAP distribution key"? > Would something like this do? > > 3.3 EAP key distribution SA > > This is an SA between the peer and backend authentication > server, and it allows them to derive keys to be delivered to > authenticators. > > Current implementations do not actually store this SA after > the EAP conversation is over, but future implementations could > use this for things such as pre-emptive key distribution. > > Contains > o Name/identifier for this SA > o Identities of the parties > o EMSK (or some other keys known only to the peer and > backend authentication server) > o Other yet-unspecified information > > 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 Mon Oct 27 22:56: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 WAA06097 for ; Mon, 27 Oct 2003 22:56:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8C9FD580019; Mon, 27 Oct 2003 21:56:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7579858001A; Mon, 27 Oct 2003 21:56:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 797DE58001A for ; Mon, 27 Oct 2003 21:55:04 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 0C680580019 for ; Mon, 27 Oct 2003 21:55:03 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9S3IKK19590 for ; Mon, 27 Oct 2003 19:18:20 -0800 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 of Issue 188: Packet ordering 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, 27 Oct 2003 19:18:20 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 188 is enclosed below. The proposed fix is as follows: Add to Section 3.1, at the end of item [6]: Reordering, if it occurs, will typically result in an EAP authentication failure, causing EAP authentication to be rerun. In an environment in which reordering is likely, it is therefore expected that EAP authentication failures will be common. It is RECOMMENDED that EAP only be run over lower layers that provide ordering guarantees; running EAP over raw IP or UDP transport is NOT RECOMMENDED. Encapsulation of EAP within RADIUS [RFC3579] satisfies ordering requirements, since RADIUS is a "lockstep" protocol that delivers packets in order. ---------------------------------------------------------- Issue 188: Packet Ordering Submitter name: Margaret Wasserman Submitter email address: Margaret.Wasserman@nokia.com Date first submitted: October 23, 2003 Reference: Document: RFC 2284bis-06 Comment type: T Priority: S Section: 2.3 Rationale/Explanation of issue: Is the current wording/diagram in the document clear enough with respect to the need for IP-based transports to include a mechanism to ensure packet order? Or do you think that we should add a couple of sentences to make this more explicit and explain what "/IP" means in Figure 2? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Oct 27 23:03:42 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 XAA06314 for ; Mon, 27 Oct 2003 23:03:05 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 60525580019; Mon, 27 Oct 2003 22:03:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BE32258001C; Mon, 27 Oct 2003 22:03:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1336758001C for ; Mon, 27 Oct 2003 22:02:35 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id EDCFA580019 for ; Mon, 27 Oct 2003 22:02:32 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9S3Pot20049 for ; Mon, 27 Oct 2003 19:25:50 -0800 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 161: SM Demultiplexing 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, 27 Oct 2003 19:25:50 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 161 is enclosed below. A fix to the state machine document has been discussed in a previous thread. The proposed fix within RFC 2284bis is as follows: Replace the text of Sections 2.2, 2.3 and 2.4 in RFC 2284bis with the following: 2.2 EAP multiplexing model Conceptually, EAP implementations consist of the following components: [a] Lower layer. The lower layer is responsible for transmitting and receiving EAP frames between the peer and authenticator. EAP has been run over a variety of lower layers including PPP; wired IEEE 802 LANs [IEEE-802.1X]; IEEE 802.11 wireless LANs [IEEE-802.11]; UDP (L2TP [RFC2661] and IKEv2 [IKEv2]); and TCP [PIC]. Lower layer behavior is discussed in Section 3. [b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and from the EAP peer and authenticator layers. [c] EAP peer and authenticator layers. Based on the Code field, the EAP layer demultiplexes incoming EAP packets to the EAP peer and authenticator layers. Typically an EAP implementation on a given host will support either peer or authenticator functionality, but it is possible for a host to act as both an EAP peer and authenticator. In such an implementation both EAP peer and authenticator layers will be present. [d] EAP method layers. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP peer and authenticator layers. Since fragmentation support is not provided by EAP itself, this is the responsibility of EAP methods, which are discussed in Section 5. The EAP multiplexing model is illustrated in Figure 1 below. Note that there is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it. +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | EAP method| EAP method| | EAP method| EAP method| | Type = X | Type = Y | | Type = X | Type = Y | | V | | | ^ | | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! Peer layer | | EAP ! Auth. layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | EAP ! layer | | EAP ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ | ! | | ! | | Lower ! layer | | Lower ! layer | | ! | | ! | +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+ ! ! ! Peer ! Authenticator +------------>-------------+ Figure 1: EAP Multiplexing Model Within EAP, the Code field functions much like a protocol number in IP. It is assumed that the EAP layer demultiplexes incoming EAP packets according to the Code field. Received EAP packets with Code=1 (Request), 3 (Success) and 4 (Failure) are delivered by the EAP layer to the EAP peer listener, if present. EAP packets with Code=2 (Response) are delivered to the EAP authenticator listener, if present. Within EAP, the Type field functions much like a port number in UDP or TCP. It is assumed that the EAP peer and authenticator layers demultiplex incoming EAP packets according to their Type, and deliver them only to the EAP method corresponding to that Type. An EAP method implementation on a host may register to receive packets from the peer or authenticator listener, or both. Since EAP authentication methods may wish to access the Identity, implementations SHOULD make the Identity Request and Response accessible to authentication methods (Types 4 or greater) in addition to the Identity method. The Identity Type is discussed in Section 5.1. A Notification Response is only used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. It cannot be assumed that the contents of the Notification Request or Response is available to another method. The Notification Type is discussed in Section 5.2. Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes of method negotiation. Peers respond to an initial EAP Request for an unacceptable Type with a Nak Response (Type 3) or Expanded Nak Response (Type 254). It cannot be assumed that the contents of the Nak Response(s) are available to another method. The Nak Type(s) are discussed in Section 5.3. EAP packets with codes of Success or Failure do not include a Type field, and are not delivered to an EAP method. Success and Failure are discussed in Section 4.2. Given these considerations, the Success, Failure, Nak Response(s) and Notification Request/Response messages MUST NOT be used to carry data destined for delivery to other EAP methods. 2.3 Pass-through behavior When operating as a "pass-through authenticator", an authenticator performs checks on the Code, Identifier and Length fields as described in Section 4.1. It forwards EAP packets received from the peer and destined to its authenticator listener to the backend authentication server; packets received from the backend authentication server destined to the peer are forwarded to it. The forwarding decision is based on examination of the Code, Identifier and Length fields. Since a "pass-through authenticator" only forwards to the backend authentication server EAP packets received from the peer and destined for its authenticator listener, pass-through authenticator implementations MUST be capable of forwarding to the backend authentication server EAP packet received from the peer with Code=2 (Response). They also MUST be capable of receiving EAP packets from the backend authentication server and forwarding EAP packets of Code=1 (Request), Code=3 (Success), and Code=4 (Failure) to the peer. Since pass-through authenticators rely on a backend authenticator server to implement methods, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision, except where the authenticator implements one or more authentication methods locally. In this case, the authenticator may examine the Type field to determine whether to act on the packet itself or forward it. Compliant pass-through authenticator implementations MUST be default forward EAP packets of any Type. The forwarding model is illustrated in Figure 2. Since EAP packets received with Code=1 (Request), Code=3 (Success), and Code=4 (Failure) are demultiplexed by the EAP layer and delivered to the peer listener, unless a host implements an EAP peer listener, these packets will be silently discarded. The behavior of a "pass-through peer" is undefined within this specification, and is unsupported by AAA protocols such as RADIUS [RFC3579] and Diameter [DiamEAP]. Peer Pass-through Authenticator Authentication Server +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | V | | ^ | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | |EAP | EAP | | | ! | | ! | |Peer | Auth.| EAP Auth. | | ! | |EAP ! peer| | | +-----------+ | |EAP !Auth.| | ! | | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer| | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ ! ! ! ! ! ! ! ! +-------->--------+ +--------->-------+ Figure 2: Pass-through Authenticator For sessions in which the authenticator acts as a pass-through, it MUST determine the outcome of the authentication solely based on the Accept/Reject indication sent by the backend authentication server; the outcome MUST NOT be determined by the contents of an EAP packet sent along with the Accept/Reject indication, or the absence of such an encapsulated EAP packet. 2.4 Peer-to-Peer Operation Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction (depending on the capabilities of the lower layer). Both peers may act as authenticators and authenticatees at the same time; in this case it is necessary to both peers to implement both EAP authenticator and peer listeners. In addition, the EAP method implementations on both peers must support both authenticator and peer functionality. Although EAP supports peer-to-peer operation, some EAP implementations, methods, AAA protocols and link layers may not support this. For example, EAP-TLS [RFC2716] is a client-server protocol requiring a different certificate profile for the client and server. This implies that a host supporting both the EAP-TLS peer and authenticator roles would need to implement both peer and authenticator listeners; would need to support both the peer and authenticator roles in the EAP-TLS implementation; would need to be provisioned with two distinct certificates, one appropriate for each role. Some EAP methods may support asymmetric authentication, with one type of credential being required for the peer and another type for the authenticator. Hosts supporting peer-to-peer operation with such a method would need to be provisioned with both types of credentials. AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM-EAP] only support "passthrough authenticator" operation. As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access-Request encapsulating an EAP-Request, Success or Failure packet with an Access-Reject. There is therefore no support for "passthrough peer" operation. Link layers such as IEEE 802.11 may only support uni-directional derivation and transport of transient session keys. For example, the group-key handshake defined in [IEEE-802.11i] is uni-directional, since in IEEE 802.11 only the Access Point (AP) sends multicast traffic. This means that in ad-hoc operation where either peer may send multicast traffic, two uni-directional group-key exchanges are required. Due to constraints imposed by the 4-way unicast key handshake state machine, this also implies two 4-way handshake and EAP method exchanges. Link layers such as IEEE 802.11 adhoc also do not support "tie breaking" wherein two hosts initiating authentication with each other will only go forward with a single authentication. This implies that even if 802.11 were to support a bi-directional group-key handshake, then two authentications, one in each direction, might still occur." ---------------------------------------------------------------- Issue 161: State Machine demultiplexing Submitter name: Florent Bersani Submitter email address: florent.bersani@francetelecom.com Date first submitted: July 21, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-July/001504.html Document: SM-04 Comment type: T Priority: S Section: Rationale/Explanation of issue: When two peers simultaneously perform EAP authentications (that is to say A acts as a peer in dialog #1 with B which acts as an authenticator and, at the same time, A acts as an authenticator in dialog #2 with B which acts as a peer) the EAP dialogs have to get demultiplexed: this can easily be done according to the EAP code field (responses go to the authenticator and other codes - requests, success and failure - go to the peer). The question is : who does this demultiplexing ? Should it be the lower layer (which then would have to read and understand the EAP layer) or the EAP state machine (which then should be modified, I think) ? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 28 06:41: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 GAA16868 for ; Tue, 28 Oct 2003 06:41:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 317E1580010; Tue, 28 Oct 2003 05:41:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 963D6580018; Tue, 28 Oct 2003 05:41:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34600580018 for ; Tue, 28 Oct 2003 05:40:50 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 027F5580010 for ; Tue, 28 Oct 2003 05:40:48 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1A69F6A909; Tue, 28 Oct 2003 13:40:47 +0200 (EET) Message-ID: <3F9E54C5.4020701@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] Proposed Resolution of Issue 188: Packet ordering References: In-Reply-To: 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: Tue, 28 Oct 2003 13:36:37 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Looks OK. Thanks. --Jari Bernard Aboba wrote: > The text of Issue 188 is enclosed below. The proposed fix is as follows: > > Add to Section 3.1, at the end of item [6]: > > Reordering, if it occurs, will typically result in an EAP > authentication failure, causing EAP authentication to be > rerun. In an environment in which reordering is likely, > it is therefore expected that EAP authentication failures > will be common. It is RECOMMENDED that EAP only be run > over lower layers that provide ordering guarantees; > running EAP over raw IP or UDP transport is NOT > RECOMMENDED. Encapsulation of EAP within RADIUS > [RFC3579] satisfies ordering requirements, since > RADIUS is a "lockstep" protocol that delivers > packets in order. > ---------------------------------------------------------- > Issue 188: Packet Ordering > Submitter name: Margaret Wasserman > Submitter email address: Margaret.Wasserman@nokia.com > Date first submitted: October 23, 2003 > Reference: > Document: RFC 2284bis-06 > Comment type: T > Priority: S > Section: 2.3 > Rationale/Explanation of issue: > > Is the current wording/diagram in the document clear > enough with respect to the need for IP-based > transports to include a mechanism to ensure packet order? > Or do you think that we should add a couple of sentences > to make this more explicit and explain what "/IP" means > in Figure 2? > > _______________________________________________ > 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 Oct 28 11:27: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 LAA05317 for ; Tue, 28 Oct 2003 11:27:10 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B80E58011A; Tue, 28 Oct 2003 10:27:19 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 26A44580109; Tue, 28 Oct 2003 10:27:12 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35940580117 for ; Tue, 28 Oct 2003 10:26:56 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id DA183580029 for ; Tue, 28 Oct 2003 10:26:47 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9SFnxL31081 for ; Tue, 28 Oct 2003 07:50:00 -0800 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] EAP WG agenda for IETF 58, Take Three 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, 28 Oct 2003 07:49:59 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Extensible Authentication Protocol (eap) WG Chair(s): Bernard Aboba Jari Arkko Monday, November 10, 2003 1930 - 2200 Preliminaries (10 minutes) Agenda Bashing Bluesheets Minutes Document Status Issue Status: http://www.drizzle.com/~aboba/EAP/eapissues.html RFC 2284bis (10 minutes), Henrik Lefkowetz http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.txt EAP State Machine (20 minutes), TBD http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.txt Network Selection, Farid Adrangi (10 minutes) http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt EAP Key Framework, Bernard Aboba (40 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-00.txt EAP Key Derivation for Multiple Applications, Joe Salowey (10 minutes) http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-02.txt PEAPv2, Jose Salowey (10 minutes) http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-07.txt EAP SIM/AKA, TBD (10 minutes) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-11.txt http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-10.txt EAP Smartcard, Pascal Urien (10 minutes) http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-03.txt Roadmap (10 minutes), WG Chairs and ADs _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Oct 28 15:26: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 PAA22959 for ; Tue, 28 Oct 2003 15:26:07 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14AE3580019; Tue, 28 Oct 2003 14:26:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78E4B58001D; Tue, 28 Oct 2003 14:26:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6CF4358001D for ; Tue, 28 Oct 2003 14:25:25 -0600 (CST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 1E107580019 for ; Tue, 28 Oct 2003 14:25:23 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22672; Tue, 28 Oct 2003 15:25:11 -0500 (EST) Message-Id: <200310282025.PAA22672@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-keying-01.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: Tue, 28 Oct 2003 15:25:11 -0500 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 : EAP Key Management Framework Author(s) : B. Aboba Filename : draft-ietf-eap-keying-01.txt Pages : 55 Date : 2003-10-28 This document provides a framework for EAP key management, including a statement of applicability and guidelines for generation, transport and usage of EAP keying material. Algorithms for key derivation or mechanisms for key transport are not specified in this document. Rather, this document provides a framework within which algorithms and transport mechanisms can be discussed and evaluated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-keying-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-keying-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28151328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-keying-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-keying-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28151328.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 Oct 28 22:38: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 WAA21271 for ; Tue, 28 Oct 2003 22:38:05 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 47C2D580024; Tue, 28 Oct 2003 21:38:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CF77580017; Tue, 28 Oct 2003 21:38:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A383A580017 for ; Tue, 28 Oct 2003 21:37:09 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 1E757580013 for ; Tue, 28 Oct 2003 21:37:08 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9T30JQ05227; Tue, 28 Oct 2003 19:00:19 -0800 From: Bernard Aboba To: eap@frascone.com Cc: housley@vigilsec.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 185: Key Framework Review 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, 28 Oct 2003 19:00:19 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 185 is enclosed below. The proposed fix is as follows: In Section 1.2, change: " AAA-Key A key derived by the EAP peer and EAP server and transported to the authenticator. In 802.11 terminology, the first 32 octets of the AAA-Key is known as the Pairwise Master Key (PMK)." To: " AAA-Key A key derived by the EAP peer and EAP server and transported to the authenticator. In IEEE 802.11 terminology, the first 32 octets of the AAA-Key is known as the Pairwise Master Key (PMK)." In Section 1.3.3, change: "[2] Generation of fresh transient session keys. This is typically" To: "[2] Generation of fresh transient session keys (TSKs). This is typically" In Section 1.4 change: Within EAP, "fast handoff" is defined as a conversation in which the EAP exchange (phase 1a) and associated AAA passthrough is bypassed, so as to reduce latency. Depending on the fast handoff mechanism, AAA-Key transport (phase 1b) may also be bypassed in favor a context transfer (see [IEEE80211f] and [I-D.aboba-802-context]) or it may be provided in a pre-emptive manner as in [IEEE-03-084] and [I-D.irtf-aaaarch-handoff]." To: "Within EAP, "fast handoff" is defined as a conversation in which the EAP exchange (phase 1a) and associated AAA passthrough is bypassed, so as to reduce latency. Depending on the fast handoff mechanism, AAA-Key transport (phase 1b) may also be bypassed or it may be provided in a pre-emptive manner as in [IEEE-03-084] and [I-D.irtf-aaaarch-handoff]." In Section 1.4.1, change: "Similarly, in a network where access is restricted based on the day and time, SSID, Calling-Station-Id or other factors, unless the" To: "Similarly, in a network where access is restricted based on the day and time, Service Set Identifier (SSID), Calling-Station-Id or other factors, unless the" In Section 2.2 change: "Master Session Key (MSK) Keying material (at least 64 octets) that is derived between the EAP client and server and exported by the EAP method." 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." Delete the existing definition of the EMSK. Change: "Initialization Vector (IV) A quantity of at least 64 octets, suitable for use in an initialization vector field, that is derived between the EAP client and server. Since the IV is a known value in methods such as EAP-TLS [RFC2716], it cannot be used by itself for computation of any quantity that needs to remain secret. As a result, its use has been deprecated and EAP methods are not required to generate it." To: "Initialization Vector (IV) A quantity of at least 64 octets, suitable for use in an initialization vector field, that is derived between the EAP client and server. Since the IV is a known value in methods such as EAP-TLS [RFC2716], it cannot be used by itself for computation of any quantity that needs to remain secret. As a result, its use has been deprecated and EAP methods are not required to generate it. However, when it is generated it MUST be unpredictable." In Section 2.3, Figure 3, delete ", TEK Deriv." from the figure. ------------------------------------------------------- Issue 185: Key Framework Review Submitter name: Russ Housley Submitter email address: housley@vigilsec.com Date first submitted: October 15, 2003 Reference: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-00-comment.txt Document: Keying Framework-00 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Here is my review of the Key Framework document: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-00-comment.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 29 10:09: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 KAA11118 for ; Wed, 29 Oct 2003 10:09:09 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C0E658001C; Wed, 29 Oct 2003 09:09:11 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E287C58001D; Wed, 29 Oct 2003 09:09:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7943758001C for ; Wed, 29 Oct 2003 09:08:45 -0600 (CST) Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [195.20.116.97]) by mail.frascone.com (Postfix) with ESMTP id CF0BD580013 for ; Wed, 29 Oct 2003 09:08:43 -0600 (CST) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.16) with SMTP id h9TF8fEU029192 for ; Wed, 29 Oct 2003 17:08:41 +0200 (EET) Received: (qmail 25933 invoked from network); 29 Oct 2003 15:08:41 -0000 Received: from unknown (HELO tehdas) ([10.1.49.92]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 29 Oct 2003 15:08:41 -0000 Received: from ltarkkal by tehdas with local (Exim 3.36 #1 (Debian)) id 1AEtlP-00042G-00; Wed, 29 Oct 2003 19:05:43 +0200 From: Lauri Tarkkala To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 188: Packet ordering Message-ID: <20031029170543.GA15489@tehdas> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i 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: Wed, 29 Oct 2003 19:05:43 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Mon, Oct 27, 2003 at 07:18:20PM -0800, Bernard Aboba wrote: > Issue 188: Packet Ordering > Submitter name: Margaret Wasserman > Submitter email address: Margaret.Wasserman@nokia.com > Date first submitted: October 23, 2003 > Reference: > Document: RFC 2284bis-06 > Comment type: T > Priority: S > Section: 2.3 > Rationale/Explanation of issue: > > Is the current wording/diagram in the document clear > enough with respect to the need for IP-based > transports to include a mechanism to ensure packet order? > Or do you think that we should add a couple of sentences > to make this more explicit and explain what "/IP" means > in Figure 2? Am I missing something here, but the bis specification is currently stating that EAP is a lock-step protocol. In this case, assuming nobody is doing optimizations based on predicting peer responses, there should be no need for an ordering guarantee. That said, requiring that the lower layer provides an ordering guarantee is a good idea considering the heritage of EAP. I do not however see this as much of an issue for new (or upto-date) implementations, which we would be talking about here. Lauri -- Lauri Tarkkala SSH Communications Security Corp http://www.ssh.com/ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 29 10:39: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 KAA14247 for ; Wed, 29 Oct 2003 10:39:03 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A800580013; Wed, 29 Oct 2003 09:39:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D6F758001E; Wed, 29 Oct 2003 09:39:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E274A58001C for ; Wed, 29 Oct 2003 09:38:17 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 407A7580013 for ; Wed, 29 Oct 2003 09:38:16 -0600 (CST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9TFcEP28503 for ; Wed, 29 Oct 2003 17:38:14 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 Oct 2003 17:38:13 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 29 Oct 2003 17:38:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Proposed Resolution of Issue 188: Packet ordering Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122314@esebe023.ntc.nokia.com> Thread-Topic: [eap] Proposed Resolution of Issue 188: Packet ordering Thread-Index: AcOeLsTQ19jKZiRIQBCIQEcP5/mAqAAAo0Hw From: To: Cc: X-OriginalArrivalTime: 29 Oct 2003 15:38:13.0784 (UTC) FILETIME=[AA37C180:01C39E32] 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: Wed, 29 Oct 2003 17:38:13 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Lauri Tarkkala wrote: > Am I missing something here, but the bis specification > is currently stating that EAP is a lock-step protocol. >=20 > In this case, assuming nobody is doing optimizations > based on predicting peer responses, there should > be no need for an ordering guarantee.=20 >=20 > That said, requiring that the lower layer provides > an ordering guarantee is a good idea considering the > heritage of EAP. I do not however see this as much > of an issue for new (or upto-date) implementations, > which we would be talking about here. Lower layer ordering guarantees are needed because the=20 Identifier field is not required to be ordered. If messages can be reordered, the peer can't necessarily distinguish a new EAP Request from a reordered retransmission of an old request. See http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-02.txt, Appendix A for a concrete example. Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 29 12:07: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 MAA19506 for ; Wed, 29 Oct 2003 12:07:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8EF54580109; Wed, 29 Oct 2003 11:07:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5D77058001D; Wed, 29 Oct 2003 11:07:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C3CD58001D for ; Wed, 29 Oct 2003 11:06:03 -0600 (CST) Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [195.20.116.97]) by mail.frascone.com (Postfix) with ESMTP id 7D69058001C for ; Wed, 29 Oct 2003 11:06:01 -0600 (CST) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.16) with SMTP id h9TH60EU001468 for ; Wed, 29 Oct 2003 19:06:00 +0200 (EET) Received: (qmail 8918 invoked from network); 29 Oct 2003 17:06:00 -0000 Received: from unknown (HELO tehdas) ([10.1.49.92]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 29 Oct 2003 17:06:00 -0000 Received: from ltarkkal by tehdas with local (Exim 3.36 #1 (Debian)) id 1AEvaw-0004JI-00; Wed, 29 Oct 2003 21:03:02 +0200 From: Lauri Tarkkala To: Pasi.Eronen@nokia.com Cc: ltarkkal@ssh.com, eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 188: Packet ordering Message-ID: <20031029190302.GA16448@tehdas> References: <052E0C61B69C3741AFA5FE88ACC775A6122314@esebe023.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122314@esebe023.ntc.nokia.com> User-Agent: Mutt/1.5.4i 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: Wed, 29 Oct 2003 21:03:02 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Wed, Oct 29, 2003 at 05:38:13PM +0200, Pasi.Eronen@nokia.com wrote: > Lauri Tarkkala wrote: > > Am I missing something here, but the bis specification > > is currently stating that EAP is a lock-step protocol. > > > > In this case, assuming nobody is doing optimizations > > based on predicting peer responses, there should > > be no need for an ordering guarantee. > > > > That said, requiring that the lower layer provides > > an ordering guarantee is a good idea considering the > > heritage of EAP. I do not however see this as much > > of an issue for new (or upto-date) implementations, > > which we would be talking about here. > > Lower layer ordering guarantees are needed because the > Identifier field is not required to be ordered. If messages > can be reordered, the peer can't necessarily distinguish > a new EAP Request from a reordered retransmission of an > old request. It is not required to be ordered by the specification, but this does not mean that an implementation can not place additional constraints upon it. Because the protocol is lock-step, the authenticator is the party driving the protocol and is free to e.g. place a partial order upon the (, ) pair. Like I previously said, considering the heritage of EAP, it probably is a good idea to require EAP transports to provide ordering guarantees. IF the historical baggage were not to exist, I do feel that freeing the authenticator implementor from thinking about these issues by requiring a total order on all packets might be a bit heavy-handed... ;-) Lauri -- Lauri Tarkkala SSH Communications Security Corp http://www.ssh.com/ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 29 13:49: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 NAA26465 for ; Wed, 29 Oct 2003 13:49:03 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22AEC580013; Wed, 29 Oct 2003 12:49:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B07CF58001C; Wed, 29 Oct 2003 12:49:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 27C4158001C for ; Wed, 29 Oct 2003 12:48:50 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 00EC5580013 for ; Wed, 29 Oct 2003 12:48:49 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 8264A6A90B; Wed, 29 Oct 2003 20:48:44 +0200 (EET) Message-ID: <3FA0050B.9000309@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: Lauri Tarkkala Cc: Pasi.Eronen@nokia.com, eap@frascone.com Subject: Re: [eap] Proposed Resolution of Issue 188: Packet ordering References: <052E0C61B69C3741AFA5FE88ACC775A6122314@esebe023.ntc.nokia.com> <20031029190302.GA16448@tehdas> In-Reply-To: <20031029190302.GA16448@tehdas> 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: Wed, 29 Oct 2003 20:20:59 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Lauri Tarkkala wrote: > Like I previously said, considering the heritage of EAP, > it probably is a good idea to require EAP transports > to provide ordering guarantees. IF the historical Agreed. > baggage were not to exist, I do feel that freeing > the authenticator implementor from thinking about > these issues by requiring a total order on all packets > might be a bit heavy-handed... ;-) Absolutely. If we didn't have the baggage, the protocol would indeed look different ;-) But we do, so... --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 29 20:54: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 UAA19935 for ; Wed, 29 Oct 2003 20:54:03 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 283BA580109; Wed, 29 Oct 2003 19:54:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8261D58010A; Wed, 29 Oct 2003 19:54:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D75BA58010A for ; Wed, 29 Oct 2003 19:53:18 -0600 (CST) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by mail.frascone.com (Postfix) with ESMTP id A3FAC580109 for ; Wed, 29 Oct 2003 19:53:17 -0600 (CST) Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h9U1nrQ9017895 for ; Thu, 30 Oct 2003 01:49:53 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h9U1lUV03822 for ; Thu, 30 Oct 2003 01:47:31 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 M2003102917531410136 ; Wed, 29 Oct 2003 17:53:14 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 29 Oct 2003 17:53:14 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39E88.940C6D35" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: [eap] interpretation of the identity response Message-ID: <96D13222E704DC4D868F0009F0EE53E10AC485@orsmsx410.jf.intel.com> Thread-Topic: [eap] interpretation of the identity response Thread-Index: AcOeiJQDcUSkBQQlSwaIKr8zLtLZdw== From: "Adrangi, Farid" To: "Bernard Aboba" , Cc: "Lortz, Victor" , "Puthenkulam, Jose P" , X-OriginalArrivalTime: 30 Oct 2003 01:53:14.0015 (UTC) FILETIME=[94782AF0:01C39E88] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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: Wed, 29 Oct 2003 17:53:13 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C39E88.940C6D35 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Bernard/Jari: =20 I have a quick question regarding 2284bis-06 draft. Currently, the draft does not specify any rules on how the EAP server should interpret an identity response (in particular where it is indicated in NAI format) to extract the identity to be authenticated. For example, given the following NAI Eng%nancy@bigu.edu , does the EAP server use the nancy@bigu.edu portion or the whole string as the ID for authenticating the user? Or another NAI example, say you have ipass/nancy@bigu.edu (where the ipass prefix is used to indicate the RADIUS AAA server in an Access Network how to route the RADIUS packets) will the EAP server use nancy@bigu.edu portion or the whole string?=20 =20 Thanks for your time. =20 BR, Farid =20 ------_=_NextPart_001_01C39E88.940C6D35 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Bernard/Jari:

 

I have a quick question regarding 2284bis-06 = draft.  Currently, the draft does not specify any rules on how the EAP server should = interpret an identity response (in particular where it is indicated in NAI format) to extract the identity to be authenticated.  For example, given the = following NAI Eng%nancy@bigu.edu, =  does the EAP server use the nancy@bigu.edu portion or the whole string as the ID for authenticating the user?  Or = another NAI example, say you have ipass/nancy@bigu.edu (where the ipass prefix is used to indicate the RADIUS AAA server in an = Access Network how to route the RADIUS packets) will the EAP server use nancy@bigu.edu portion or the whole = string?

 

Thanks for your time.

 

BR,

Farid

 

=00 ------_=_NextPart_001_01C39E88.940C6D35-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 29 21:20: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 VAA20723 for ; Wed, 29 Oct 2003 21:20:03 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7359E580109; Wed, 29 Oct 2003 20:20:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 193E658010A; Wed, 29 Oct 2003 20:20:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5BA3F58010A for ; Wed, 29 Oct 2003 20:19:39 -0600 (CST) 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 1611C580109 for ; Wed, 29 Oct 2003 20:19:38 -0600 (CST) Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Oct 2003 18:22:04 -0800 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 h9U2JXjP021253; Wed, 29 Oct 2003 18:19:34 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.64.27]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 18:24:26 -0800 From: "Joseph Salowey" To: "'Adrangi, Farid'" , "'Bernard Aboba'" , Cc: "'Lortz, Victor'" , "'Puthenkulam, Jose P'" , Subject: RE: [eap] interpretation of the identity response Message-ID: <009f01c39e8c$41c93020$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A0_01C39E49.33A5F020" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <96D13222E704DC4D868F0009F0EE53E10AC485@orsmsx410.jf.intel.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 30 Oct 2003 02:24:27.0114 (UTC) FILETIME=[F0EC64A0:01C39E8C] 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: Wed, 29 Oct 2003 18:19:32 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_00A0_01C39E49.33A5F020 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think the processing of the identity response is up to the mechanism. If the NAI is decorated in non-standard means that is not known to the home AAA this can be a problem (it is also not within the NAI specification). Many mechanisms have a way to request or determine identity independent of the EAP identity response (EAP-SIM,EAP-AKA,EAP-TLS,EAP-MCSHAPv2). I If I had my preference I would use the identity response for routing only and ignore the user identity in the identity response. It should be a recommendation that mechanisms provide a way to obtain identity outside of the identity response. Joe -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Adrangi, Farid Sent: Wednesday, October 29, 2003 5:53 PM To: Bernard Aboba; jarkko@piuha.net Cc: Lortz, Victor; Puthenkulam, Jose P; eap@frascone.com Subject: [eap] interpretation of the identity response Hello Bernard/Jari: I have a quick question regarding 2284bis-06 draft. Currently, the draft does not specify any rules on how the EAP server should interpret an identity response (in particular where it is indicated in NAI format) to extract the identity to be authenticated. For example, given the following NAI Eng%nancy@bigu.edu , does the EAP server use the nancy@bigu.edu portion or the whole string as the ID for authenticating the user? Or another NAI example, say you have ipass/nancy@bigu.edu (where the ipass prefix is used to indicate the RADIUS AAA server in an Access Network how to route the RADIUS packets) will the EAP server use nancy@bigu.edu portion or the whole string? Thanks for your time. BR, Farid ------=_NextPart_000_00A0_01C39E49.33A5F020 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
I=20 think the processing of the identity response is up to the = mechanism.  If=20 the NAI is decorated in non-standard means that is not known to the home = AAA=20 this can be a problem (it is also not within the NAI specification). = Many=20 mechanisms have a way to request or determine identity independent of = the EAP=20 identity response (EAP-SIM,EAP-AKA,EAP-TLS,EAP-MCSHAPv2).   = I If=20 I had my preference I would use the identity response for routing only = and=20 ignore the user identity in the identity response.  It should = be a=20 recommendation that mechanisms provide a way to obtain identity outside = of the=20 identity response. 
 
Joe
-----Original Message-----
From:=20 eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of = Adrangi, Farid
Sent: Wednesday, October 29, 2003 5:53=20 PM
To: Bernard Aboba; jarkko@piuha.net
Cc: Lortz, = Victor;=20 Puthenkulam, Jose P; eap@frascone.com
Subject: [eap] = interpretation=20 of the identity response

Hello=20 Bernard/Jari:

 

I have a quick question = regarding=20 2284bis-06 draft.  Currently, the draft does not specify any = rules on how=20 the EAP server should interpret an identity response (in particular = where it=20 is indicated in NAI format) to extract the identity to be = authenticated. =20 For example, given the following NAI Eng%nancy@bigu.edu, =  does the EAP=20 server use the nancy@bigu.edu = portion or=20 the whole string as the ID for authenticating the user?  Or = another NAI=20 example, say you have ipass/nancy@bigu.edu (where = the ipass=20 prefix is used to indicate the RADIUS AAA server in an Access Network = how to=20 route the RADIUS packets) will the EAP server use nancy@bigu.edu portion or the whole = string?

 

Thanks for your=20 time.

 

BR,

Farid

 

------=_NextPart_000_00A0_01C39E49.33A5F020-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 29 21:55: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 VAA21641 for ; Wed, 29 Oct 2003 21:53:16 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3857B580133; Wed, 29 Oct 2003 20:53:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5563858012D; Wed, 29 Oct 2003 20:53:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9E58258012D for ; Wed, 29 Oct 2003 20:52:10 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 17BC9580109 for ; Wed, 29 Oct 2003 20:52:07 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9U2FCZ22366 for ; Wed, 29 Oct 2003 18:15:13 -0800 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 180: Conversation Overview 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, 29 Oct 2003 18:15:12 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 180 is enclosed below. The proposed resolution is as follows: Add Pasi Eronen as an author. Replace the text of section 1.3 with the following: 1.3. Conversation Overview Where EAP key derivation is supported, EAP authentication is typically a component of a four phase exchange: Discovery (phase 0) EAP authentication (phase 1a) Access authorization (phase 1b) Service authentication (phase 2) In the discovery phase (phase 0), the EAP peer and authenticator locate each other. This may include a conversation in which they contact each other, and then exchange some information about the service to be provided. For example, one of the parties may indicate its willingness to provide a service (and to perform the EAP authenticator role), and the other party requests access to that service (assuming the EAP peer role). Next, the EAP peer and EAP server authenticate each other (phase 1a) and derive a shared key (the AAA-Key). Where a backend authentication server is present, the authenticator forward EAP packets between the peer and backend authentication server (EAP server). This enables deployment of new authentication methods without requiring new code on the authenticator. Partially overlapping with this exchange is a second exchange (phase 1b), between the authenticator and the backend authentication server. In this exchange, the authenticator and backend authentication server authenticate each other via the AAA protocol, and the authenticator sends to the backend authentication server information about the service requested by the peer (in the form of AAA protocol attributes). When phase 1a completes, the backend authentication server indicates to the authentication whether the service is to be provided (Accept/Reject), more detailed information on the service to be provided (AAA authorization attributes), and keying material (the AAA-Key) to be used in the derivation of Transient Session Keys (TSKs). Service authentication (phase 2) always occurs after the completion of EAP authentication (phase 1a) and access authorization (phase 1b). Some or all of the following features may be supported: [1] Network selection. Where multiple networks are advertised by an authenticator, it is necessary for the peer to explicitly indicate its desire to connect to one or more of the advertised networks. Since EAP does not include explicit network selection functionality, this function needs to be handled outside of EAP. [2] Secure association. On wireless networks, it may be desirable to enable "make before break" by allowing an EAP peer to authenticate and derive keys with an EAP server prior to its arrival at an authenticator. In such a situation, the successful completion of EAP authentication and key derivation does not necessarily imply that the peer wishes to be connected to the authenticator that it has been communicating with. Rather, this commitment is signaled by the peer in a separate step, as part of service authentication (phase 2). The joining of the peer to a network is known as "association" and where the associated packets are integrity protected and authenticated, the exchange is known as a "secure association". [3] Mutual proof of possession of the AAA-Key. This demonstrates that both the EAP peer and authenticator have been authenticated and authorized by the AAA server. Since mutual proof of possession is not the same as mutual authentication, the EAP peer cannot verify authenticator assertions (including the authenticator identity) as a result of this exchange. [4] Secure negotiation of capabilities. During phase 2, the peer and authenticator may exchange more service parameters (possibly beyond those exchanged during phase 0) and protect some or all of these parameters using the AAA-Key. By securely negotiating session parameters, the service authentication protocol protects against spoofing during the discovery phase and ensures that the peer and authenticator are in agreement about how data is to be secured. [5] Generation of fresh transient session keys. This is typically accomplished via the exchange of nonces, and includes generation of both unicast and multicast (where required) session keys. By not using the AAA-Key directly to protect data, protection is provided against compromise of the AAA-Key. By guaranteeing freshness of TSKs it is assured that these keys are not reused. An attacker not knowing the AAA-Key is unable to calculate the TSKs. [6] Key activation and deletion. Once the TSKs are derived, it is necessary to synchronize their activation. The issue of synchronization also arises during rekey, when it is desirable to create a new TSK prior to deleting the old one. The phases and the relationship between the parties is illustrated below. EAP peer Authenticator Auth. Server -------- ------------- ------------ <----------------------------> Discovery (phase 0) <------------------------------------------------------> EAP authentication (phase 1a) <-------------------------> Access authorization (phase 1b) <----------------------------> Service authentication (phase 2) 1.3.1 A concrete example: IEEE 802.11i Extended Service Set (ESS) o Phase 0: The Station (peer) discovers the Access Point (authenticator) and its associated capabilities by listening to Beacon messages, and/or a Probe Request/Response exchange with the Access Point. Capabilities learned in phase 0 include the SSID, data rates, supported ciphersuites, hop patterns and other PHY parameters. o Phase 1a is initiated by the station either by sending an EAPOL-Start message to the Access Point (pre-authentication) or by completing an Association/Reassociation Request/Response exchange with the Access Point. The Association/Reassociation exchange includes selection of the network to which the station wishes to be attached, as well as the associated capabilities of that network. However, since this exchange is not secured, successful completion cannot be considered definitive. The Access Point (AP) then sends an EAP-Request (most likely an EAP-Request/Identity) to the Station, encapsulated in an EAP over Wireless LAN (EAPOW) frame. The EAP peer and server then authenticate each other. For example, if EAP-TLS is used, they exchange certificates, verify that the certificates are valid and belong to the expected party, and prove possessoin of the corresponding private keys. This exchange generates a shared key between them. o Phase 1b typically uses RADIUS, which may use a shared secret and/or IPsec to provide per-packet authentication and integrity protection. Where IPsec is used, per-packet confidentiality can also be provided; where a shared secret is used confidentiality can only be provided for selected attributes (such as the AAA-Key). The Access Point sends a RADIUS Access-Request packet to the backend authentication server containing attributes (such as the NAS-Port-Type, Calling-Station-Id and Called-Station-Id) describing the service that is being requested. When phase 1a completes, the backend authentication server communicates its access decision to the Access Point (Access-Accept/Reject). If access is to be provided, the Access-Accept includes service authorizations such as those described in [RFC3580]. This may include parameters such as Session-Timeout, as well as the AAA-Key. o Phase 2 includes the four-way and group key handshakes. These exchanges protect service parameters (MAC addresses, Beacon/Probe Response Information Elements, selected ciphersuite) and derive Transient Session Keys (TSKs) used to protect subsequent data traffic. Since the 4-way handshake includes a protected parameter exchange it enables the station to definitively confirm the results of the unprotected Association/Reassociation exchange, including network selection (if the SSID is included in the 4-way handshake). After phase 2, the parties protect the 802.11 data frames utilizing the selected ciphersuite (TKIP or AES CCMP) and Transient Session Keys. Security services include per-packet authentication, integrity protection, confidentiality and replay protection. 1.3.2 Second example: IKEv2/IPsec This example assumes that IKEv2 [IKEv2] and IPsec [RFC2401] are used to to provide access to a Virtual Private Network (VPN), and that EAP is used for authentication. o Phase 0: Typically the VPN client (initiator) is configured with the VPN gateway name or address, but it also may be possible for it to be discovered using mechanisms such as DNS KX [RFC2230], or SRV [RFC 2782] Resource Records. The client contacts the gateway and they exchange Diffie-Hellman parameters, nonces and select an IKEv2 ciphersuite. The client also indicates the willingness to use EAP by leaving out the AUTH payload from the third message. o Phase 1a completes. Typically with IKEv2 it is likely that an EAP method utilizing password or hardware token authentication will be used. o Phase 1b completes and the backend authentication server provides the authenticator with the AAA-Key as well as VPN authorization attributes, such as those defined in [RFC2548]. o Phase 2: In this phase IKE and IPsec SAs are negotiated. When EAP is used for authentication within IKEv2, the AAA-Key is not required for TSK derivation since the Diffie-Hellman exchange is used for this purpose. However the AAA-Key is used to cryptographically bind the EAP and IKEv2 exchanges. This is done by computing a MIC of the Diffie-Hellman parameters and nonces (and some other information) exchanged in phase 0. This implicitly protects the parameters and the rest of the conversation as well. This phase also includes negotiation of service parameters such as the client IP address, what IP traffic will be protected, what ciphersuites will be used, and so on. After this, data traffic is protected by IPsec ESP [RFC2406] or AH [RFC2402]. 1.3.3 PPP over Ethernet PPP over Ethernet (PPPoE) [RFC2516] provides the ability to connect a network of hosts to a remote Access Concentrator. To provide a point-to-point connection over Ethernet, each PPP session must discover the MAC address of the remote peer and establish a unique session identifier. PPPoE includes its own Discovery stage (Phase 0) in which the peer can discover the capabilities of available Access Concentrators. The peer broadcasts an Initiation packet, one or more Access Concentrators send Offer packets. The peer then selects an Access Concentrator and sends sends a unicast Session Request packet to it. The selected Access Concentrator then replies with a Confirmation packet. after which the peer proceeds to the PPP Session Stage, where authentication can be carried out. The Session Request/Confirmation exchange confirms the establishment of an association between the peer and authenticator; however, since the exchange is not secured it is vulnerable to attack. Once a PPP Session is established, EAP authentication can be selected and a method supporting key derivation can be carried out enabling the generation of keying material (phase 1a). If a backend authentication server is available, it can then transport the AAA-Key to the authenticator (Phase 1b). Subsequent to PPP authentication, a ciphersuite such as MPPE [RFC3078] can be negotiated in order to enable encryption of the PPP session. Use of EAP keying material for derivation of transient session keys for MPPE is described in [RFC3079]. 1.4 Conversation limitations It is worthwhile to point out two important limitations. The first one is rather trivial, and applies only to some phase 2 protocols. However, the second one is much less obvious, and is more a fundamental limitation of the EAP design. 1.4.1 Protection of service parameters in phase 2 Some media (such as PPPoE, see above) may not include a Phase 2 exchange, and even where a Phase is included, it may not protect all service parameters. This allows an attacker without access to the AAA-Key to interfere in the negotiation of service parameters, disrupting subsequent communications. IEEE 802.11i [IEEE80211i] supports but does not require protection of the SSID or capabilities such as the data rates or PHY-specific parameters within the 4-way handshake. Since IEEE 802.11 management frames are unprotected (including the Association/Reassociation exchange) an implementation that does not securely include negotiated capability Information Elements (IEs) within the 4-way handshake is vulnerable to an attack involving spoofed management frames. Such an attack could convince the station and AP to connect to an undesired network at inappropriate rates, disable use of power management features, etc. In PPPoE the Discovery and Selection phases are not protected, and the transient session keys are derived directly from the AAA-Key, without an additional "secure association" protocol step. This means that the freshness of the TSKs are not guaranteed if the AAA-Key is reused; it also implies that the discovery, network selection and ciphersuite negotiation phases can be disrupted by an attacker, since there is no provision for secure capabilities negotiation. Since PPP ECP [RFC1968] does not support protected ciphersuite negotiation, a "downgrade attack" can be carried out in which an attacker can cause a weaker ciphersuite to be selected. In general, enabling protected parameter negotiation is an important part of the design of the phase 2 protocol, and depends on a threat analysis in order to determine what parameters require protection. 1.4.2 Independence of phases 1a and 1b Currently, phases 1a and 1b are (almost) independent of each other. They are usually carried inside the same RADIUS packets, but in an important sense they are still independent. For example, it is possible to terminate authentication on the EAP authenticator while still utilizing AAA for authorization, so that EAP packets would not "passthrough" the authenticator even though a AAA exchange would still be carried out between the authenticator and backend authentication server. As a result, the backend authentication server cannot restrict the service parameters used by the authenticator. A malicious or compromised authenticator trusted by the backend authentication server can present any set of service parameters it wants to the peer. Protecting these parameters within phase 2 does not prevent this attack since protection is achieved using a key known to the authenticator (the attacker). Leaving the service parameters to the authenticator makes sense in many situations. For example in IEEE 802.11 the authenticator (AP) has knowledge of what data rates, hop patterns or ciphersuites it supports, while the backend authentication server may not have this information. As a result, the backend authentication server may only be capable of providing general guidelines as to what services can be provided, but not a detailed service specification. However, there are situations in which the backend authentication server may wish to restrict some particular service parameters. For example, currently an IEEE 802.11 Access Point advertising the SSID "Joe's Hotspot" could advertise the SSID "Harry's Hotspot" or "Example Inc. Intranet" even though it did not really offer access to those networks. Similarly, an IKEv2 VPN gateway could claim to offer IEEE 802.11 access, and if the IKEv2 session is authenticated solely using EAP (without certificates), an Access Point could claim to offer IKEv2 services. Since the AAA server implicitly trusts the NAS to carry out the service that it requests, a AAA protocol by itself cannot provide protection against these kind of attacks. 1.4.3 Connecting phases 1a and 1b This vulnerability results from the separation of phases 1a and 1b, a fundamental limitation of the current EAP (and AAA) design. It appears that potential solutions involve three necessary components: a) The backend authentication server needs to obtain service parameters from the authenticator. b) The backend authentication server needs to determine whether the service parameters are appropriate/valid prior to providing the AAA-Key to the NAS. This typically will involve checking the service parameters against values corresponding to the claimed identity of the authenticator. c) The authenticator has to be prevented from communicating different service parameters to the peer and backend authentication server. Several potential solutions have been suggested: 1) Service parameters can be communicated within an EAP method exchange, protected using keys known only to the peer and EAP server. This allows the backend authentication server to check whether the values communicated by the EAP peer match those provided to it by the authenticator. 2) The backend authentication server (and the peer) could include the service parameters in the derivation of the AAA-Key, which in turn is derived from keying material known only to the peer and EAP server. This approach guarantees that the EAP peer and authenticator will only derive matching TSKs where the service parameters communicated by the authenticator to the EAP peer and server are the same. Mechanisms 1 and 2 each have their advantages and disadvantages. Mechanism 1 does not require changes to deployed AAA servers or authenticators, but depends on deployment of EAP methods which support service parameter verification. Since EAP methods are media independent, the method specification cannot be media specific, and thus cannot service parameters unique to a particular lower layer. This may make it difficult to create an EAP method that can verify arbitrary service parameters. Mechanism 2 requires chagnes to AAA servers and authenticators but can work with arbitrary EAP methods. However, its correct operation is heavily dependent on correct implementation of service parameter cannonicalization, since if implementations differ it is conceivable that they could derive different keys, even if the parameters advertised by the authenticator to the peer and backend authentication server match identically. 1.4.4 Repeating the conversation Subsequent to completion of the initial conversation, it is possible for Phases 0, 1 and/or 2 to be repeated. A mobile host may change its location and as a result may periodically initiate discovery of potential new points of attachment. Alternatively, a new authenticator may be placed into service and announce its presence on the network. As a result, a new Phase 0 exchange may be carried out. There are several reasons why a new phase 1a/1b conversation might be required. o Periodic reauthentication (and reauthorization) might be needed. In this case a new phase 1a/1b is used to check that the peer still has the correct credentials, and that authorization granted by the backend authentication server is still valid. Where the ciphersuite is known to be weak (such as IEEE 802.11 WEP), reauthentication may also be used to force the derivation of a new AAA-Key and corresponding Transient Session Keys. o The authenticator has lost the state associated with this service, or the state is no longer synchronized. This can occur if the authenticator is rebooted, or if the the service is moved to a different physical service element (see Sections 1.4.1 and 3.3.3 for more discussion). o New authorization may be required from the backend authentication server. This can be required if the peer attempts to change aspects of the service. Typically the service authorizations include a range of acceptable services that can be provided by the authenticator without requesting permission from the backend authentication server. However if the peer requests a service outside the authorized range, additional permission may be required. For example, in IEEE 802.11 it is possible for the Station (peer) and Access Point (authenticator) to renegotiate the data rate, or even the network to which the station is attached (new SSID in an Association-Request). If the new rate or SSID is not one which the backend authentication server had previously authorized a new phase 1a/1b exchange may be required. There are several reasons why a new phase 2 conversation might be required: o Periodic rekey. After expiration of the TSK lifetime it might be desirable to derive fresh TSKs without having to reauthenticate. o Deletion of service SAs. For example, a peer might be moving out of range and wish to notify the authenticator so that resources can be reclaimed. Add to informative references: [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-11.txt, Internet draft (work in progress), October 2003. [RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1996. [RFC2230] Atkinson, R., "Key Exchange Delegation Record for the DNS", RFC 2230, November 1997. [RFC2401] Atkinson, R. and Kent, S., "Security Architecture for the Internet Protocol", RFC 2401, November 1998 [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", RFC 2402, November 1998 [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998 [RFC2516] Mamakos, L., et. al., "A Method for Transmitting PPP over Ethernet (PPPoE)", RFC 2516, February 1999. [RFC2782] Gulbrandsen, A., Vixie, P., Esibov, L. "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000 [RFC3078] Pall, G. and G. Zorn, "Microsoft Point-to-Point Encryption (MPPE) Protocol", RFC 3078, March 2001. [RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)", RFC 3079, March 2001. ------------------------------------------------------------- Issue 180: Conversation Overview Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: October 14, 2003 Reference: Document: Keying framework Comment type: T Priority: 1 Section: 1.3 Rationale/Explanation of issue: Here is a proposed replacement for section 1.3 of the keying framework (note that this will most likely be revised during/after the interim meeting). 1.3. Conversation Overview Where EAP key derivation is supported, EAP authentication is typically a component of a four phase exchange: Discovery (phase 0) EAP authentication (phase 1a) Access authorization (phase 1b) Service authentication (phase 2) In the discovery phase (phase 0), the parties locate and contact each, and then exchange some information about the service to be provided. For instance, one of the parties may indicate its willingness to provide a service (and to perform the EAP authenticator role), and the other party requests access to that service (assuming the EAP peer role). Next, the EAP peer and backend authentication server authenticate each other (phase 1a) and derive a shared session key (later called Authorization Key). In this phase, the authenticator just forwards EAP packets between the peer and backend authentication server (note that in some cases, the authenticator and backend authentication server can be colocated in the same physical node). This feature of EAP enables deployment of new authentication methods without requiring development of new code on the authenticator. Partially overlapping with this exchange is a second exchange (phase 1b), between the authenticator and the backend authentication server. In this exchange, the authenticator and backend authentication server authenticate each other (using some other mechanism than EAP), and authenticator sends information about the service requested by the peer (typically inside some AAA protocol attributes). When the phase 1a has finished, the backend authentication server sends the authenticator information about whether the service should be provided or not, a key for protecting service communication (Authorization Key), and optionally more detailed instructions about the service to be provided. After both phases 1a and 1b are complete, the authenticator signals the peer it will allow access to the service (phase 2). Next, the peer and authenticator typically exchange more parameters about the service to be provided (most likely some were already exchanged during phase 0), protect at least some of these parameters using the Authorization Key, and agree about keys used to protect subsequent communication. The goal is to ensure that an attacker not knowing the Authorization Key cannot modify the protected parameters or calculate the keys that will be subsequently used. The phases and the relationship between the parties is illustrated below. EAP peer Authenticator Auth. Server -------- ------------- ------------ <----------------------------> Discovery (phase 0) <------------------------------------------------------> EAP authentication (phase 1a) <-------------------------> Access authorization (phase 1b) <----------------------------> Service authentication (phase 2) 1.3.1 A concrete example: IEEE 802.11i ESS (Details to be added; this is just a sketch) o Phase 0: Typically, the client (peer) discovers the access point (authenticator) by listening to Beacon messages, and requests access by sending an Assocation Request message. The service parameters exchanged in phase 0 include the SSID, data rates, supported ciphersuites, hop patterns (and other PHY parameters). The AP initiates phase 1a by sending an EAP Identity Request, encapsulated inside an EAPOL frame (though in some cases, the AP requests the backend authentication server to send this). o In phase 1a, the client and backend authentication server authenticate each other. For instance, if EAP-TLS is used, they both exchange certificates, verify that the certificates are valid and belong to the expected party, and prove that they know the corresponding private keys. This exchange also generates a shared key between them. o Phase 1b typically uses RADIUS. The RADIUS packets are authenticated either with RADIUS's own shared secret mechanism (Message-Authenticator), or IPsec. The access point sends an Access-Request message containing various service parameters (such as Service-Type, Calling-Station-Id, and Called-Station-Id). When phase 1a has finished, the backend authentication server gives permission for the service (Access-Accept), and sends e.g. Authorization Key and Session-Timeout. o Phase 2 includes the four-way handshake and group key handshake. These exchanges protect various service parameters (MAC addresses, RSN IE, selected ciphersuite) and produce keys for encrypting the actual traffic. After phase 2, the parties protect the 802.11 data frames with TKIP or CCMP (basically, encryption and MAC using the keys negotiated in phase 2, and sequence numbers for replay protection). 1.3.2 Second example: IKEv2/IPsec This example assumes a "road warrior VPN gateway" type situation where the IKEv2 SA is authenticated solely using EAP (no certificates are necessary). o Phase 0: IKEv2 doesn't usually use "discovery" in strict sense; instead, the client (initiator) is configured with the IPsec gateway's address or DNS name. The client contacts the gateway and they exchange Diffie-Hellman parameters, nonces and select an IKEv2 ciphersuite. The client also indicates the willingness to use EAP by leaving out the AUTH payload from the third message. o Phase 1a is similar as above (although it is likely that some other EAP method than EAP-TLS would be used). o Phase 1b is also very similar. Although no "RADIUS guidelines for IKEv2" document exists yet, RADIUS could be used with very small modifications (perhaps a new value for Service-Type and agreement about what to put in Calling-Station-Id/Called-Station-Id attributes). o Phase 2: In this phase, the client and the gateway authenticate the IKEv2 SA by using Authorization Key to compute a MAC of the Diffie-Hellman parameters and nonces (and some other information) exchanged in phase 0. This implicitly protects other parameters and the rest of the conversation as well. The service parameters negotiated next include details about client IP addresses, what IP traffic will be protected, what ciphersuites will be used, and so on. After this, the traffic is typically protected with ESP or AH. 1.3.3 Repeating the conversation There are several reasons why a service might require new phase 1a/1b conversation. o The service may require periodic reauthentication (and reauthorization): A new phase 1a/1b is used to check that the client still has the correct credentials, and the authorization granted by the backend authentication server is still valid. o Service parameters may have changed in a way that requires new authorization granted by the backend authentication server. For instance, suppose that the peer is allowed WLAN access with 802.11g physical layer; is the user allowed to switch to 802.11b? In this case, the answer is most likely yes--the backend authentication server isn't concerned with such small details. The peer and authenticator can negotiate this change in service parameters without having a new phase 1a/1b exchange. However, if the user is accessing SSID "Joe's HotSpot", does this authorization also give access to SSID "Example Inc. Intranet"? Most likely no--this is a detail the backend authentication server would like to know about. Depending on the service, there are service parameters between these two extremes: some of them matter when authorizing access, some are small details that can be negotiated freely between the peer and the authenticator. See Section X.X for more discussion about the authorization issues. o The authenticator has lost the state associated with this service, or the state is no longer synchronized. This may occur if, for instance, the authenticator is rebooted, or if the the service is moved to a different physical service element (see Sections X.X.X (TBD: correctness of fast handoff) and 3.3.3 for more discussion about this). 1.4 Conversation limitations It is worthwhile to point out two important limitations. The first one is rather trivial, and applies only to some phase 2 protocols. However, the second one is much less obvious, and is more a fundamental limitation of the EAP design. 1.4.1 Protection of service parameters in phase 2 Typically, phase 2 does not protect all parameters about the service. That is, even an attacker who does not know the Authorization Key can cause the parties to have a different idea of some service parameters. For instance, MPPE [RFC3078] does not protect the selected ciphersuite, potentially allowing a "downgrade attack" in which an attacker causes a weaker ciphersuite to be selected than would have been otherwise. To take a second example, IEEE 802.11i does not protect the SSID, capability information, data rates and PHY-specific parameters sent in Beacon messages. Of course, not all parameters necessarily need protection, since they are not useful in any practical attacks. Selecting what parameters to protect is a design decision in the phase 2 protocol, not a fundamental property of the EAP design. 1.4.2 Independence of phases 1a and 1b Currently, phases 1a and 1b are (almost) independent of each other. They are usually carried inside the same RADIUS packets, but in an important sense they are still independent. (At least in theory, it would be possible to have a system where the EAP packets would not go through the authenticator at all). The most important consequence of this is that the backend authentication server cannot restrict the service parameters used by the authenticator. A malicious or compromised authenticator (that is trusted by the backend authentication server) can present any set of service parameters it wants to the peer. The parameters can be protected at phase 2, but at this point they are protected using a key known to the authenticator. Leaving the service parameters to the authenticator actually makes sense in many situations. For instance, in WLANs the authenticator (AP) knows best what data rates, hop patterns or ciphersuites it supports. It would probably not be wise to require the backend authenticator server to know about these. However, there are situations where the backend authentication server might want to restrict some particular service parameters. For instance, currently a WLAN access point offering service for SSID "Joe's Hotspot" could also claim to offer service for SSID "Harry's Hotspot" or "Example Inc. Intranet". To take a second example, an IKEv2 gateway could claim to offer WLAN service, and if the IKEv2 session is authenticated solely using EAP (without any certificates), a WLAN access point could claim to offer IKEv2 services. 1.4.3 Connecting phases 1a and 1b The separation of phases 1a and 1b is a fundamental limitation of current EAP design. There have been discussions whether this limitation is actually a significant problem or not, and if so, how it could be solved. It seems that any solution involves three necessary components: 1) The backend authentication server has to get the values for those parameters. 2) The backend authentication server has to check that the authenticator it is sending the Authorization Key to is actually authorized to use those values. This most likely involves a database on the backend authentication server, connecting the authenticated identity of the authenticator (AAA SA, see Section 3.4) to the authorized values (such as SSID). 3) The authenticator has to be prevented from telling different values to the peer and backend authentication server. a) The values could communicated inside the EAP exchange, protected using keys known only to the peer and the backend authentication server (EAPv2 or Archie). b) The backend authentication server (and the peer) could include the values of these parameters when deriving the Authorization Key (from keys known only to the peer and the backend authentication server). _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 29 22:03:56 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 WAA21957 for ; Wed, 29 Oct 2003 22:03:46 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CCCBF58013B; Wed, 29 Oct 2003 21:00:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E5BEF5801A6; Wed, 29 Oct 2003 21:00:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9741C58012E for ; Wed, 29 Oct 2003 20:59:17 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id AD07A58012D for ; Wed, 29 Oct 2003 20:58:46 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9U2L7422692; Wed, 29 Oct 2003 18:21:08 -0800 From: Bernard Aboba To: Joseph Salowey Cc: "'Adrangi, Farid'" , jarkko@piuha.net, "'Lortz, Victor'" , "'Puthenkulam, Jose P'" , eap@frascone.com Subject: RE: [eap] interpretation of the identity response In-Reply-To: <009f01c39e8c$41c93020$0200000a@amer.cisco.com> Message-ID: References: <009f01c39e8c$41c93020$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Wed, 29 Oct 2003 18:21:07 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I think the processing of the identity response is up to the mechanism. > If the NAI is decorated in non-standard means that is not known to the > home AAA this can be a problem (it is also not within the NAI > specification). Many mechanisms have a way to request or determine > identity independent of the EAP identity response > (EAP-SIM,EAP-AKA,EAP-TLS,EAP-MCSHAPv2). I If I had my preference I > would use the identity response for routing only and ignore the user > identity in the identity response. It should be a recommendation that > mechanisms provide a way to obtain identity outside of the identity > response. Yes, I agree with this. A side benefit is that the Identity can be protected. Is there any text that needs to be added to RFC 2284bis to clarify this? We're in IETF last call now, so I'd encourage submission of an issue... _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 29 22: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 WAA22705 for ; Wed, 29 Oct 2003 22:25:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 264D85801A4; Wed, 29 Oct 2003 21:25:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 354CD580133; Wed, 29 Oct 2003 21:25:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C353580133 for ; Wed, 29 Oct 2003 21:24:15 -0600 (CST) Received: from struggle.mr.itd.umich.edu (struggle.mr.itd.umich.edu [141.211.144.25]) by mail.frascone.com (Postfix) with ESMTP id 62743580130 for ; Wed, 29 Oct 2003 21:24:14 -0600 (CST) Received: from [10.0.1.2] (pm478-47.dialip.mich.net [207.75.179.249]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id h9U3Nn9o006195; Wed, 29 Oct 2003 22:23:51 -0500 From: John Vollbrecht To: Joseph Salowey , "'Adrangi, Farid'" , "'Bernard Aboba'" , jarkko@piuha.net Cc: "'Lortz, Victor'" , "'Puthenkulam, Jose P'" , eap@frascone.com Subject: RE: [eap] interpretation of the identity response Message-ID: <5592435.1067466227@[10.0.1.2]> In-Reply-To: <009f01c39e8c$41c93020$0200000a@amer.cisco.com> References: <009f01c39e8c$41c93020$0200000a@amer.cisco.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: Wed, 29 Oct 2003 22:23:48 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit --On Wednesday, October 29, 2003 6:19 PM -0800 Joseph Salowey wrote: > > I think the processing of the identity response is up to the mechanism. > If the NAI is decorated in non-standard means that is not known to the > home AAA this can be a problem (it is also not within the NAI > specification). Many mechanisms have a way to request or determine > identity independent of the EAP identity response > (EAP-SIM,EAP-AKA,EAP-TLS,EAP-MCSHAPv2). I If I had my preference I > would use the identity response for routing only and ignore the user > identity in the identity response. It should be a recommendation that > mechanisms provide a way to obtain identity outside of the identity > response. > Joe > > I agree with your suggestion about independent identity in a method. I am wondering if the question about format is not also valid for routing. If the identity response is used for routing, then it must be understood by all routers. If a NAS or Proxy gets something it doesn't understand how to route it presumably throws it away or sends a Failure. The implication is that the Client and NAS and any intermediate servers need to have the same routing expectations. The spec does not say anything about how to break up the NAI for routing. I think it is pretty complicated to come up with an agreement about what such a standard would be, and I personally don't think it is necessary at this point. -- John > > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of > Adrangi, Farid Sent: Wednesday, October 29, 2003 5:53 PM > To: Bernard Aboba; jarkko@piuha.net > Cc: Lortz, Victor; Puthenkulam, Jose P; eap@frascone.com > Subject: [eap] interpretation of the identity response > > > > Hello Bernard/Jari: > > > > I have a quick question regarding 2284bis-06 draft. Currently, the draft > does not specify any rules on how the EAP server should interpret an > identity response (in particular where it is indicated in NAI format) to > extract the identity to be authenticated. For example, given the > following NAI Eng%nancy@bigu.edu, does the EAP server use the > nancy@bigu.edu portion or the whole string as the ID for authenticating > the user? Or another NAI example, say you have ipass/nancy@bigu.edu > (where the ipass prefix is used to indicate the RADIUS AAA server in an > Access Network how to route the RADIUS packets) will the EAP server use > nancy@bigu.edu portion or the whole string? > > > > Thanks for your time. > > > > BR, > > Farid > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Oct 29 22:29: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 WAA22790 for ; Wed, 29 Oct 2003 22:29:16 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 085205801A1; Wed, 29 Oct 2003 20:53:25 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35747580109; Wed, 29 Oct 2003 20:53:19 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 888BA580109 for ; Wed, 29 Oct 2003 20:52:54 -0600 (CST) Received: from hermes.hd.intel.com (fmr09.intel.com [192.52.57.35]) by mail.frascone.com (Postfix) with ESMTP id CD5B658012D for ; Wed, 29 Oct 2003 20:52:52 -0600 (CST) Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h9U2nTQ9006147 for ; Thu, 30 Oct 2003 02:49:29 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h9U2l6V24202 for ; Thu, 30 Oct 2003 02:47:06 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003102918524823204 ; Wed, 29 Oct 2003 18:52:48 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 29 Oct 2003 18:52:48 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39E90.E64DE2A4" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] interpretation of the identity response Message-ID: <96D13222E704DC4D868F0009F0EE53E10AC486@orsmsx410.jf.intel.com> Thread-Topic: [eap] interpretation of the identity response Thread-Index: AcOejEaCPSj1Q+8lRam0aYrC56mXTwAAXV5g From: "Adrangi, Farid" To: "Joseph Salowey" , "Bernard Aboba" , Cc: "Lortz, Victor" , "Puthenkulam, Jose P" , X-OriginalArrivalTime: 30 Oct 2003 02:52:48.0092 (UTC) FILETIME=[E6C909C0:01C39E90] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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: Wed, 29 Oct 2003 18:52:47 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C39E90.E64DE2A4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Leaving the processing totally up to the mechanism may lead to some interoperability issues. I like your preferred way to use the identity response for routing purposes only. =20 BR, Farid =20 -----Original Message----- From: Joseph Salowey [mailto:jsalowey@cisco.com]=20 Sent: Wednesday, October 29, 2003 6:20 PM To: Adrangi, Farid; 'Bernard Aboba'; jarkko@piuha.net Cc: Lortz, Victor; Puthenkulam, Jose P; eap@frascone.com Subject: RE: [eap] interpretation of the identity response =20 I think the processing of the identity response is up to the mechanism. If the NAI is decorated in non-standard means that is not known to the home AAA this can be a problem (it is also not within the NAI specification). Many mechanisms have a way to request or determine identity independent of the EAP identity response (EAP-SIM,EAP-AKA,EAP-TLS,EAP-MCSHAPv2). I If I had my preference I would use the identity response for routing only and ignore the user identity in the identity response. It should be a recommendation that mechanisms provide a way to obtain identity outside of the identity response. =20 =20 Joe -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Adrangi, Farid Sent: Wednesday, October 29, 2003 5:53 PM To: Bernard Aboba; jarkko@piuha.net Cc: Lortz, Victor; Puthenkulam, Jose P; eap@frascone.com Subject: [eap] interpretation of the identity response Hello Bernard/Jari: =20 I have a quick question regarding 2284bis-06 draft. Currently, the draft does not specify any rules on how the EAP server should interpret an identity response (in particular where it is indicated in NAI format) to extract the identity to be authenticated. For example, given the following NAI Eng%nancy@bigu.edu , does the EAP server use the nancy@bigu.edu portion or the whole string as the ID for authenticating the user? Or another NAI example, say you have ipass/nancy@bigu.edu (where the ipass prefix is used to indicate the RADIUS AAA server in an Access Network how to route the RADIUS packets) will the EAP server use nancy@bigu.edu portion or the whole string?=20 =20 Thanks for your time. =20 BR, Farid =20 ------_=_NextPart_001_01C39E90.E64DE2A4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Leaving the processing totally up = to the mechanism may lead to some interoperability issues.  I like your = preferred way to use the identity response for routing purposes only.  =

BR,

Farid

 

-----Original = Message-----
From: Joseph Salowey [mailto:jsalowey@cisco.com]
Sent: Wednesday, October = 29, 2003 6:20 PM
To: Adrangi, Farid; = 'Bernard Aboba'; jarkko@piuha.net
Cc: Lortz, Victor; = Puthenkulam, Jose P; eap@frascone.com
Subject: RE: [eap] = interpretation of the identity response

 

I think the = processing of the identity response is up to the mechanism.  If the NAI is = decorated in non-standard means that is not known to the home AAA this can be a = problem (it is also not within the NAI specification). Many mechanisms have a way to = request or determine identity independent of the EAP identity response (EAP-SIM,EAP-AKA,EAP-TLS,EAP-MCSHAPv2).   I If I had my preference I would use the identity response for routing only and ignore = the user identity in the identity response.  It should be a = recommendation that mechanisms provide a way to obtain identity outside of the identity response. 

 

Joe=

-----Original Message-----
From: = eap-admin@frascone.com [mailto:eap-admin@frascone.com] On = Behalf Of Adrangi, Farid
Sent: Wednesday, October = 29, 2003 5:53 PM
To: Bernard Aboba; jarkko@piuha.net
Cc: Lortz, Victor; = Puthenkulam, Jose P; eap@frascone.com
Subject: [eap] = interpretation of the identity response

Hello = Bernard/Jari:

 

I have a quick question = regarding 2284bis-06 draft.  Currently, the draft does not specify any rules = on how the EAP server should interpret an identity response (in particular = where it is indicated in NAI format) to extract the identity to be = authenticated.  For example, given the following NAI Eng%nancy@bigu.edu,  does the EAP server use the nancy@bigu.edu portion or the whole string as the ID for authenticating the user? =  Or another NAI example, say you have ipass/nancy@bigu.edu (where the ipass prefix is used to indicate the RADIUS AAA server in an = Access Network how to route the RADIUS packets) will the EAP server use nancy@bigu.edu portion or the whole = string?

 

Thanks for your = time.

 

BR,

Farid

 

=00 ------_=_NextPart_001_01C39E90.E64DE2A4-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 30 00:22: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 AAA26121 for ; Thu, 30 Oct 2003 00:22:12 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35B2158012D; Wed, 29 Oct 2003 23:22:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D192358012E; Wed, 29 Oct 2003 23:22:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4F93E58012E for ; Wed, 29 Oct 2003 23:21:09 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id B8C7C58012D for ; Wed, 29 Oct 2003 23:21:07 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 688B66A90C for ; Thu, 30 Oct 2003 07:21:06 +0200 (EET) Message-ID: <3FA09EC7.8000100@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 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] minutes from 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, 30 Oct 2003 07:16:55 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Extensible Authentication Protocol (eap) Interim Meeting Herndon, VA October 15, 2003 0900 - 1230 EAP WG Interim Meeting 1330 - 1700 EAP WG - IEEE 802.11i Joint Meeting Chair(s): Bernard Aboba Jari Arkko READING MATERIAL ================ o General Information: http://www.drizzle.com/~aboba/EAP/interim.txt o EAP Key Framework http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-00.txt o EAP State Machine http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-00.txt http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-00.pdf o RFC 2284bis http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.txt o IEEE 802.11i D6.0 http://grouper.ieee.org/groups/802/11/private/Draft_Standards/11i/802.11i-D6.0.pdf Userid: p8021 password: go_wildcats o IEEE 802.1X-REV-D7.1 http://www.ieee802.org/1/files/private/x-REV-drafts/d7/802-1X-REV-d7-1.pdf PRELIMINARIES ============= o Agenda Bashing No comments. o Bluesheets Participants: o Minutes Taken by Joe Salowey and John Vollbrecth (thanks!), merged by Jari Arkko. o Document Status Jari went through the document status, as described in http://www.drizzle.com/~aboba/EAP/int-03/eap_oct03interim_agenda.ppt - 2284bis has passed WG last call in AD evaluation Queue. - State machine is now a Working Group document. Two open issues to resolve with .1X (modifications will be made to the .1aa to fix this). A WG Last Call will be issued soon. There is still time to get changes into .1aa Call for implementers to verify state machine. Testing organizations are developing conformance tests based on this draft. Not clear who is or will review this. Probably need implementations to check it -- maybe Yoshihiro will implement it. Has been released to 1.X and 11i for review, but not much feedback yet. - EAP Keying framework. This is also now Working Group document. More work is needed on it, though. This isn't a dependency of 2284bis. All requirements have been moved to 2284bis. Keying framework being copied by 11i, not pointed to -- mainly a timing issue. Diameter EAP depends on Keying Framework (RADIUS can also use it, probably based on Diameter work). - EAP RADIUS, RFC 3579, has been approved and published. - EAP Diameter, draft-ietf-aaa-eap-02.txt is being worked on in AAA WG. - Methods: There are several Internet Drafts on methods. As 2284 progresses it should be possible to move these forward, however it is not exactly clear yet -- discussions ongoing with the IESG. Not in charter to work on Methods. Individual methods may be individual/informational or may become working group items. Presumably charter would have to change to support this. Additional mandatory to implement mechanisms: Different requirements for different applications, no one method meets everyone's needs. Develop methods first and then see if agreement can be reached. Tunnelled methods have different requirement from 2284; requirements will likely be defined in methods. discussion of what interface is required and how methods using tunneled methods interface. Some discussion that timeframe for definining anything in ietf will be too late to impact implementation. Methods can be coordinated as has been done with SIM and AKA. Public Key methods not widely discussed. Comments on Archie and IKEV2. EAP KEY FRAMEWORK I =================== o Open Issues - Bernard Aboba http://www.drizzle.com/~aboba/EAP/eapissues.html Issue 179: EAP-PRF issue raised by Uri Blumenthal. PRFs are required for derivation of keys from the EMSK. Some of the described PRFs associated with this issue may have IPR associated with them. Question is do we need a single PRF? Many PRFs are described/implemented and ok. It would be good to pick one for interoperability. But people felt uncomfortable with a new PRF, and the proposal is to reject this issue. Issue 180: SA description. New text under discussion this meeting Issue 182: Authorization issues. New text incorporated into latest draft. Jari: Some additional issues have been opened since these slides. Minor things, however. o Conversation Overview - Pasi Eronen Pasi presented EAP Keying phases as in http://www.drizzle.com/~aboba/EAP/int-03/eap_interim_slides.ppt There are three main phases, only one of which is EAP. Note that the discussion and implementation is only partly EAP. (0) Discovery This is out of the scope of EAP, discovery handled by PPPoE or 802.1x for example. (1a) EAP-authentication Authenticate EAP Peer and EAP Server. (1b) Access-Authorization Provide keying material and EAP authorizations to authenticator. Note that 1a and 1b typically overlap. (2) Service Authentication For instance, 802.11i four-way exchange. Setup protection and negotiate parameters for services. Authentication may not be the best name for this process since no real authentication takes place. Key material from EAP is used in this phase. Not all of the parameter negotiation may be protected. Discussion in comparison of the proposed model with Kerberos. The trust model is very similar. All parties trust the AAA server which acts similar to a KDC. The AAA access accept contains information that would be contained in a kerberos ticket. It could be possible for EAP methods to work like kerberos. Instead of sending keys through AAA, credentials could be returned in EAP to the client. The client could use these credentials to establish phase 2. Perhaps this should be explored more. o Malicious AP problem, Pasi Eronen Continuing with the same slides as above. An AP can represent one set of information to the client and a different set of information to the AAA. In particular it can do this with the SSID. The SSID could be authenticated by one of the following methods: 1. Incorporate it into key derivation 2. Exchange the SSID in the authentication mechanism as authorization data. It would be best to have a generic means of authenticating arbitrary authorization data within the EAP channel. Existing mechanism such as EAP-TLS may be able to include authorization data (SSID) in a server certificate. It is not clear how useful this would be. Is SSID spoofing a problem? It is not clear that SSID spoofing is a problem that needs to be solved. The consensus at the interim meeting is that no one required this problem to be solved. o Security Associations - Pasi Eronen Security association Discussion, continuing with the same slides as above. There are the following SAs: - Long Term EAP-SA This is a long term security relationship based on a password, public key pair or shared secret. Security is probably not the appropriate term for this, for public key Trust Anchor, for secret key security relationship? - Short term EAP-SA This was defined as an EAP method SA to support fast resume functionality. It is not used external to the mechanism. - AAA SA Security association between AAA and authenticator based on shared secret, IPSEC or TLS. - Service SAs Service SAs are between the EAP-Peer and authenticator. They combine information from EAP, service negotiation and discovery. They are based on keying material from EAP. Discussion about whether MSK and EMSK state (or keys derived from that state) may be maintained on AAA for various reasons (Fast Handoff for example). This state would then be like security association derived from EAP. Currently this is not well defined and AAA implementations usually destroy the state after keys are distributed to the authenticator. Discussion of 802.11i specific service SAs: - PTKSA Created by 4 way handshake Addresses, PTK, Ciphersuite, cipher data(new), lifetime(new), reference to PMKSA (new not in document), authorization information (SSID, L2 filters, accounting) - PMKSA PMKID, PMK, SSID, sharing PMK between The keying document should describe problems with Using the AAA-Key directly. Pre 802.11i WEP can be used as an example. Note that Pasi's document has generic info as well as examples. The slides show only the examples. Discussion of whether examples belong in document. EAP KEY FRAMEWORK II ==================== o Key Scoping & Fast Handoff - Bernard Aboba 8o-09 Postponed due to lack of time. o Authorization & Fast handoff - Jari Arkko Postponed due to lack of time. o Diameter EAP - Pasi Eronen & Jari Arkko An "AAA-Token" should consist of: - authorization AVP - key The key attribute only contains a key and is not a group attribute. Does a key name need to be included? If keys are derived from the EMSK or MSK and are cached then there is a reason to name them. This name should be derived from the EAP mechanism so both EAP-Peer and Eap-Authenticator need to know the name. If keys are going to be cached on the authenticator then AAA may need to return a name. Some discussion on naming techniques. 802.11i currently hashes the PMK with a known quantity to generate a name. There was some reservation expressed as to whether this was a good idea or not. It would be better if the EAP mechanism derived a key that was not a direct static function of the key. Naming issues for SA's particularly the long term Key between the client and AAA server. There is some confusion about whether the key can be a Master Key and if it is different if a public key is used. We did not come to closure about this, but noted that Russ has requirement that there be a name. (Some discussion that name allows SA to be destroyed/tracked.) AFTERNOON MEETING WITH IEEE =========================== o Minutes will be provided separately _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 30 01:18: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 BAA27350 for ; Thu, 30 Oct 2003 01:18:03 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55FB1580136; Thu, 30 Oct 2003 00:18:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1926D58012F; Thu, 30 Oct 2003 00:18:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AEAAC58012F for ; Thu, 30 Oct 2003 00:17:55 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id DADC458012E for ; Thu, 30 Oct 2003 00:17:53 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9U5exY01980 for ; Wed, 29 Oct 2003 21:40:59 -0800 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] EAP WG agenda for IETF 58, Take Four 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, 29 Oct 2003 21:40:59 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Extensible Authentication Protocol (eap) WG Chair(s): Bernard Aboba Jari Arkko Monday, November 10, 2003 1930 - 2200 Preliminaries (10 minutes) Agenda Bashing Bluesheets Minutes Document Status Issue Status: http://www.drizzle.com/~aboba/EAP/eapissues.html WG Work Items ------------- RFC 2284bis (10 minutes), Henrik Lefkowetz http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.txt EAP State Machine (20 minutes), TBD http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.txt EAP Key Framework, Bernard Aboba (40 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-00.txt Drafts relating to WG work items -------------------------------- Network Selection, Farid Adrangi (10 minutes) http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt EAP Key Derivation for Multiple Applications, Joe Salowey (10 minutes) http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-02.txt The Compound Binding Problem, Jose Puthenkulam (10 minutes) http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt EAP methods - Status & Issues ----------------------------- PEAPv2, Jose Salowey (10 minutes) http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-07.txt EAP SIM/AKA, Henry Haverinen (10 minutes) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-11.txt http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-10.txt EAP Smartcard, Pascal Urien (10 minutes) http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-03.txt Roadmap (10 minutes), WG Chairs and ADs _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Oct 30 13:13: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 NAA03466 for ; Thu, 30 Oct 2003 13:13:05 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E58D2580109; Thu, 30 Oct 2003 12:13:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B76EA58010A; Thu, 30 Oct 2003 12:13:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0968858010A for ; Thu, 30 Oct 2003 12:12:01 -0600 (CST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 8067E580109 for ; Thu, 30 Oct 2003 12:11:59 -0600 (CST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9UIBueu001644 for ; Thu, 30 Oct 2003 10:11:56 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.65.214]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 30 Oct 2003 10:16:49 -0800 From: "Joseph Salowey" To: Message-ID: <00ec01c39f11$4d5cbe90$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 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 30 Oct 2003 18:16:50.0035 (UTC) FILETIME=[FCC22C30:01C39F11] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 189: Handling of the identity response 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, 30 Oct 2003 10:11:54 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Handling of the identity response Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 10/30/3003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-October/001787.html, http://mail.frascone.com/pipermail/public/eap/2003-October/001788.html Document: RFC2284bis Comment type: 'E'ditorial Priority: '1' Should fix Section: Section 5.1 and Section 2.2 Rationale/Explanation of issue: The data in the EAP-Identity Response method is typically provided to a method for processing. There are several reasons why a method may not be able to process this identity. First the identity may not be the appropriate identity for the method chosen by the server. Second the identity may have been decorated to ensure that it is routed correctly to the appropriate EAP-Server. The recommendation is to suggest that the EAP-Identity response be used primarily for routing and method selection. EAP-Methods should provided a separate mechanism for obtaining identity and not rely upon the identity response. Many proposed methods already have a way to do this. Requested change: Modify the following text in section 2.2: "Since some EAP authentication methods may wish to access the Identity, implementations SHOULD make the Identity Request and Response accessible to authentication methods (Types 4 or greater) in addition to the Identity method. However, it is recommended that future EAP Methods not rely upon the identity received in the identity response and have a alternate way of obtaining identity. There are several reasons why a method may not be able to process this identity; the identity may not be the appropriate identity for the method chosen by the server, the identity may have been decorated to ensure that it is routed correctly to the appropriate EAP-Server, or the identity may have been truncated or obfuscated for privacy reasons. It is recommended that the identity be used primarily for routing the request to an appropriate EAP server and that the identity response be ignored by the EAP Method. The Identity Type is discussed in Section 5.1." I 'm not sure we need to add anything to section 5.1 (although I think the implementation note needs to be fixed). There may be security considerations: in order to prevent mechanisms from revealing too much information about valid users method implementations may always ignore the identity response and use the mechanism specific identity query. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 31 12:14: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 MAA08942 for ; Fri, 31 Oct 2003 12:14:04 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 82CE5580131; Fri, 31 Oct 2003 11:14:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0B687580132; Fri, 31 Oct 2003 11:14:05 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A7E2D580132 for ; Fri, 31 Oct 2003 11:13:40 -0600 (CST) Received: from reformers.mr.itd.umich.edu (reformers.mr.itd.umich.edu [141.211.93.147]) by mail.frascone.com (Postfix) with ESMTP id 1E9D5580131 for ; Fri, 31 Oct 2003 11:13:39 -0600 (CST) Received: from dhcp60-10.merit.edu (dhcp60-10.merit.edu [198.108.60.210]) by reformers.mr.itd.umich.edu (smtp) with ESMTP id h9VH3hES008221; Fri, 31 Oct 2003 12:03:43 -0500 From: John Vollbrecht To: Joseph Salowey , eap@frascone.com Subject: Re: [eap] Issue 189: Handling of the identity response Message-ID: <7789243.1067601822@dhcp60-10.merit.edu> In-Reply-To: <00ec01c39f11$4d5cbe90$0200000a@amer.cisco.com> References: <00ec01c39f11$4d5cbe90$0200000a@amer.cisco.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: Fri, 31 Oct 2003 12:03:42 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit see suggestions below - mostly edits and nits --On Thursday, October 30, 2003 10:11 AM -0800 Joseph Salowey wrote: > Handling of the identity response > > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date first submitted: 10/30/3003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-October/001787.html, > http://mail.frascone.com/pipermail/public/eap/2003-October/001788.html > Document: RFC2284bis > Comment type: 'E'ditorial > Priority: '1' Should fix > Section: Section 5.1 and Section 2.2 > Rationale/Explanation of issue: > > The data in the EAP-Identity Response method is typically provided to a > method for processing. There are several reasons why a method may not > be able to process this identity. First the identity may not be the > appropriate identity for the method chosen by the server. Second the > identity may have been decorated to ensure that it is routed correctly > to the appropriate EAP-Server. > > The recommendation is to suggest that the EAP-Identity response be used > primarily for routing and method selection. EAP-Methods should provided > a separate mechanism for obtaining identity and not rely upon the > identity response. Many proposed methods already have a way to do this. > > Requested change: > > Modify the following text in section 2.2: > > "Since some EAP authentication methods may wish to access the Identity, > implementations SHOULD make the Identity Request and Response accessible > to authentication methods (Types 4 or greater) in addition to the > Identity method. However, it is recommended that future EAP Methods not > Identity Type is discussed in Section 5.1." > > rely upon the identity received in the identity response and have a > alternate way of obtaining identity. There are several reasons why a > method may not be able to process this identity; the identity may > the identity may have been decorated to ensure that it is routed correctly > to the appropriate EAP-Server, or the identity may have been truncated > or obfuscated for privacy reasons. . It is recommended that the identity >> be used primarily for routing the request to an appropriate EAP server; > and that the identity response be ignored by the EAP Method. > Identity Type is discussed in Section 5.1." > how about When an EAP Identity Method is used, Data in the EAP-Identity Response is typically provided to subsequent EAP Methods. The subsequent Method MAY use this in its processing its algorithm. Note that the information in the Identity Response is primarily used for routiing following EAP requests and for selecting a method to process the request. A method SHOULD NOT use information in the Identity response as the actual Identity to be authenticated. The reason is that the Data in the Identity Response may not be the appropriate identity for the method chosen by the server: the identity may have been decorated to ensure that it is routed correctly by a NAS or Proxy AAAA Server to the appropriate EAP-Server, or the identity may have been truncated or obfuscated for privacy reasons. It is recommended that the Identity Response Data be used primarily for routing the request to an appropriate EAP server and/or selecting an EAP method, and that the Identity Response Data be ignored by subsequent the EAP Method. Identity Type is discussed in Section 5.1. > I 'm not sure we need to add anything to section 5.1 (although I think > the implementation note needs to be fixed). There may be security > considerations: in order to prevent mechanisms from revealing too much > information about valid users method implementations may always ignore > the identity response and use the mechanism specific identity query. > > _______________________________________________ > 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 Oct 31 14:09: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 OAA13889 for ; Fri, 31 Oct 2003 14:09:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49D07580135; Fri, 31 Oct 2003 13:09:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 118BC580132; Fri, 31 Oct 2003 13:09:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6BE20580132 for ; Fri, 31 Oct 2003 13:08:43 -0600 (CST) Received: from sj-iport-5.cisco.com (unknown [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 3CBB4580131 for ; Fri, 31 Oct 2003 13:08:42 -0600 (CST) Received: from cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2003 11:09:02 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9VJ8QMn021936; Fri, 31 Oct 2003 11:08:29 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.112.104]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 31 Oct 2003 11:13:21 -0800 From: "Joseph Salowey" To: "'John Vollbrecht'" , Subject: RE: [eap] Issue 189: Handling of the identity response Message-ID: <01e301c39fe2$5ceac1a0$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 In-Reply-To: <7789243.1067601822@dhcp60-10.merit.edu> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 31 Oct 2003 19:13:21.0430 (UTC) FILETIME=[0C99BB60:01C39FE3] 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: Fri, 31 Oct 2003 11:08:25 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: jrv@j.imap.itd.umich.edu > [mailto:jrv@j.imap.itd.umich.edu] On Behalf Of John Vollbrecht > Sent: Friday, October 31, 2003 9:04 AM > To: Joseph Salowey; eap@frascone.com > Subject: Re: [eap] Issue 189: Handling of the identity response > > > see suggestions below - mostly edits and nits > > --On Thursday, October 30, 2003 10:11 AM -0800 Joseph Salowey > wrote: > > > Handling of the identity response > > > > Submitter name: Joe Salowey > > Submitter email address: jsalowey@cisco.com > > Date first submitted: 10/30/3003 > > Reference: > > > http://mail.frascone.com/pipermail/public/eap/2003-October/001787.html > > , > > > http://mail.frascone.com/pipermail/public/eap/2003-October/001788.html > > Document: RFC2284bis > > Comment type: 'E'ditorial > > Priority: '1' Should fix > > Section: Section 5.1 and Section 2.2 > > Rationale/Explanation of issue: > > > > The data in the EAP-Identity Response method is typically > provided to > > a method for processing. There are several reasons why a > method may > > not be able to process this identity. First the identity > may not be > > the appropriate identity for the method chosen by the > server. Second > > the identity may have been decorated to ensure that it is routed > > correctly to the appropriate EAP-Server. > > > > The recommendation is to suggest that the EAP-Identity response be > > used primarily for routing and method selection. > EAP-Methods should > > provided a separate mechanism for obtaining identity and > not rely upon > > the identity response. Many proposed methods already have > a way to do > > this. > > > > Requested change: > > > > Modify the following text in section 2.2: > > > > "Since some EAP authentication methods may wish to access the > > Identity, implementations SHOULD make the Identity Request and > > Response accessible to authentication methods (Types 4 or > greater) in > > addition to the Identity method. However, it is recommended that > > future EAP Methods not > > > Identity Type is discussed in Section 5.1." > > > > > rely upon the identity received in the identity response and have a > > alternate way of obtaining identity. There are several > reasons why a > > method may not be able to process this identity; the > identity may the > > identity may have been decorated to ensure that it is > routed correctly > > to the appropriate EAP-Server, or the identity may have > been truncated > > or obfuscated for privacy reasons. . It is recommended that the > > identity > >> be used primarily for routing the request to an appropriate EAP > >> server; > > and that the identity response be ignored by the EAP > Method. Identity > > Type is discussed in Section 5.1." > > > > how about > > When an EAP Identity Method is used, Data in the EAP-Identity > Response is > typically provided to subsequent EAP Methods. The subsequent > Method MAY > use this in its processing its algorithm. Note that the > information in the > Identity Response is primarily used for routiing following > EAP requests and > for selecting a method to process the request. A method > SHOULD NOT use > information in the Identity response as the actual Identity to be > authenticated. > [Joe] I'm not sure about the last sentence. The SHOULD NOT may conflict with the previous MAY. How about. "A method SHOULD provide a method specific means for obtaining identity so it does not have to rely upon the information in identity response. > The reason is that the Data in the Identity Response may not > be the appropriate identity for the method chosen by the > server: the identity > may have been decorated to ensure that it is routed correctly > by a NAS or > Proxy AAAA Server to the appropriate EAP-Server, or the > identity may have > been truncated or obfuscated for privacy reasons. It is > recommended that > the Identity Response Data be used primarily for routing the > request to an > appropriate EAP server and/or selecting an EAP method, and that the > Identity Response Data be ignored by subsequent the EAP > Method. Identity > Type is discussed in Section 5.1. > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 31 14:49: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 OAA15803 for ; Fri, 31 Oct 2003 14:49:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 99339580131; Fri, 31 Oct 2003 13:49:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3244580132; Fri, 31 Oct 2003 13:49:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 57438580132 for ; Fri, 31 Oct 2003 13:48:51 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id E44D6580131 for ; Fri, 31 Oct 2003 13:48:49 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9VJBl003744 for ; Fri, 31 Oct 2003 11:11:47 -0800 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] EAP WG agenda for IETF 58, Take Five 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, 31 Oct 2003 11:11:46 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Extensible Authentication Protocol (eap) WG Chair(s): Bernard Aboba Jari Arkko Monday, November 10, 2003 1930 - 2200 Preliminaries (10 minutes) Agenda Bashing Bluesheets Minutes Document Status Issue Status: http://www.drizzle.com/~aboba/EAP/eapissues.html WG Work Items (70 minutes) ------------- RFC 2284bis (10 minutes), Henrik Lefkowetz http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.txt EAP State Machine (20 minutes), TBD http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.txt EAP Key Framework, Bernard Aboba (40 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-00.txt Drafts relating to WG work items (30 minutes) -------------------------------- Network Selection, Farid Adrangi (10 minutes) http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt EAP Key Derivation for Multiple Applications, Joe Salowey (10 minutes) http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-02.txt The Compound Binding Problem, Jose Puthenkulam (10 minutes) http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt EAP methods - Status & Issues (20 minutes) ----------------------------- PEAPv2, Jose Salowey (5 minutes) http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-07.txt EAP SIM/AKA, Henry Haverinen (5 minutes) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-11.txt http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-10.txt EAP Smartcard, Pascal Urien (5 minutes) http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-03.txt EAP-IKEv2, Hannes Tschofenig (5 minutes) http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-02.txt Roadmap (10 minutes), WG Chairs and ADs _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 31 15:07: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 PAA17141 for ; Fri, 31 Oct 2003 15:07:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B89A580135; Fri, 31 Oct 2003 14:07:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2801D580131; Fri, 31 Oct 2003 14:07:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 658DF580131 for ; Fri, 31 Oct 2003 14:06:59 -0600 (CST) Received: from reformers.mr.itd.umich.edu (reformers.mr.itd.umich.edu [141.211.93.147]) by mail.frascone.com (Postfix) with ESMTP id 1A45B58012D for ; Fri, 31 Oct 2003 14:06:58 -0600 (CST) Received: from dhcp60-10.merit.edu (dhcp60-10.merit.edu [198.108.60.210]) by reformers.mr.itd.umich.edu (smtp) with ESMTP id h9VK6nES007476; Fri, 31 Oct 2003 15:06:50 -0500 From: John Vollbrecht To: Joseph Salowey , eap@frascone.com Subject: RE: [eap] Issue 189: Handling of the identity response Message-ID: <8118165.1067612806@dhcp60-10.merit.edu> In-Reply-To: <01e301c39fe2$5ceac1a0$0200000a@amer.cisco.com> References: <01e301c39fe2$5ceac1a0$0200000a@amer.cisco.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: Fri, 31 Oct 2003 15:06:47 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit --On Friday, October 31, 2003 11:08 AM -0800 Joseph Salowey wrote: > > > > -----Original Message----- > > From: jrv@j.imap.itd.umich.edu > > [mailto:jrv@j.imap.itd.umich.edu] On Behalf Of John Vollbrecht > > Sent: Friday, October 31, 2003 9:04 AM > > To: Joseph Salowey; eap@frascone.com > > Subject: Re: [eap] Issue 189: Handling of the identity response > > > > > > see suggestions below - mostly edits and nits > > > > --On Thursday, October 30, 2003 10:11 AM -0800 Joseph Salowey > > wrote: > > > > > Handling of the identity response > > > > > > Submitter name: Joe Salowey > > > Submitter email address: jsalowey@cisco.com > > > Date first submitted: 10/30/3003 > > > Reference: > > > > > http://mail.frascone.com/pipermail/public/eap/2003-October/001787.html > > > , > > > > > http://mail.frascone.com/pipermail/public/eap/2003-October/001788.html > > > Document: RFC2284bis > > > Comment type: 'E'ditorial > > > Priority: '1' Should fix > > > Section: Section 5.1 and Section 2.2 > > > Rationale/Explanation of issue: > > > > > > The data in the EAP-Identity Response method is typically > > provided to > > > a method for processing. There are several reasons why a > > method may > > > not be able to process this identity. First the identity > > may not be > > > the appropriate identity for the method chosen by the > > server. Second > > > the identity may have been decorated to ensure that it is routed > > > correctly to the appropriate EAP-Server. > > > > > > The recommendation is to suggest that the EAP-Identity response be > > > used primarily for routing and method selection. > > EAP-Methods should > > > provided a separate mechanism for obtaining identity and > > not rely upon > > > the identity response. Many proposed methods already have > > a way to do > > > this. > > > > > > Requested change: > > > > > > Modify the following text in section 2.2: > > > > > > "Since some EAP authentication methods may wish to access the > > > Identity, implementations SHOULD make the Identity Request and > > > Response accessible to authentication methods (Types 4 or > > greater) in > > > addition to the Identity method. However, it is recommended that > > > future EAP Methods not > > > > > Identity Type is discussed in Section 5.1." > > > > > > > > rely upon the identity received in the identity response and have a > > > alternate way of obtaining identity. There are several > > reasons why a > > > method may not be able to process this identity; the > > identity may the > > > identity may have been decorated to ensure that it is > > routed correctly > > > to the appropriate EAP-Server, or the identity may have > > been truncated > > > or obfuscated for privacy reasons. . It is recommended that the > > > identity > > >> be used primarily for routing the request to an appropriate EAP > > >> server; > > > and that the identity response be ignored by the EAP > > Method. Identity > > > Type is discussed in Section 5.1." > > > > > > > how about > > > > When an EAP Identity Method is used, Data in the EAP-Identity > > Response is > > typically provided to subsequent EAP Methods. The subsequent > > Method MAY > > use this in its processing its algorithm. Note that the > > information in the > > Identity Response is primarily used for routiing following > > EAP requests and > > for selecting a method to process the request. A method > > SHOULD NOT use > > information in the Identity response as the actual Identity to be > > authenticated. > > > [Joe] I'm not sure about the last sentence. The SHOULD NOT may conflict > with the previous MAY. How about. > "A method SHOULD provide a method specific means for obtaining identity > so it does not have to rely upon the information in identity response. > [John] I understand your point. I was trying to say that the algorithm MAY use the information, otherwise why would we give it to him? However, it should not use it as the method's identity. Note that it may use the identity or identity as modified by the NAS to select which EAP method to use. That is different than using it in the method. > > The reason is that the Data in the Identity Response may not > > be the appropriate identity for the method chosen by the > > server: the identity > > may have been decorated to ensure that it is routed correctly > > by a NAS or > > Proxy AAAA Server to the appropriate EAP-Server, or the > > identity may have > > been truncated or obfuscated for privacy reasons. It is > > recommended that > > the Identity Response Data be used primarily for routing the > > request to an > > appropriate EAP server and/or selecting an EAP method, and that the > > Identity Response Data be ignored by subsequent the EAP > > Method. Identity > > Type is discussed in Section 5.1. > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 31 15:33: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 PAA18948 for ; Fri, 31 Oct 2003 15:33:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 45C6F580109; Fri, 31 Oct 2003 14:33:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E844158012D; Fri, 31 Oct 2003 14:33:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61ECA58012D for ; Fri, 31 Oct 2003 14:32:42 -0600 (CST) 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 34BD3580109 for ; Fri, 31 Oct 2003 14:32:41 -0600 (CST) Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 31 Oct 2003 12:35:32 -0800 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 h9VKWbXw016315; Fri, 31 Oct 2003 12:32:38 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.112.104]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 31 Oct 2003 12:37:32 -0800 From: "Joseph Salowey" To: "'John Vollbrecht'" , Subject: RE: [eap] Issue 189: Handling of the identity response Message-ID: <01ef01c39fee$1f852c40$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 In-Reply-To: <8118165.1067612806@dhcp60-10.merit.edu> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 31 Oct 2003 20:37:32.0384 (UTC) FILETIME=[CF342600:01C39FEE] 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: Fri, 31 Oct 2003 12:32:36 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > > > how about > > > > > > When an EAP Identity Method is used, Data in the EAP-Identity > > > Response is typically provided to subsequent EAP Methods. The > > > subsequent Method MAY > > > use this in its processing its algorithm. Note that the > > > information in the > > > Identity Response is primarily used for routiing following > > > EAP requests and > > > for selecting a method to process the request. A method > > > SHOULD NOT use > > > information in the Identity response as the actual Identity to be > > > authenticated. > > > > > [Joe] I'm not sure about the last sentence. The SHOULD NOT may > > conflict with the previous MAY. How about. "A method > SHOULD provide a > > method specific means for obtaining identity so it does not have to > > rely upon the information in identity response. > > > [John] I understand your point. I was trying to say that the > algorithm MAY > use the information, otherwise why would we give it to him? > However, it > should not use it as the method's identity. Note that it may use the > identity or identity as modified by the NAS to select which > EAP method to > use. That is different than using it in the method. > [Joe] Isn't the method section is done before the method gets the identity? Some existing methods may require the identity that is why it should be provided to the method. I think we want to discourage reliance on the identity response in methods moving forward. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 31 15:52: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 PAA19669 for ; Fri, 31 Oct 2003 15:51:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 293D5580135; Fri, 31 Oct 2003 14:52:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3C4C858012D; Fri, 31 Oct 2003 14:52:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0377858012D for ; Fri, 31 Oct 2003 14:51:15 -0600 (CST) Received: from reformers.mr.itd.umich.edu (reformers.mr.itd.umich.edu [141.211.93.147]) by mail.frascone.com (Postfix) with ESMTP id 1AC1E580109 for ; Fri, 31 Oct 2003 14:51:14 -0600 (CST) Received: from dhcp60-10.merit.edu (dhcp60-10.merit.edu [198.108.60.210]) by reformers.mr.itd.umich.edu (smtp) with ESMTP id h9VKoKES014809; Fri, 31 Oct 2003 15:50:21 -0500 From: John Vollbrecht To: Joseph Salowey , eap@frascone.com Subject: RE: [eap] Issue 189: Handling of the identity response Message-ID: <8274794.1067615417@dhcp60-10.merit.edu> In-Reply-To: <01ef01c39fee$1f852c40$0200000a@amer.cisco.com> References: <01ef01c39fee$1f852c40$0200000a@amer.cisco.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: Fri, 31 Oct 2003 15:50:17 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit --On Friday, October 31, 2003 12:32 PM -0800 Joseph Salowey wrote: > > > > how about > > > > > > > > When an EAP Identity Method is used, Data in the EAP-Identity > > > > Response is typically provided to subsequent EAP Methods. The > > > > subsequent Method MAY > > > > use this in its processing its algorithm. Note that the > > > > information in the > > > > Identity Response is primarily used for routiing following > > > > EAP requests and > > > > for selecting a method to process the request. A method > > > > SHOULD NOT use > > > > information in the Identity response as the actual Identity to be > > > > authenticated. > > > > > > > [Joe] I'm not sure about the last sentence. The SHOULD NOT may > > > conflict with the previous MAY. How about. "A method > > SHOULD provide a > > > method specific means for obtaining identity so it does not have to > > > rely upon the information in identity response. > > > > > [John] I understand your point. I was trying to say that the > > algorithm MAY > > use the information, otherwise why would we give it to him? > > However, it > > should not use it as the method's identity. Note that it may use the > > identity or identity as modified by the NAS to select which > > EAP method to > > use. That is different than using it in the method. > > > [Joe] Isn't the method section is done before the method gets the > identity? Some existing methods may require the identity that is why it > should be provided to the method. I think we want to discourage > reliance on the identity response in methods moving forward. > [John] I think the Identity may be used by some methods (actually I am not sure this is true) which are capable of doing whatever treating of the method to get its meaning. However some methods may also use the identity from the RADIUS User-ID to get the identity. These are not the same, as the NAS may modify the EAP Identity data to support RADIUS proxy routing. I am thinking the second case [routing] is governed by a set of rules agreed to by the organization of clients and NASs not covered in this spec. This is ok. The first case - where the method uses the Identity Response data from the previous request as an identity does not seem right. In thinking about it I am not sure it actually happens in any implementations [as opposed to selecting the method instance based on the Response Data]. I think this is what you are saying should be discouraged, and I am wondering if it is SHOULD or MUST not. > _______________________________________________ > 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 Oct 31 16:25:00 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 QAA20848 for ; Fri, 31 Oct 2003 16:24:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AEA7F58012D; Fri, 31 Oct 2003 15:25:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB702580131; Fri, 31 Oct 2003 15:25:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C8B8580131 for ; Fri, 31 Oct 2003 15:24:55 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id BAAFF58012D for ; Fri, 31 Oct 2003 15:24:53 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9VKlof09343 for ; Fri, 31 Oct 2003 12:47:50 -0800 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] EAP WG agenda for IETF 58, Take Six 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, 31 Oct 2003 12:47:50 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Extensible Authentication Protocol (eap) WG Chair(s): Bernard Aboba Jari Arkko Monday, November 10, 2003 1930 - 2200 Preliminaries (10 minutes) Agenda Bashing Bluesheets Minutes Document Status Issue Status: http://www.drizzle.com/~aboba/EAP/eapissues.html WG Work Items (70 minutes) ------------- RFC 2284bis (10 minutes), Henrik Lefkowetz http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.txt EAP State Machine (20 minutes), TBD http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.txt EAP Key Framework, Bernard Aboba (40 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt Drafts relating to WG work items (30 minutes) -------------------------------- Network Selection, Farid Adrangi (10 minutes) http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt EAP Key Derivation for Multiple Applications, Joe Salowey (10 minutes) http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-02.txt The Compound Binding Problem, Jose Puthenkulam (10 minutes) http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt EAP methods - Status & Issues (20 minutes) ----------------------------- PEAPv2, Jose Salowey (5 minutes) http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-07.txt EAP SIM/AKA, Henry Haverinen (5 minutes) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-12.txt http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-11.txt EAP Smartcard, Pascal Urien (5 minutes) http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-03.txt EAP-IKEv2, Hannes Tschofenig (5 minutes) http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-02.txt Roadmap (10 minutes), WG Chairs and ADs _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Oct 31 17:51: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 RAA23356 for ; Fri, 31 Oct 2003 17:51:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C09F58012D; Fri, 31 Oct 2003 16:51:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58B70580131; Fri, 31 Oct 2003 16:51:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DC790580131 for ; Fri, 31 Oct 2003 16:50:20 -0600 (CST) 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 A9C4558012D for ; Fri, 31 Oct 2003 16:50:19 -0600 (CST) Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 31 Oct 2003 14:49:44 -0800 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 h9VMoGXw024262; Fri, 31 Oct 2003 14:50:16 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.112.104]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 31 Oct 2003 14:55:10 -0800 From: "Joseph Salowey" To: "'John Vollbrecht'" , Subject: RE: [eap] Issue 189: Handling of the identity response Message-ID: <01ff01c3a001$59ee0b50$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 In-Reply-To: <8274794.1067615417@dhcp60-10.merit.edu> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 31 Oct 2003 22:55:10.0937 (UTC) FILETIME=[09AF5490:01C3A002] 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: Fri, 31 Oct 2003 14:50:15 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: jrv@j.imap.itd.umich.edu > [mailto:jrv@j.imap.itd.umich.edu] On Behalf Of John Vollbrecht > Sent: Friday, October 31, 2003 12:50 PM > To: Joseph Salowey; eap@frascone.com > Subject: RE: [eap] Issue 189: Handling of the identity response > > > > > --On Friday, October 31, 2003 12:32 PM -0800 Joseph Salowey > wrote: > > > > > > how about > > > > > > > > > > When an EAP Identity Method is used, Data in the EAP-Identity > > > > > Response is typically provided to subsequent EAP > Methods. The > > > > > subsequent Method MAY use this in its processing its > algorithm. > > > > > Note that the information in the > > > > > Identity Response is primarily used for routiing following > > > > > EAP requests and > > > > > for selecting a method to process the request. A method > > > > > SHOULD NOT use > > > > > information in the Identity response as the actual > Identity to be > > > > > authenticated. > > > > > > > > > [Joe] I'm not sure about the last sentence. The SHOULD NOT may > > > > conflict with the previous MAY. How about. "A method > > > SHOULD provide a > > > > method specific means for obtaining identity so it does > not have > > > > to rely upon the information in identity response. > > > > > > > [John] I understand your point. I was trying to say that the > > > algorithm MAY use the information, otherwise why would we > give it to > > > him? However, it > > > should not use it as the method's identity. Note that it > may use the > > > identity or identity as modified by the NAS to select which > > > EAP method to > > > use. That is different than using it in the method. > > > > > [Joe] Isn't the method section is done before the method gets the > > identity? Some existing methods may require the identity > that is why > > it should be provided to the method. I think we want to discourage > > reliance on the identity response in methods moving forward. > > > [John] I think the Identity may be used by some methods > (actually I am not > sure this is true) which are capable of doing whatever > treating of the > method to get its meaning. However some methods may also use > the identity > from the RADIUS User-ID to get the identity. These are not > the same, as > the NAS may modify the EAP Identity data to support RADIUS > proxy routing. > [Joe] A EAP method SHOULD provide a means to obtain the peer identity. A method MAY use external indicators to determine identity, but these should not be the only means to establish identity as these are usually specific to certain invironments. > I am thinking the second case [routing] is governed by a set of rules > agreed to by the organization of clients and NASs not covered > in this spec. > This is ok. > > The first case - where the method uses the Identity Response > data from the > previous request as an identity does not seem right. In > thinking about it > I am not sure it actually happens in any implementations [as > opposed to > selecting the method instance based on the Response Data]. [Joe] I was under the impression that EAP-OTP required the identity. I > think this is > what you are saying should be discouraged, and I am wondering > if it is > SHOULD or MUST not. > [Joe] If we can make it a MUST NOT use the identity from the identity response that would be great. > > > _______________________________________________ > > 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