From aboba@internaut.com Wed Jul 2 14:46:56 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 2 Jul 2003 06:46:56 -0700 (PDT) Subject: [eap] Updated Agenda for EAP WG at IETF 57 Message-ID: Extensible Authentication Protocol WG (eap) CHAIR: Bernard Aboba Jari Arkko AGENDA: Monday, July 14 at 1530-1730 =============================== Preliminaries (20 minutes) Bluesheets Minute Takers Agenda Bash Document Status Liason Statements RFC 2284bis (20 minutes), Henrik Levkowetz http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-04.txt EAP State Machine (20 minutes), Pasi Eronen http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-03.txt EAP Compound Binding (20 minutes), Jose Puthenkulam http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt Methods EAP SIM & AKA (10 minutes) H. Haverinen, J. Salowey, J. Arkko 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-SIM Security Analysis (20 minutes), Uri Blumenthal http://www.drizzle.com/~aboba/EAP/AnalyisOfEAP.pdf Thursday, July 17 at 1300-1500 =============================== EAP Client Side Transport (10 minutes), B. Boursetty http://www.ietf.org/internet-drafts/draft-boursetty-eap-cst-00.txt EAP Keying Framework (30 minutes), Bernard Aboba http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-07.txt Use of EAP Keying for DHCP Bootstrap (10 minutes), H. Tschofenig http://www.ietf.org/internet-drafts/draft-tschofenig-pana-bootstrap-rfc3118-00.txt Methods (cont'd) EAP LDAP (10 minutes), H. Mancini http://www.ietf.org/internet-drafts/draft-mancini-pppext-eap-ldap-00.txt EAP Support in Smartcard (10 minutes), P. Urien http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-02.txt http://www.ietf.org/internet-drafts/draft-urien-eap-ssc-00.txt PEAP Version 2 (10 minutes), Ashwin Palekar http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-06.txt EAP Archie (10 minutes), Jesse Walker http://www.ietf.org/internet-drafts/draft-jwalker-eap-archie-01.txt From pcalhoun@airespace.com Wed Jul 2 00:58:40 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Tue, 1 Jul 2003 16:58:40 -0700 Subject: [eap] CAPWAP BOF Message-ID: <40301581B2962B448690A023EF16DFE1DC5041@bsn-mail-01.bstormnetworks.com> FYI PatC ---- BOF NAME & ACRONYM: Control And Provisioning of Wireless Access Points (capwap) AREA: OPS BOF CHAIR(S): Dorothy Stanley (dstanley@agere.com) James Kempf (kempf@docomolabs-usa.com) MAILING LIST: List: lwapp@frascone.com Subscribe: lwapp-request@frascone.com Body: subscribe in Subject line Archive: http://mail.frascone.com/pipermail/public/lwapp/ AGENDA: Intro and Agenda Bashing (5 min) LWAPP (Pat Calhoun) (10 min) SNMP (Marcus Brunner) (10 min) Accesss Point Discovery (Inderpreet Singh) (10 min). Security and Certificate Provisioning (David Molnar) (10 min) Discussion (40 min) Summary and Next Steps (10 min) FULL DESCRIPTION: Conventional IETF wisdom has it that wireless access points for non-provisioned wireless media are no more than simple Layer 2 bridges that transparently forward packets between the wired and wireless links. While this is indeed their primary function, in reality, higher layer functions have been gradually migrating into such access points. An example is network access server functionality. Managing this functionality, its interaction between access points, and between access points and access routers has become increasingly difficult. Because some of the functions involve exchange of Layer 2 information, IETF has traditionally maintained that it is "Not Our Problem". On the other hand, because many of the functions either use or provide services with a Layer 3 component, the relevant Layer 2 standardization bodies (such as IEEE for 802.11) have been reluctant to step forward and own the problem either.=20 Recently, next generation 802.11 network infrastructure (also referred to as WLAN switches) have seen significant interest in the market. Several companies, both startups and incumbents in the WLAN space, have announced, or are shipping products. Most of these products have a similar architecture which simplifies the access points, but does not remove the problem of managing the interaction with the IP network. Given the interest in the market for such products, there is no doubt that standardizing the interface between the AP and the controller (or WLAN switch) would benefit the Internet community. Would defining a new Layer 2 independent protocol to manage wireless access points both dynamically and statically help? Can existing IETF solutions contribute, and, if so, is there any Layer 2 independent work that IETF might do to adapt those solutions to the problem space? Wireless access points also have additional security needs that are ill met by regarding them as simple Layer 2 bridges. Because such access points are easy to deploy by design, security provisioning is difficult to achieve. How does the network provider's router verify that a particular access point is authorized to be on the network? Wireless access points are also being called upon to provide increasingly more complex security for hosts, approaching that provided by the highly provisioned wireless media in cellular networks. Can the implementation of these functions be simplified by centralizing the intelligence and distributing the RF interfaces? In this BOF, we will discuss these issues and attempt to come to some conclusions about what IETF might or might not do to help address the problem. READING LIST: Lightweight Access Point Protocol http://www.airespace.com/ftp/draft-calhoun-seamoby-lwapp-03.txt Proposed Solutions: TBD Proposed WG Charter: TBD From aboba@internaut.com Thu Jul 3 16:33:48 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 3 Jul 2003 08:33:48 -0700 (PDT) Subject: [eap] REMINDER: EAP WG last call on draft-ietf-eap-rfc2284bis-04.txt Message-ID: There is an EAP WG last call out on RFC 2284bis, before it is forwarded to the IESG for consideration as an IETF Proposed Standard. The document is available for examination here: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-04.txt EAP WG last call will last until July 6, 2003. So far we have not gotten very many comments -- if you have not already read the draft, please do so and send in your comments to the EAP WG mailing list (eap@frascone.com) in the format specified on the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html From farooq.bari@attws.com Thu Jul 3 18:51:42 2003 From: farooq.bari@attws.com (Bari, Farooq) Date: Thu, 3 Jul 2003 10:51:42 -0700 Subject: [eap] IETF protocol interoperability bake off rules Message-ID: <84359F26B1241A4E90FBBE7F0996BFE9517C9E@WA-MSG12-BTH.wireless.attws.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3418B.C30B2E3A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 This request is not directly related to EAP but I was wondering if any of the reader knows any documented IETF bake off rules/guidelines for protocol interoperability testing. I am assuming since such interoperability is part of standardization process, so some guidelines should exist. I searched IETF website but could not find any info on it. =20 regards =20 Farooq Bari AT&T Wireless Technology Architecture & Standards =20 +1 425 580 5526 farooq.bari@attws.com =20 =20 ------_=_NextPart_001_01C3418B.C30B2E3A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
This = request is=20 not directly related to EAP but I was wondering if any of the = reader knows=20 any documented IETF bake off rules/guidelines for protocol=20 interoperability testing. I am assuming since such interoperability = is part=20 of standardization process, so some guidelines should exist. I searched = IETF=20 website but could not find any info on it.
 
regards
 
Farooq = Bari
AT&T = Wireless
Technology = Architecture &=20 Standards
 
+1 425 580 = 5526
 
=00 ------_=_NextPart_001_01C3418B.C30B2E3A-- From stephen.mccann@roke.co.uk Fri Jul 4 08:33:14 2003 From: stephen.mccann@roke.co.uk (McCann, Stephen) Date: Fri, 4 Jul 2003 08:33:14 +0100 Subject: [eap] IETF protocol interoperability rules Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C341FB.25DE27BE Content-Type: text/plain Farooq, Hi. Generally speaking the IETF does not (and cannot, I believe) hold interoperability tests. Usually such events are organised by the members of a group, who mutually decide to hold such an event and organise it between themselves. It is usually not sponsored or supported by the IETF in any way. I also understand that the use of the words "bak* o**" causes problems with trademarks, and offends some minority communities, so they are usually referred to as interop tests/events. I enclose a couple of examples of interop events for testing other protocols originally created within the IETF; including one by ourselves which I organised (apologies for blatant advertisement). rohc : http://www.dmn.tzi.org/ietf/rohc/rohc-bake.ppt sctp : http://pel.cis.udel.edu/interop/ Additionally there are also organisations like ETSI in Europe which arrange Plug Tests for any technical standard : http://www.etsi.org/frameset/home.htm?/plugtests/home.htm Kind regards Stephen McCann Siemens Roke Manor Romsey UK -----Original Message----- From: Bari, Farooq [mailto:farooq.bari@attws.com] Sent: Thursday, July 03, 2003 6:52 PM To: eap@frascone.com Subject: [eap] IETF protocol interoperability bake off rules Hi, This request is not directly related to EAP but I was wondering if any of the reader knows any documented IETF bake off rules/guidelines for protocol interoperability testing. I am assuming since such interoperability is part of standardization process, so some guidelines should exist. I searched IETF website but could not find any info on it. regards Farooq Bari AT&T Wireless Technology Architecture & Standards +1 425 580 5526 farooq.bari@attws.com ------_=_NextPart_001_01C341FB.25DE27BE Content-Type: text/html Message
Farooq,
    Hi.
 
Generally speaking the IETF does not (and cannot, I believe) hold interoperability tests.
Usually such events are organised by the members of a group, who mutually decide
to hold such an event and organise it between themselves. It is usually not sponsored
or supported by the IETF in any way.
 
I also understand that the use of the words "bak* o**" causes problems with trademarks,
and offends some minority communities, so they are usually referred to as interop tests/events.
 
I enclose a couple of examples of interop events for testing other protocols originally created
within the IETF; including one by ourselves which I organised (apologies for blatant advertisement).
 
rohc :
 
 
sctp :
 
 
Additionally there are also organisations like ETSI in Europe which arrange Plug Tests for
any technical standard :
 
 
Kind regards
 
Stephen McCann
Siemens Roke Manor
Romsey
UK
-----Original Message-----
From: Bari, Farooq [mailto:farooq.bari@attws.com]
Sent: Thursday, July 03, 2003 6:52 PM
To: eap@frascone.com
Subject: [eap] IETF protocol interoperability bake off rules

Hi,
 
This request is not directly related to EAP but I was wondering if any of the reader knows any documented IETF bake off rules/guidelines for protocol interoperability testing. I am assuming since such interoperability is part of standardization process, so some guidelines should exist. I searched IETF website but could not find any info on it.
 
regards
 
Farooq Bari
AT&T Wireless
Technology Architecture & Standards
 
+1 425 580 5526
 
------_=_NextPart_001_01C341FB.25DE27BE-- From Pasi.Eronen@nokia.com Fri Jul 4 11:38:20 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 4 Jul 2003 13:38:20 +0300 Subject: [eap] FYI: Several new EAP-related internet-drafts Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222B8@esebe023.ntc.nokia.com> Hi, I haven't seen these announced here yet, although they are=20 probably of interest to EAP WG members (note that I personally don't have anything to do with most of these documents). EAP methods ----------- J. Arkko, H. Haverinen: EAP AKA Authentication=20 http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-10.txt H. Haverinen, J. Salowey: EAP SIM Authentication=20 http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-11.txt= H. Mancini: EAP-LDAP Protocol http://www.ietf.org/internet-drafts/draft-mancini-pppext-eap-ldap-00.txt L. Salgarelli: EAP-SKE authentication and key exchange protocol http://www.ietf.org/internet-drafts/draft-salgarelli-pppext-eap-ske-03.tx= t A. Salkintzis: The EAP GPRS Protocol (EAP-GPRS)=20 http://www.ietf.org/internet-drafts/draft-salki-pppext-eap-gprs-01.txt H. Tschofenig, D. Kroeselberg: EAP IKEv2 Method (EAP-IKEv2) http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-01.txt Others ------ P. Eronen, T. Hiller, G. Zorn: Diameter Extensible Authentication Protocol (EAP) Application http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-02.txt J. Puthenkulam et al.: The Compound Authentication Binding Problem http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt J. Salowey, P. Eronen: EAP Key Derivation for Multiple Applications http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt J. Salowey: Protected EAP TLV=20 http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-02.txt= P. Urien et al.: EAP support in smartcards http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-02.txt P. Urien, M. Dandjinou: EAP-SSC Secured Smartcard Channel http://www.ietf.org/internet-drafts/draft-urien-eap-ssc-00.txt J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba: State Machines for EAP Peer and Authenticator http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-04.txt http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-04.ps (sorry if I missed some EAP-related document) Best regards, Pasi From aboba@internaut.com Fri Jul 4 15:17:12 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 4 Jul 2003 07:17:12 -0700 (PDT) Subject: [eap] comments on draft-tschofenig-eap-ikev2-01.txt Message-ID: Introduction Typically an introduction provides an overview of the problem, the general approach taken to solving it and the reasoning behind selection of the solution approach. Reading this draft, I am unsure whether the objective is to create a single EAP method utilizing basic IKEv2 modes (certificate, pre-shared key) or whether the goal is to create another tunneling method. Can you clarify? Page 4, Message exchange: When is the EAP Identity exchange necessary/useful in EAP IKEv2? IKEv2 supports its own (protected) identity exchanges, and the method also allows nested EAP Identity exchanges. So you've got a lot of different (and potentially conflicting) identity information available. Assuming that asymmetric IKEv2 features aren't used, can the EAP server play the role of IKEv2 Initiator? This would save a round-trip, no? Page 6 " Since the goal of this EAP method is not to establish an IPsec SA some payloads used in IKEv2 are omitted. In particularly the following messages and payloads are not required: - Traffic Selectors - IPsec SA negotiation payloads (e.g. CREATE_CHILD_SA exchange or SAx2 payloads) - ECN Notification - Port handling - NAT traversal" Yes, EAP IKEv2 need only carry out IKE SA creation. However, a secure association does need to be subsequently negotiated. So there is the question of how the IKE SA is subsequently bound to the (non-IPsec) Phase 2 SA. Any thoughts on that? Since address management is now supported within IKEv2, is the intent to allow IP address assignment within EAP? Section 6 How is KEYMAT used to generate the MSK and EMSK? Section 8 Does EAP IKEv2 utilize Notifications? If not, that should be stated explicitly. It would be useful to have a discussion of error handling. When does the method terminate with an EAP-IKEv2 method-specific error message? Can an EAP Failure always be silently discarded prior to method completion? If the standard means of calculating IKEv2 MACs is used, then the fields of the EAP header will not be covered. Are there any security implications of this? From aboba@internaut.com Fri Jul 4 15:27:01 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 4 Jul 2003 07:27:01 -0700 (PDT) Subject: [eap] Revised Agenda for EAP WG at IETF 57 Message-ID: Extensible Authentication Protocol WG (eap) CHAIR: Bernard Aboba Jari Arkko AGENDA: Monday, July 14 at 1530-1730 =============================== Preliminaries (20 minutes) Bluesheets Minute Takers Agenda Bash Document Status Liason Statements RFC 2284bis (20 minutes), Henrik Levkowetz http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-04.txt EAP State Machine (20 minutes), Pasi Eronen http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-04.txt EAP Compound Binding (20 minutes), Jose Puthenkulam http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt Methods EAP SIM & AKA (10 minutes) H. Haverinen, J. Salowey, J. Arkko 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-SIM Security Analysis (20 minutes), Uri Blumenthal http://www.drizzle.com/~aboba/EAP/AnalyisOfEAP.pdf Thursday, July 17 at 1300-1500 =============================== EAP Client Side Transport (10 minutes), B. Boursetty http://www.ietf.org/internet-drafts/draft-boursetty-eap-cst-00.txt EAP Keying Framework (30 minutes), Bernard Aboba http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-07.txt Use of EAP Keying for DHCP Bootstrap (10 minutes), H. Tschofenig http://www.ietf.org/internet-drafts/draft-tschofenig-pana-bootstrap-rfc3118-00.txt Methods (cont'd) EAP IKEv2 (10 minutes), H. Tschofenig http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-01.txt EAP LDAP (10 minutes), H. Mancini http://www.ietf.org/internet-drafts/draft-mancini-pppext-eap-ldap-00.txt EAP Support in Smartcard (10 minutes), P. Urien http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-02.txt http://www.ietf.org/internet-drafts/draft-urien-eap-ssc-00.txt PEAP Version 2 (10 minutes), J. Salowey/A. Palekar http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-06.txt EAP Archie (10 minutes), Jesse Walker http://www.ietf.org/internet-drafts/draft-jwalker-eap-archie-01.txt From Pasi.Eronen@nokia.com Sun Jul 6 15:20:04 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Sun, 6 Jul 2003 17:20:04 +0300 Subject: [eap] EAP-04 comments Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222BB@esebe023.ntc.nokia.com> EAP-04 comments Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: July 6, 2003 Reference:=20 Document: RFC2284bis Comment type: E/T Priority: 1 Section: various Rationale/Explanation of issue: Overall, the draft looks fine, and it seems that we're finally close to getting it finished! In hindsight, there are a couple of things that might have been clearer if organized differently, but it probably doesn't make sense to do such changes at this point.=20 --- (Section 2) "Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction. Both peers may act as authenticators and authenticatees at the same time. For a discussion of security issues in peer-to-peer operation, see Section 7.7. I think this does not apply to all lower layers. Perhaps it should be rephrased to something like "Some lower layers for carrying EAP, such as PPP, may support peer-to-peer operation, in which an indendent and...". --- (Section 4.2) "Success or Failure packets MUST NOT be sent by an EAP authenticator prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it." I think there are several EAP methods where the number of rounds varies (so the phrase "the final round" is not well defined), depending on many issues, including whether the method is=20 going to succeed or not. Perhaps this would better take that into account? "Success and Failure packets MUST NOT be sent by an EAP authenticator if the specification of the given method does not allow the method to finish at that point. A peer EAP implementation receiving a Success or Failure packet where sending one is not allowed MUST silently discard it." --- (Section 4.2) "If the peer attempts to authenticate to the authenticator and fails to do so, the authenticator MUST send a Failure packet and MUST NOT grant access by sending a Success packet." I know that this was beaten to death already :-) But since=20 we have not defined what "failing to authenticate to the authenticator" means, does this actually impose any=20 requirements for EAP implementations? (The problem is that "failing to authenticate" could be thought as "not successfully authenticating"; but according to the definition of "successful authentication" in Section 1.2, the above requirement does not make much sense.) Perhaps this would capture the intent? "If the peer attempts to authenticate to the authenticator using a method that provides key derivation, the authenticator SHOULD NOT grant access by sending a Success packet if the key derivation has failed for some reason." --- (Section 5.7) "EAP Types from 0 through 255 are semantically identical whether they appear as single octet EAP Types or as Vendor-Types when Vendor-Id is zero." =20 (Section 5.7) "An implementation that supports the Expanded attribute MUST treat EAP Types that are less than 256 equivalently whether they appear as a single octet or as the 32-bit Vendor-Type within a Expanded Type where Vendor-Id is 0." and Otherwise fine, but Expanded Nak packets have a different format than Legacy Nak packets, so they are not treated exactly identically. Perhaps we should add something like "There is one exception to this rule: Expanded Nak and Legacy Nak packets share the same code, but must be treated differently because they have a different format." (an alternative would be to change the code of Expanded Naks to something else, but probably this is easier?) --- Appendix B: Two significant changes to RFC 2284 are not mentioned: mutual authentication and key derivation=20 (RFC 2284 did not even mention either of them). ---- References: There are newer versions of RFC2869bis and SASLPREP drafts available (Ok, RFC editor will probably handle these...) ---- References: PIC is most likely dead and superseded by IKEv2, so maybe we should remove references to PIC and add a pointer to IKEv2? ---- Best regards, Pasi From Pasi.Eronen@nokia.com Sun Jul 6 15:22:40 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Sun, 6 Jul 2003 17:22:40 +0300 Subject: [eap] EAP-04 lower layer indications Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB68@esebe023.ntc.nokia.com> EAP-04 lower layer indications Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: July 6, 2003 Reference:=20 Document: RFC2284bis Comment type: T Priority: 1 Section: 3.4 Rationale/Explanation of issue: Section 3.4 says that=20 "Section 4.2 defines the circumstances in which a peer, having concluded an EAP method with successful acknowledged result indications, may conclude that a Success packet has been lost after expiration of a timeout. In those same circumstances, if a peer receives a lower layer success indication as defined in Section 7.2, it MAY conclude that a Success packet has been lost without waiting for a timeout. This ensures that an attacker spoofing lower layer indications can at best succeed in a denial of service attack." This is not exactly what the current state machine does... The current text says that "if you are in a situation where a timeout would lead to success (that is, you have received a method-specific success indication), also lower-layer success indication does." What the current state mechine does is "if you are in a situation where receiving an EAP Success packet would lead to success, also lower-layer success indication does." Or in other words, the effect of receiving a lower-layer success indication is identical to receiving an EAP Success: if an EAP Success packet would be silently discarded, so is the lower-layer success indication. Both are IMHO quite reasonable approaches, and I just wanted to clarify which one we really want to use? A second issue: Earlier versions of the draft also mentioned lower-layer failure indications (e.g. "Lower layer failure indications provided to EAP by the lower layer MUST be processed and will cause an EAP exchange in progress to be aborted." in -03 version). This seems to be missing from -04, and I think the old text still applies? Best regards, Pasi From jari.arkko@piuha.net Sun Jul 6 15:29:40 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 06 Jul 2003 17:29:40 +0300 Subject: [eap] EAP-04 comments In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222BB@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A61222BB@esebe023.ntc.nokia.com> Message-ID: <3F083254.1080701@piuha.net> Pasi.Eronen@nokia.com wrote: > EAP-04 comments > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: July 6, 2003 > Reference: > Document: RFC2284bis > Comment type: E/T > Priority: 1 > Section: various > Rationale/Explanation of issue: > > Overall, the draft looks fine, and it seems that we're finally > close to getting it finished! In hindsight, there are a couple > of things that might have been clearer if organized differently, > but it probably doesn't make sense to do such changes at this > point. > > --- > > (Section 2) "Since EAP is a peer-to-peer protocol, an > independent and simultaneous authentication may take place in > the reverse direction. Both peers may act as authenticators > and authenticatees at the same time. For a discussion of > security issues in peer-to-peer operation, see Section 7.7. > > I think this does not apply to all lower layers. Perhaps it > should be rephrased to something like "Some lower layers for > carrying EAP, such as PPP, may support peer-to-peer operation, > in which an indendent and...". Yes. [Alternative re-formulation: "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)."] > --- > > (Section 4.2) "Success or Failure packets MUST NOT be sent by > an EAP authenticator prior to completion of the final round > of a given method. A peer EAP implementation receiving a > Success or Failure packet prior to completion of the method > in progress MUST silently discard it." > > I think there are several EAP methods where the number of rounds > varies (so the phrase "the final round" is not well defined), > depending on many issues, including whether the method is > going to succeed or not. > > Perhaps this would better take that into account? > > "Success and Failure packets MUST NOT be sent by an EAP > authenticator if the specification of the given method does not > allow the method to finish at that point. A peer EAP > implementation receiving a Success or Failure packet where > sending one is not allowed MUST silently discard it." SOunds good! > --- > > (Section 4.2) "If the peer attempts to authenticate to the > authenticator and fails to do so, the authenticator MUST send a > Failure packet and MUST NOT grant access by sending a Success > packet." > > I know that this was beaten to death already :-) But since > we have not defined what "failing to authenticate to the > authenticator" means, does this actually impose any > requirements for EAP implementations? > > (The problem is that "failing to authenticate" could be thought > as "not successfully authenticating"; but according to the > definition of "successful authentication" in Section 1.2, the > above requirement does not make much sense.) > > Perhaps this would capture the intent? > > "If the peer attempts to authenticate to the authenticator using > a method that provides key derivation, the authenticator SHOULD > NOT grant access by sending a Success packet if the key > derivation has failed for some reason." Works for me. Maybe delete "for some reason". > --- > > (Section 5.7) "EAP Types from 0 through 255 are semantically > identical whether they appear as single octet EAP Types or as > Vendor-Types when Vendor-Id is zero." > > (Section 5.7) "An implementation that supports the Expanded > attribute MUST treat EAP Types that are less than 256 > equivalently whether they appear as a single octet or as the > 32-bit Vendor-Type within a Expanded Type where Vendor-Id is > 0." and > > Otherwise fine, but Expanded Nak packets have a different format > than Legacy Nak packets, so they are not treated exactly > identically. > > Perhaps we should add something like "There is one exception to > this rule: Expanded Nak and Legacy Nak packets share the same > code, but must be treated differently because they have a > different format." Yes. > --- > > Appendix B: Two significant changes to RFC 2284 are not > mentioned: mutual authentication and key derivation > (RFC 2284 did not even mention either of them). Ok. > ---- > > References: There are newer versions of RFC2869bis and SASLPREP > drafts available (Ok, RFC editor will probably handle these...) Better update them now, just for consistency. > ---- > > References: PIC is most likely dead and superseded by IKEv2, so > maybe we should remove references to PIC and add a pointer to > IKEv2? Yes! Thanks for your comments, Pasi. --Jari From jari.arkko@piuha.net Sun Jul 6 15:35:41 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 06 Jul 2003 17:35:41 +0300 Subject: [eap] EAP-04 lower layer indications In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB68@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BB68@esebe023.ntc.nokia.com> Message-ID: <3F0833BD.8060403@piuha.net> Pasi.Eronen@nokia.com wrote: > Section 3.4 says that > > "Section 4.2 defines the circumstances in which a peer, > having concluded an EAP method with successful acknowledged > result indications, may conclude that a Success packet has > been lost after expiration of a timeout. In those same > circumstances, if a peer receives a lower layer success > indication as defined in Section 7.2, it MAY conclude that a > Success packet has been lost without waiting for a > timeout. This ensures that an attacker spoofing lower layer > indications can at best succeed in a denial of service > attack." > > This is not exactly what the current state machine does... > > The current text says that "if you are in a situation where a > timeout would lead to success (that is, you have received a > method-specific success indication), also lower-layer success > indication does." > > What the current state mechine does is "if you are in a > situation where receiving an EAP Success packet would lead to > success, also lower-layer success indication does." Or in other > words, the effect of receiving a lower-layer success indication > is identical to receiving an EAP Success: if an EAP Success > packet would be silently discarded, so is the lower-layer > success indication. > > Both are IMHO quite reasonable approaches, and I just > wanted to clarify which one we really want to use? Hmm... if we get a method specific success indication, shouldn't we enable then in all three cases below: (a) Success received (b) Lower-layer success indication (c) Timeout? > A second issue: Earlier versions of the draft also mentioned > lower-layer failure indications (e.g. "Lower layer failure > indications provided to EAP by the lower layer MUST be processed > and will cause an EAP exchange in progress to be aborted." in > -03 version). This seems to be missing from -04, and I think > the old text still applies? Can't remember what happened to this. --Jari From alper@docomolabs-usa.com Mon Jul 7 05:46:07 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Sun, 06 Jul 2003 21:46:07 -0700 Subject: [eap] EAP-04 comments In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222BB@esebe023.ntc.nokia.com> Message-ID: > References: PIC is most likely dead and superseded by IKEv2, so > maybe we should remove references to PIC and add a pointer to > IKEv2? ... and to PANA. Alper From jsalowey@cisco.com Mon Jul 7 05:44:19 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Sun, 6 Jul 2003 21:44:19 -0700 Subject: [eap] EAP-OTP Message-ID: <006701c34442$6e205990$0200000a@amer.cisco.com> Does EAP-OTP provide replay protection? 2284bis-04 says no, but it seems that it should. From jsalowey@cisco.com Mon Jul 7 05:57:11 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Sun, 6 Jul 2003 21:57:11 -0700 Subject: [eap] Issue: Identity Response mismatch Message-ID: <006901c34444$3a825230$0200000a@amer.cisco.com> Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 7/6/2003 Reference: Document: RFC2284bis, RFC 2869bis Comment type: 'E' Priority: '1' Section: 7.3 Rationale/Explanation of issue: I could not find a place in the draft where it covers the possiblity that the Identity response differs from the identity that is authenticated by the EAP method. Requested change: Perhaps the following should be added to the security considerations section: "It is possible for the identity in the identity response to be different from the identity authenticated by the EAP method. This may be intentional in the case of identity privacy. An EAP method SHOULD use the authenticated identity when making access control decisions. A method MAY allow the use of the identity in the identity response if it is an authnorized alias for the authenticated identity." From jari.arkko@piuha.net Mon Jul 7 08:44:40 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 07 Jul 2003 10:44:40 +0300 Subject: [eap] Issue: Identity Response mismatch In-Reply-To: <006901c34444$3a825230$0200000a@amer.cisco.com> References: <006901c34444$3a825230$0200000a@amer.cisco.com> Message-ID: <3F0924E8.8010604@piuha.net> Joseph Salowey wrote: > I could not find a place in the draft where it covers the possiblity > that the Identity response differs from the identity that is > authenticated by the EAP method. > > Requested change: > > Perhaps the following should be added to the security considerations > section: > > "It is possible for the identity in the identity response to be > different from the identity authenticated by the EAP method. This may > be intentional in the case of identity privacy. An EAP method SHOULD > use the authenticated identity when making access control decisions. A Fine so far... > method MAY allow the use of the identity in the identity response if it > is an authnorized alias for the authenticated identity." This part I don't understand. Are you still talking about the case where the id resp != some method internal identity? --Jari From jari.arkko@piuha.net Mon Jul 7 08:44:46 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 07 Jul 2003 10:44:46 +0300 Subject: [eap] EAP-04 comments In-Reply-To: References: Message-ID: <3F0924EE.4090201@piuha.net> Alper Yegin wrote: >>References: PIC is most likely dead and superseded by IKEv2, so >>maybe we should remove references to PIC and add a pointer to >>IKEv2? > > > ... and to PANA. Yes, that can be done. (Both the IKEv2 and PANA references would be non-normative, by the way, so that we don't have to wait for either one to complete.) --Jari From Pasi.Eronen@nokia.com Mon Jul 7 09:14:12 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Mon, 7 Jul 2003 11:14:12 +0300 Subject: [eap] EAP-04 lower layer indications Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222BC@esebe023.ntc.nokia.com> Jari Arkko wrote: > Pasi.Eronen@nokia.com wrote: >=20 > > Section 3.4 says that=20 > >=20 > > "Section 4.2 defines the circumstances in which a peer, > > having concluded an EAP method with successful acknowledged > > result indications, may conclude that a Success packet has > > been lost after expiration of a timeout. In those same > > circumstances, if a peer receives a lower layer success > > indication as defined in Section 7.2, it MAY conclude that a > > Success packet has been lost without waiting for a > > timeout. This ensures that an attacker spoofing lower layer > > indications can at best succeed in a denial of service > > attack." > >=20 > > This is not exactly what the current state machine does... > >=20 > > The current text says that "if you are in a situation where a > > timeout would lead to success (that is, you have received a > > method-specific success indication), also lower-layer success > > indication does." > >=20 > > What the current state mechine does is "if you are in a > > situation where receiving an EAP Success packet would lead to > > success, also lower-layer success indication does." Or in other > > words, the effect of receiving a lower-layer success indication > > is identical to receiving an EAP Success: if an EAP Success > > packet would be silently discarded, so is the lower-layer > > success indication. > >=20 > > Both are IMHO quite reasonable approaches, and I just > > wanted to clarify which one we really want to use? >=20 > Hmm... if we get a method specific success indication, shouldn't > we enable then in all three cases below: > (a) Success received > (b) Lower-layer success indication > (c) Timeout? You're right, and that happens in both approaches. The only=20 difference is in what to do when we don't have a method specific=20 indication. In this case, - both approaches enable the link if Success is received - both approaches fail on timeout - the current state machine enables the link if lower-layer success indication is received, while 2284bis-04 says that the lower-layer success indication must be ignored (presumably leading to failure in timeout later). Which approach do you think we should use? Best regards, Pasi From hannes.tschofenig@siemens.com Mon Jul 7 09:34:02 2003 From: hannes.tschofenig@siemens.com (Tschofenig Hannes) Date: Mon, 7 Jul 2003 10:34:02 +0200 Subject: [eap] comments on draft-tschofenig-eap-ikev2-01.txt Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFF89@mchp905a.mch.sbs.de> hi bernard, thank you for your comments. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Friday, July 04, 2003 4:17 PM > To: eap@frascone.com > Subject: [eap] comments on draft-tschofenig-eap-ikev2-01.txt > > > Introduction > > Typically an introduction provides an overview of the > problem, the general > approach taken to solving it and the reasoning behind selection of the > solution approach. > > Reading this draft, I am unsure whether the objective is to create a > single EAP method utilizing basic IKEv2 modes (certificate, pre-shared > key) or whether the goal is to create another tunneling > method. Can you > clarify? sure. unlike other methods eap-ikev2 actually provides both. the method is, as such, applicable to a wide variety of environments. we noticed that some drafts add some framework aspects. we believe that this is not really useful since eap allows the to be used in different scenario (depending on the users / administrators choice). however, we it is true that the introduction still needs some work. > > Page 4, Message exchange: > > When is the EAP Identity exchange necessary/useful in EAP > IKEv2? IKEv2 > supports its own (protected) identity exchanges, and the method also > allows nested EAP Identity exchanges. it is true that eap-ikev2 provides user identity confidentiality for the identities used in the tunneled eap exchange. however, the protection is only passive. if you stress one sentence (with should not) in the ikev2 specification then you can use the eap identity exchange and experience active user identity confidentiality for the initiator. we have discussed this at the ipsec mailing list. however, user identity confidentiality seems to be a minor issue for many people (strange enough). > So you've got a lot of > different (and potentially conflicting) identity information > available. regarding the number of identities i guess there is no difference to other tunneling drafts (if tunneling is used). we are open to simplifications (if possible). > > Assuming that asymmetric IKEv2 features aren't used, can the > EAP server > play the role of IKEv2 Initiator? This would save a round-trip, no? in certain environments where you do not want to provide dos protection for the responder and where you don't want to use legacy authentication that is actually true. > > Page 6 > > " Since the goal of this EAP method is not to establish an IPsec SA > some payloads used in IKEv2 are omitted. In particularly the > following messages and payloads are not required: > > - Traffic Selectors > - IPsec SA negotiation payloads > (e.g. CREATE_CHILD_SA exchange or SAx2 payloads) > - ECN Notification > - Port handling > - NAT traversal" > > Yes, EAP IKEv2 need only carry out IKE SA creation. However, > a secure association > does need to be subsequently negotiated. So there is the > question of how > the IKE SA is subsequently bound to the (non-IPsec) Phase 2 SA. Any > thoughts on that? which non-IPsec security association would you like to create? > > Since address management is now supported within IKEv2, is > the intent to > allow IP address assignment within EAP? when we looked at securing the address configuration procedures in pana we discussed a number of possible approaches. we also noticed that ikev2 offers this functionality (not surprisingly since there was a long discussion about it on the ipsec mailing list). this is a possible approach. still we think that the pana-dhcp-bootstrapping approach provides a cleaner solution. > > Section 6 > > How is KEYMAT used to generate the MSK and EMSK? we need to discribe this - thanks for pointing to it. > > Section 8 > > Does EAP IKEv2 utilize Notifications? If not, that should be stated > explicitly. > > It would be useful to have a discussion of error handling. > When does the > method terminate with an EAP-IKEv2 method-specific error > message? Can an > EAP Failure always be silently discarded prior to method completion? true. we still need to provide proper error handling for the next version of the draft. yoshi ohba already pointed us to this gap. > > If the standard means of calculating IKEv2 MACs is used, then > the fields > of the EAP header will not be covered. Are there any security > implications of this? you mean the eap header ouside the eap-ikev2 method? the eap payload inside ikev2 is protected. ciao hannes > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Mon Jul 7 14:41:15 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 7 Jul 2003 06:41:15 -0700 (PDT) Subject: [eap] comments on draft-tschofenig-eap-ikev2-01.txt In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BBFF89@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F03BBFF89@mchp905a.mch.sbs.de> Message-ID: > which non-IPsec security association would you like to create? IEEE 802.11 encrypted communications with TKIP or AES CCMP, or in the future, IEEE 802 LINKSEC. > you mean the eap header ouside the eap-ikev2 method? the eap payload inside > ikev2 is protected. Right, the EAP header (Code, Identifier, Length, Type). From jsalowey@cisco.com Mon Jul 7 17:01:59 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Mon, 7 Jul 2003 09:01:59 -0700 Subject: [eap] Issue: Identity Response mismatch In-Reply-To: <3F0924E8.8010604@piuha.net> Message-ID: <008b01c344a1$19d9bf70$0200000a@amer.cisco.com> > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Monday, July 07, 2003 12:45 AM > To: Joseph Salowey > Cc: 'EAP mailing List' > Subject: Re: [eap] Issue: Identity Response mismatch > > > Joseph Salowey wrote: > > > I could not find a place in the draft where it covers the > possiblity > > that the Identity response differs from the identity that is > > authenticated by the EAP method. > > > > Requested change: > > > > Perhaps the following should be added to the security considerations > > section: > > > > "It is possible for the identity in the identity response to be > > different from the identity authenticated by the EAP > method. This may > > be intentional in the case of identity privacy. An EAP > method SHOULD > > use the authenticated identity when making access control > decisions. > > A > > Fine so far... > > > method MAY allow the use of the identity in the identity > response if > > it is an authnorized alias for the authenticated identity." > > This part I don't understand. Are you still talking about the > case where the id resp != some method internal identity? [Joe] Yes, It should probably say If a the identity in the identity response is an authorized alias of the authenticated identity the alias MAY use this identity for making access control decisions. Alternatively we could just say that the authenticated identity always takes precedence over the identity in the identity response when they differ. > > --Jari > > From jari.arkko@piuha.net Mon Jul 7 18:33:20 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 07 Jul 2003 20:33:20 +0300 Subject: [eap] Issue: Identity Response mismatch In-Reply-To: <008b01c344a1$19d9bf70$0200000a@amer.cisco.com> References: <008b01c344a1$19d9bf70$0200000a@amer.cisco.com> Message-ID: <3F09AEE0.8040109@piuha.net> Joseph Salowey wrote: > [Joe] Yes, It should probably say > > If a the identity in the identity response is an authorized alias of the > authenticated identity the alias MAY use this identity for making access > control decisions. Hmm... if its an alias, there does not appear to be much of a difference, or? > Alternatively we could just say that the authenticated identity always > takes precedence over the identity in the identity response when they > differ. This sounds good. --Jari From aboba@internaut.com Mon Jul 7 19:35:55 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 7 Jul 2003 11:35:55 -0700 (PDT) Subject: [eap] Question on Framed-MTU attribute Message-ID: In response to the question, we got back a number of responses noting that the maximum size of the EAP packet that can be sent by a RADIUS server is given by Framed-MTU - 4. Since Framed-MTU denotes the maximum size of an IP packet that can be transmitted over the wire between the Supplicant and the Authenticator, any additional overhead beyond that required for an IP packet needs to be taken into account. For example, in IEEE 802.1X, there are 4 octets of additional overhead beyond what might be required for an IP packet -- the 802.1X Version (1), Type(1) and Body Length(2) fields. In PPP, there are also 4 octets of additional overhead, namely the Type (1), Length (1) and Authentication-Protocol (2) fields of the Authentication-Protocol Configuration Option format defined in [RFC 1661]. Here is what draft-congdon says about the Framed-MTU attribute: "This attribute indicates the maximum size of an IP packet that may be transmitted over the wire between the Supplicant and the Authenticator. IEEE 802.1X Authenticators set this to the value corresponding to the relevant 802 medium, and include it in the RADIUS Access-Request. For EAP over IEEE 802 media, the Framed-MTU values (which do not include LLC/SNAP overhead) and maximum frame length values (not including the preamble) are as follows: .nf Maximum Frame Media Framed-MTU Length ========= =============== ============== Ethernet 1500 1522 802.3 1500 1522 802.4 8174 8193 802.5 (4 Mbps) 4528 4550 802.5 (16 Mbps) 18173 18200 802.5 (100 Mb/s) 18173 18200 802.6 9191 9240 802.9a 1500 1518 802.11 2304 2346 802.12 (Ethernet) 1500 1518 802.12 (Token Ring) 4502 4528 FDDI 4479 4500" I am thinking that the need to subtract out 4 octets should probably be included in the above paragraph. From aboba@internaut.com Tue Jul 8 04:09:32 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 7 Jul 2003 20:09:32 -0700 (PDT) Subject: [eap] Issue 156: Terminology reorganization Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: July 6, 2003 Reference: Document: EAP-04 Comment type: T Priority: S Section: 1.2, 1.3, 7.2.1 Rationale/Explanation of issue: The security claims terminology is best left with the rest of the security claims section 7.2. Also, the definitions of Man-in-the-Middle resistance and Cryptographic binding appear to overlap. Change Section 1.2 to the following: "1.2 Terminology This document frequently uses the following terms: authenticator The end of the link initiating EAP authentication. The term Authenticator is used in [IEEE-802.1X], and authenticator has the same meaning in this document. peer The end of the link that responds to the authenticator. In [IEEE-802.1X], this end is known as the Supplicant. backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X]. Displayable Message This is interpreted to be a human readable string of characters. The message encoding MUST follow the UTF-8 transformation format [RFC2279]. EAP server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server. Silently Discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the event, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. Successful authentication In the context of this document, "successful authentication" is an exchange of EAP messages, as a result of which the authenticator decides to allow access by the peer, and the peer decides to use this access. The authenticator's decision typically involves both authentication and authorization aspects; the peer may successfully authenticate to the authenticator but access may be denied by the authenticator due to policy reasons. Message Integrity Check (MIC) A keyed hash function used for authentication and integrity protection of data. This is usually called a Message Authentication Code (MAC), but IEEE 802 specifications (and this document) use the acronym MIC to avoid confusion with Medium Access Control. Cryptographic separation Two keys (x and y) are "cryptographically separate" if an adversary that knows all messages exchanged in the protocol cannot compute x from y or y from x without "breaking" some cryptographic assumption. In particular, this definition allows that the adversary has the knowledge of all nonces sent in cleartext as well as all predictable counter values used in the protocol. Breaking a cryptographic assumption would typically require inverting a one-way function or predicting the outcome of a cryptographic pseudo-random number generator without knowledge of the secret state. 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. Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is used in the derivation of Transient Session Keys (TSKs) for the ciphersuite negotiated between the EAP peer and authenticator. Where a backend authentication server is present, acting as an EAP server, it will typically transport the MSK to the authenticator, so that in this case, the MSK is available to the peer, authenticator and authentication server. Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. Unlike the MSK, the EMSK is known only to the EAP peer and EAP server and is not provided to a third party. The EMSK is reserved for future uses that are not defined yet. For example, it could be used to derive additional keying material for purposes such as fast handoff, cryptographic binding, etc." Delete Section 1.3. Add Section 7.2.1: "7.2.1 Security claims terminology for EAP methods These terms are used to described the security properties of EAP methods: Mutual authentication This refers to an EAP method in which, within an interlocked exchange, the authenticator authenticates the peer and the peer authenticates the authenticator. Two independent one-way methods, running in opposite directions do not provide mutual authentication as defined here. Integrity protection This refers to providing data origin authentication and protection against unauthorized modification of information for EAP packets (including EAP Requests and Responses). When making this claim, a method specification MUST describe the EAP packets and fields within the EAP packet that are protected. Replay protection This refers to protection against replay of an EAP method or its messages, including method-specific success and failure indications. Confidentiality This refers to encryption of EAP messages, including EAP Requests and Responses, and method-specific success and failure indications. A method making this claim MUST support identity protection (see Section 7.3). Key derivation This refers to the ability of the EAP method to derive exportable keying material such as the Master Session Key (MSK), and Extended Master Session Key (EMSK). The MSK is used only for further key derivation, not directly for protection of the EAP conversation or subsequent data. Use of the EMSK is reserved. Key strength If the effective key strength is N bits, the best currently known methods to recover the key (with non-negligible probability) require an effort comparable to 2^N operations of a typical block cipher. Dictionary attack protection Where password authentication is used, users are notoriously prone to select poor passwords. A method may be said to be dictionary attack resistant if, when there is a weak password in the secret, the method does not allow an attack more efficient than brute force. Fast reconnect The ability, in the case where a security association has been previously established, to create a new or refreshed security association in a smaller number of round-trips. Cryptographic binding The demonstration of the EAP peer to the EAP server that a single entity has acted as the EAP peer for all methods executed within a tunnel method. Binding MAY also imply that the EAP server demonstrates to the peer that a single entity has acted as the EAP server for all methods executed within a tunnel method. If executed correctly, binding serves to mitigate man-in-the-middle vulnerabilities. Acknowledged result indications The ability within a method for the authenticator to indicate to the peer whether it has successfully authenticated to it, and for the peer to acknowledge receipt of that indication as well as indicating to the authenticator whether it has successfully authenticated to the peer. Since EAP Success and Failure packets are neither acknowledged nor integrity protected, this claim requires implementation of a method-specific result exchange that is authenticated, integrity and replay protected on a per-packet basis." From aboba@internaut.com Tue Jul 8 04:18:18 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 7 Jul 2003 20:18:18 -0700 (PDT) Subject: [eap] (no subject) Message-ID: Issue 157: Order of attribute processing Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: July 6, 2003 Reference: Document: RFC 2869bis-22 Comment type: T Priority: S Section: 2.6.4, 3, Appendix B Rationale/Explanation of issue: Existing implementations process EAP-Message attributes first, and changing the processing order will cause backward compatibility issues as well as problems with operation of IEEE 802.11i. If approved, this change will be made in Author 48 hours, since the draft has already been approved for publication as an RFC. In Section 2.6.4, change: "Reject or Access-Challenge, the NAS SHOULD process other attributes first, then decapsulate EAP-Message attribute(s), reconstitute the EAP packet and send it to the peer." To: "Reject or Access-Challenge, the NAS SHOULD first decapsulate EAP-Message attribute(s), reconstitute the EAP packet and send it to the peer, then process other attributes." In Section 3 , change: "difficult to manage." To: "difficult to manage. The User-Name attribute within the Access-Accept packet need not be the same as the User-Name attribute in the Access- Request." In Appendix B , change: "EAP-Message attributes are processed last (Section 2.6.4)." To: "EAP-Message attributes are processed first (Section 2.6.4)." From aboba@internaut.com Tue Jul 8 04:21:54 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 7 Jul 2003 20:21:54 -0700 (PDT) Subject: [eap] Issue 157: Order of attribute processing Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: July 6, 2003 Reference: Document: RFC 2869bis-22 Comment type: T Priority: S Section: 2.6.4, 3, Appendix B Rationale/Explanation of issue: Existing implementations process EAP-Message attributes first, and changing the processing order will cause backward compatibility issues as well as problems with operation of IEEE 802.11i. If approved, this change will be made in Author 48 hours, since the draft has already been approved for publication as an RFC. In Section 2.6.4, change: "Reject or Access-Challenge, the NAS SHOULD process other attributes first, then decapsulate EAP-Message attribute(s), reconstitute the EAP packet and send it to the peer." To: "Reject or Access-Challenge, the NAS SHOULD first decapsulate EAP-Message attribute(s), reconstitute the EAP packet and send it to the peer, then process other attributes." In Section 3 , change: "difficult to manage." To: "difficult to manage. The User-Name attribute within the Access-Accept packet need not be the same as the User-Name attribute in the Access- Request." In Appendix B , change: "EAP-Message attributes are processed last (Section 2.6.4)." To: "EAP-Message attributes are processed first (Section 2.6.4)." From aboba@internaut.com Tue Jul 8 04:42:58 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 7 Jul 2003 20:42:58 -0700 (PDT) Subject: [eap] Issue 158: Miscellaneous Nits Message-ID: Issue 158: Miscellaneous Nits Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: July 6, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-July/001430.html Document: EAP-04 Comment type: E Priority: S Section: 3.1, 5, 7.2, 7.3, 7.5, A.1 Rationale/Explanation of issue: In Section 3.1, move the following text to section 3.4: " After EAP authentication is complete, the peer will typically transmit data to the network via the authenticator. In order to provide assurance that the peer transmitting data is the same entity that successfully completed EAP authentication, the lower layer needs to bind per-packet integrity, authentication and replay protection to the original EAP authentication, using keys derived during EAP authentication. Alternatively, the lower layer needs to be physically secure. Otherwise it is possible for subsequent data traffic to be hijacked, or replayed. As a result of these considerations, EAP SHOULD be used only when lower layers provide physical security for data (e.g., wired PPP or IEEE 802 links), or for insecure links, where per-packet authentication, integrity and replay protection is provided. Where keying material for the lower layer ciphersuite is itself provided by EAP, ciphersuite negotiation and key activation is controlled by the lower layer. In PPP, ciphersuites are negotiated within ECP so that it is not possible to use keys derived from EAP authentication until the completion of ECP. Therefore an initial EAP exchange cannot protected by a PPP ciphersuite, although EAP re-authentication can be protected. In IEEE 802 media, key activation also typically occurs after completion of EAP authentication. Therefore an initial EAP exchange typically cannot be protected by lower layer ciphersuite, although an EAP re-authentication or pre-authentication exchange can be protected." In Section 3.1, indent the following paragraph: "The Point-to-Point Protocol is designed for simple links which transport packets between two peers. These links provide full-duplex simultaneous bi-directional operation, and are assumed to deliver packets in order." In Section 5, change "MITM resistance:" to "Crypt. binding:" (Since we no longer have a definition of Man-in-the-Middle resistance) In Section 7.2, change "man-in-the-middle resistance" to "cryptographic binding" In Section 7.3, Change "Identity-Response" to "EAP-Response/Identity" (two times) Delete Section A.1, and change Section 7.5 to the following: "7.5 Packet modification attacks While EAP methods may support per-packet data origin authentication, integrity and replay protection, support is not provided within the EAP layer. Since the Identifier is only a single octet, it is easy to guess, allowing an attacker to successfully inject or replay EAP packets. An attacker may also modify EAP headers (Code, Identifier, Length, Type) within EAP packets where the header is unprotected. This could cause packets to be inappropriately discarded or misinterpreted. In the case of PPP and IEEE 802 wired links, it is assumed that such attacks are restricted to attackers who can gain access to the physical link. However, where EAP is run over physically insecure lower layers such as wireless (802.11 or cellular) or the Internet (such as within protocols supporting PPP, EAP or Ethernet Tunneling), this assumption is no longer valid and the vulnerability to attack is greater. To protect EAP messages sent over physically insecure lower layers, methods providing mutual authentication and key derivation, as well as per-packet origin authentication, integrity and replay protection SHOULD be used. Method-specific MICs may be used to provide protection. If a per-packet MIC is employed within an EAP method, then peers, authentication servers, and authenticators not operating in pass-through mode MUST validate the MIC. MIC validation failures SHOULD be logged. Whether a MIC validation failure is considered a fatal error or not is determined by the EAP method specification. Since EAP messages of Types Identity, Notification, and Nak do not include their own MIC, it may be desirable for the EAP method MIC to cover information contained within these messages, as well as the header of each EAP message. For details, see Appendix A. To provide protection, EAP also may be encapsulated within a protected channel created by protocols such as ISAKMP [RFC2408] as is done in [IKEv2] or within TLS [RFC2246]. However, as noted in Section 7.4, EAP tunneling may result in a man-in-the-middle vulnerability. Existing EAP methods define message integrity checks (MICs) that cover more than one EAP packet. For example, EAP-TLS [RFC2716] defines a MIC over a TLS record that could be split into multiple fragments; within the FINISHED message, the MIC is computed over previous messages. Where the MIC covers more than one EAP packet, a MIC validation failure is typically considered a fatal error. Within EAP-TLS [RFC2716] a MIC validation failure is treated as a fatal error, since that is what is specified in TLS [RFC2246]. However, it is also possible to develop EAP methods that support per-packet MICs, and respond to verification failures by silently discarding the offending packet. In this document, descriptions of EAP message handling assume that per-packet MIC validation, where it occurs, is effectively performed as though it occurs before sending any responses or changing the state of the host which received the packet." From jari.arkko@piuha.net Tue Jul 8 08:14:59 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 08 Jul 2003 10:14:59 +0300 Subject: [eap] EAP-04 lower layer indications In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222BC@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A61222BC@esebe023.ntc.nokia.com> Message-ID: <3F0A6F73.2000909@piuha.net> Pasi.Eronen@nokia.com wrote: > You're right, and that happens in both approaches. The only > difference is in what to do when we don't have a method specific > indication. In this case, > > - both approaches enable the link if Success is received > - both approaches fail on timeout > - the current state machine enables the link if lower-layer > success indication is received, while 2284bis-04 says that > the lower-layer success indication must be ignored > (presumably leading to failure in timeout later). > > Which approach do you think we should use? Ok, I see. There doesn't appear to be a security difference, since Success can most likely be spoofed at least as easily as lower-layer success indication. But there has been a lot of discussion around lower layer indications in the past, so I'm inclined to trust 2284bis more on this. Bernard, do you remember why 2284bis ignores lower-layer success indications? --Jari From hannes.tschofenig@siemens.com Tue Jul 8 10:28:10 2003 From: hannes.tschofenig@siemens.com (Tschofenig Hannes) Date: Tue, 8 Jul 2003 11:28:10 +0200 Subject: [eap] comments on draft-tschofenig-eap-ikev2-01.txt Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFF9E@mchp905a.mch.sbs.de> hi bernard, > Introduction > > Typically an introduction provides an overview of the > problem, the general > approach taken to solving it and the reasoning behind selection of the > solution approach. > > Reading this draft, I am unsure whether the objective is to create a > single EAP method utilizing basic IKEv2 modes (certificate, pre-shared > key) or whether the goal is to create another tunneling > method. Can you > clarify? jari gave us a comment on the previous version of the draft regarding the missing/unclear introduction. i thought that i corrected it by copying a proposal of dirk into the new version. unfortunately this change got lost somehow. this makes you comment concerning the missing introduction much clearer. you are certainly right - i should correct that. >> which non-IPsec security association would you like to create? > IEEE 802.11 encrypted communications with TKIP or AES CCMP, or in the > future, IEEE 802 LINKSEC. if i understood eap and the keying framework correctly (i hope so :-)) then the actual usage of the session keys derived with eap should be independent of the eap method itself. wouldn't it defeat the purpose of the keying framework if everyone specifies how to derive keys for these particular environments. please correct me if i am wrong. hence with regard to the keying framework the eap-ikev2 would export the msk, emsk and the iv only. these keys have to be derived from the ike-sa (as mentioned by you the draft needs to be more specific at that place - some parts are missing at the moment). >> you mean the eap header ouside the eap-ikev2 method? the eap payload inside >> ikev2 is protected. > Right, the EAP header (Code, Identifier, Length, Type). yoshi ohba pointed me to this problem with regard to fragmentation and the eap success message. this sounds like a more general discussion. after some exchanges you have a session key available which would possible allow you to protect the headers (and some other payloads such as messages related to fragmentation). we wanted to discuss the problem of protecting fragmentation specific messages next sunday. thanks again for pointing us to open issues. ciao hannes From aboba@internaut.com Tue Jul 8 13:29:36 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Jul 2003 05:29:36 -0700 (PDT) Subject: [eap] EAP-04 lower layer indications In-Reply-To: <3F0A6F73.2000909@piuha.net> References: <052E0C61B69C3741AFA5FE88ACC775A61222BC@esebe023.ntc.nokia.com> <3F0A6F73.2000909@piuha.net> Message-ID: > Ok, I see. There doesn't appear to be a security > difference, since Success can most likely be spoofed > at least as easily as lower-layer success indication. > But there has been a lot of discussion around lower > layer indications in the past, so I'm inclined to > trust 2284bis more on this. Bernard, do you remember > why 2284bis ignores lower-layer success indications? When we did the implementation survey, we found that nobody implemented this part of the specification. From aboba@internaut.com Tue Jul 8 13:47:12 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Jul 2003 05:47:12 -0700 (PDT) Subject: [eap] comments on draft-tschofenig-eap-ikev2-01.txt In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BBFF9E@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F03BBFF9E@mchp905a.mch.sbs.de> Message-ID: > if i understood eap and the keying framework correctly (i hope so :-)) then > the actual usage of the session keys derived with eap should be independent > of the eap method itself. wouldn't it defeat the purpose of the keying > framework if everyone specifies how to derive keys for these particular > environments. please correct me if i am wrong. EAP methods do not derive sessions keys. They derive keying material -- much as IKE Phase 1 derives the keying material used to subsequently derive IKE Phase 2 SAs. To satisfy Russ's requirements an EAP equivalent of IKE Phase 2 is subsequently necessary, and the question is how EAP methods (Phase 1) bind their keying material to the Phase 2. This is what Russ referred to as "key naming". In order to know which EAP Phase 1 keying material is to be used to form the Phase 2 SA, presumably the EAP method needs to export a "key name" of some kind. During the EAP WG meeting at IETF 57 we'll try to get some clarity about exactly what the "key name" is. Most existing EAP methods have something equivalent to this. For example, in EAP TLS, TTLS or PEAP it is the "sessionid" + Client/Server identities -- this uniquely describes the session, and therefore the keying material arising from it. In EAP IKEv2, I believe that the equivalent is the IKE Cookies + the ID payloads of the parties. The "key name" needs to be provided to the NAS along with the "keying material" by AAA, and then used by the NAS in the Phase 2 key exchange in order to inform the peer what keying material is being used to derive the transient session keys as part of the Phase 2 exchange. I'd note that there may be other alternative possiblities for providing the "key name", but they tend to involve lots of computation on the EAP peer. For example, a hash of the keying material can be sent by the NAS, but that divulges a lot of information about the key itself, and may not meet Russ's requirement for algorithm independence. Also, if there are a lot of potential keys (as there might be say, where fast handoff is supported), then the EAP peer might have to go through quite a few computations in order to find keying material that matches a particular hash. For example, the keying material for AP C might be derived from the EMSK derived during an exchange at AP B, or it might be a transferred PMK from AP A or AP B, or... With a unique "key name" things are much simpler (and faster) because the EAP peer just looks up the key in the key cache using the key name. > hence with regard to the keying framework the eap-ikev2 would export the > msk, emsk and the iv only. these keys have to be derived from the ike-sa (as > mentioned by you the draft needs to be more specific at that place - some > parts are missing at the moment). Yes -- the IV is optional, I believe. From jari.arkko@piuha.net Tue Jul 8 15:00:18 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 08 Jul 2003 17:00:18 +0300 Subject: [eap] EAP-04 lower layer indications In-Reply-To: References: <052E0C61B69C3741AFA5FE88ACC775A61222BC@esebe023.ntc.nokia.com> <3F0A6F73.2000909@piuha.net> Message-ID: <3F0ACE72.2060400@piuha.net> Bernard Aboba wrote: >>Ok, I see. There doesn't appear to be a security >>difference, since Success can most likely be spoofed >>at least as easily as lower-layer success indication. >>But there has been a lot of discussion around lower >>layer indications in the past, so I'm inclined to >>trust 2284bis more on this. Bernard, do you remember >>why 2284bis ignores lower-layer success indications? > > When we did the implementation survey, we found that nobody implemented > this part of the specification. Oh. While it seems perhaps a bit funny way to look at the implementations for guidance in what the specification should do, this is a fact of life when working with an already deployed protocol. Maybe we should keep 2284bis as is, and change the state machine regarding this point. Pasi, what do you think? --Jari From hannes.tschofenig@siemens.com Tue Jul 8 15:35:08 2003 From: hannes.tschofenig@siemens.com (Tschofenig Hannes) Date: Tue, 8 Jul 2003 16:35:08 +0200 Subject: [eap] comments on draft-tschofenig-eap-ikev2-01.txt Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFFA5@mchp905a.mch.sbs.de> hi bernard, thanks for raising russ's requirements on key derivation. the current text in the eap-ikev2 key derivation section suggests to reuse the key derivation function proposed in section 2.17 of ikev2. this is the key derivation function which is used for creating ipsec sas. without pfs (which i assume is not necessary of eap-ikev2) the key derivation function is : KEYMAT = prf+(SK_d, Ni | Nr) ikev2 (and hence eap-ikev2) only include nonces (the SK_d key is again based on nonces only) and does not something like cookies, id payloads of the two parties, etc. into the key derivation. we will update the key derivation function to incorporate these payloads if necessary. reading russ's requirements i had the impression that his main concern is primiarly towards the protocol which uses the keys (key material) afterwards. this might be, for example, link layer encryption (or better a protocol for establishing the security association which are used to provide link layer security). actually we had a number of questions during the process of working on pana / dhcp bootstrapping. we looked at the existing documents which address this problem e.g. your "EAP Keying Framework" draft, the "AAA key distribution" draft and russ's slides from the last ietf. when we tried to write down a key derivation function which fullfills the requirements we thought that there might be a need to illustrate the security properties a little bit more. we hope to get more details on it during the next ietf. ciao hannes > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, July 08, 2003 2:47 PM > To: Tschofenig Hannes > Cc: eap@frascone.com; Kroeselberg Dirk > Subject: RE: [eap] comments on draft-tschofenig-eap-ikev2-01.txt > > > > if i understood eap and the keying framework correctly (i > hope so :-)) then > > the actual usage of the session keys derived with eap > should be independent > > of the eap method itself. wouldn't it defeat the purpose of > the keying > > framework if everyone specifies how to derive keys for > these particular > > environments. please correct me if i am wrong. > > EAP methods do not derive sessions keys. They derive keying > material -- > much as IKE Phase 1 derives the keying material used to subsequently > derive IKE Phase 2 SAs. > > To satisfy Russ's requirements an EAP equivalent of IKE Phase 2 is > subsequently necessary, and the question is how EAP methods > (Phase 1) bind > their keying material to the Phase 2. This is what Russ referred to as > "key naming". In order to know which EAP Phase 1 keying > material is to be > used to form the Phase 2 SA, presumably the EAP method needs to export > a "key name" of some kind. > > During the EAP WG meeting at IETF 57 we'll try to get some > clarity about > exactly what the "key name" is. Most existing EAP methods > have something > equivalent to this. For example, in EAP TLS, TTLS or PEAP it is the > "sessionid" + Client/Server identities -- this uniquely describes the > session, and therefore the keying material arising from it. > In EAP IKEv2, > I believe that the equivalent is the IKE Cookies + the ID > payloads of the parties. > > The "key name" needs to be provided to the NAS along with the "keying > material" by AAA, and then used by the NAS in the Phase 2 key > exchange in > order to inform the peer what keying material is being used > to derive the > transient session keys as part of the Phase 2 exchange. > > I'd note that there may be other alternative possiblities for > providing > the "key name", but they tend to involve lots of computation > on the EAP > peer. For example, a hash of the keying material can be sent > by the NAS, > but that divulges a lot of information about the key itself, > and may not > meet Russ's requirement for algorithm independence. Also, if > there are a > lot of potential keys (as there might be say, where fast handoff is > supported), then the EAP peer might have to go through quite a few > computations in order to find keying material that matches a > particular > hash. For example, the keying material for AP C might be > derived from the > EMSK derived during an exchange at AP B, or it might be a > transferred PMK > from AP A or AP B, or... With a unique "key name" things are much > simpler (and faster) because the EAP peer just looks up the > key in the key > cache using the key name. > > > hence with regard to the keying framework the eap-ikev2 > would export the > > msk, emsk and the iv only. these keys have to be derived > from the ike-sa (as > > mentioned by you the draft needs to be more specific at > that place - some > > parts are missing at the moment). > > Yes -- the IV is optional, I believe. > From aboba@internaut.com Tue Jul 8 15:44:06 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Jul 2003 07:44:06 -0700 (PDT) Subject: [eap] comments on draft-tschofenig-eap-ikev2-01.txt In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BBFFA5@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F03BBFFA5@mchp905a.mch.sbs.de> Message-ID: > the current text in the eap-ikev2 key derivation section suggests to reuse > the key derivation function proposed in section 2.17 of ikev2. this is the > key derivation function which is used for creating ipsec sas. without pfs > (which i assume is not necessary of eap-ikev2) the key derivation function > is : KEYMAT = prf+(SK_d, Ni | Nr) Russ's requirements are that compromise of a single NAS not result in compromise at other NASes. I think this requires cryptographic independence between keying material at each NAS. There is also a requirement for freshness both in the keying material and in the transient session keys. Typically a nonce exchange in both phases will accomplish this. > ikev2 (and hence eap-ikev2) only include nonces (the SK_d key is again based > on nonces only) and does not something like cookies, id payloads of the two > parties, etc. into the key derivation. we will update the key derivation > function to incorporate these payloads if necessary. I don't think that the "key name" needs to be part of the key derivation to qualify -- it's just an identifier that uniquely identifies the security association -- much as the SPI and dest address do for IPsec (phase 2 SAs). The answer to the question "what is the key name?" is usually provided by asking the question "if I wanted to continue the exchange, or do a rekey, how would I identify what SA is to be continued/rekeyed?" > reading russ's requirements i had the impression that his main concern is > primiarly towards the protocol which uses the keys (key material) > afterwards. this might be, for example, link layer encryption (or better a > protocol for establishing the security association which are used to provide > link layer security). Yes, most of the requirements are satisfied in the Phase 2 protocol (freshness of transient session keys, secure capabilities negotiation, mutual authentication, replay protection, binding of transient session keys to the secure association, key synchronization). However, there is a requirement for "key naming" which is critical in linking the EAP (Phase 1) exchange to the subsequent secure association (Phase 2) exchange. So far, this aspect has been neglected because the link was fairly trivial -- the Phase 2 always occurred between the same parties as Phase 1 and there was only one Phase 2 SA possible between a peer and NAS. However, with roaming and things like LINKSEC on the horizon, things get a lot more complicated. The Phase 2 SA may be generated from a Phase 1 (EAP) conversation run over a different NAS; the Phase 2 SA could be generated from an MSK or an EMSK; there could be more than one Phase 2 SA generated from a Phase 1 SA, each with different security parameters. To make sure that the system works in these scenarios the requirement for "key naming" is critical -- otherwise there is no way to make it clear to the peer what key is relevant to a particular Phase 2 conversation. > actually we had a number of questions during the process of working on pana > / dhcp bootstrapping. we looked at the existing documents which address this > problem e.g. your "EAP Keying Framework" draft, the "AAA key distribution" > draft and russ's slides from the last ietf. when we tried to write down a > key derivation function which fullfills the requirements we thought that > there might be a need to illustrate the security properties a little bit > more. we hope to get more details on it during the next ietf. I think this is a very good discussion to have during IETF 57, during the Thursday session. I am not sure we will end up with a lot of answers, but at least we will have identified the questions. From jsalowey@cisco.com Tue Jul 8 17:28:45 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Tue, 8 Jul 2003 09:28:45 -0700 Subject: [eap] comments on draft-tschofenig-eap-ikev2-01.txt In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BBFFA5@mchp905a.mch.sbs.de> Message-ID: <000601c3456e$01f55400$0200000a@amer.cisco.com> > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Tschofenig Hannes > Sent: Tuesday, July 08, 2003 7:35 AM > To: 'Bernard Aboba' > Cc: eap@frascone.com; Kroeselberg Dirk > Subject: RE: [eap] comments on draft-tschofenig-eap-ikev2-01.txt > > > hi bernard, > > thanks for raising russ's requirements on key derivation. > > the current text in the eap-ikev2 key derivation section > suggests to reuse the key derivation function proposed in > section 2.17 of ikev2. this is the key derivation function > which is used for creating ipsec sas. without pfs (which i > assume is not necessary of eap-ikev2) the key derivation > function is : KEYMAT = prf+(SK_d, Ni | Nr) > > ikev2 (and hence eap-ikev2) only include nonces (the SK_d key > is again based on nonces only) and does not something like > cookies, id payloads of the two parties, etc. into the key > derivation. we will update the key derivation function to > incorporate these payloads if necessary. > > reading russ's requirements i had the impression that his > main concern is primiarly towards the protocol which uses the > keys (key material) afterwards. this might be, for example, > link layer encryption (or better a protocol for establishing > the security association which are used to provide link layer > security). > > actually we had a number of questions during the process of > working on pana / dhcp bootstrapping. we looked at the > existing documents which address this problem e.g. your "EAP > Keying Framework" draft, the "AAA key distribution" draft and > russ's slides from the last ietf. when we tried to write down > a key derivation function which fullfills the requirements we > thought that there might be a need to illustrate the security > properties a little bit more. we hope to get more details on > it during the next ietf. [Joe] You might also want to look at http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt This draft outlines a way to consistently derive keys from the EMSK for different applications to maitain separation and avoid conflicts. > > ciao > hannes > > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Tuesday, July 08, 2003 2:47 PM > > To: Tschofenig Hannes > > Cc: eap@frascone.com; Kroeselberg Dirk > > Subject: RE: [eap] comments on draft-tschofenig-eap-ikev2-01.txt > > > > > > > if i understood eap and the keying framework correctly (i > > hope so :-)) then > > > the actual usage of the session keys derived with eap > > should be independent > > > of the eap method itself. wouldn't it defeat the purpose of > > the keying > > > framework if everyone specifies how to derive keys for > > these particular > > > environments. please correct me if i am wrong. > > > > EAP methods do not derive sessions keys. They derive keying > > material -- > > much as IKE Phase 1 derives the keying material used to subsequently > > derive IKE Phase 2 SAs. > > > > To satisfy Russ's requirements an EAP equivalent of IKE Phase 2 is > > subsequently necessary, and the question is how EAP methods > (Phase 1) > > bind their keying material to the Phase 2. This is what > Russ referred > > to as "key naming". In order to know which EAP Phase 1 keying > > material is to be > > used to form the Phase 2 SA, presumably the EAP method > needs to export > > a "key name" of some kind. > > > > During the EAP WG meeting at IETF 57 we'll try to get some > > clarity about > > exactly what the "key name" is. Most existing EAP methods > > have something > > equivalent to this. For example, in EAP TLS, TTLS or PEAP it is the > > "sessionid" + Client/Server identities -- this uniquely > describes the > > session, and therefore the keying material arising from it. > > In EAP IKEv2, > > I believe that the equivalent is the IKE Cookies + the ID > > payloads of the parties. > > > > The "key name" needs to be provided to the NAS along with > the "keying > > material" by AAA, and then used by the NAS in the Phase 2 > key exchange > > in order to inform the peer what keying material is being used > > to derive the > > transient session keys as part of the Phase 2 exchange. > > > > I'd note that there may be other alternative possiblities for > > providing > > the "key name", but they tend to involve lots of computation > > on the EAP > > peer. For example, a hash of the keying material can be sent > > by the NAS, > > but that divulges a lot of information about the key itself, > > and may not > > meet Russ's requirement for algorithm independence. Also, if > > there are a > > lot of potential keys (as there might be say, where fast handoff is > > supported), then the EAP peer might have to go through quite a few > > computations in order to find keying material that matches a > > particular > > hash. For example, the keying material for AP C might be > > derived from the > > EMSK derived during an exchange at AP B, or it might be a > > transferred PMK > > from AP A or AP B, or... With a unique "key name" things are much > > simpler (and faster) because the EAP peer just looks up the > > key in the key > > cache using the key name. > > > > > hence with regard to the keying framework the eap-ikev2 > > would export the > > > msk, emsk and the iv only. these keys have to be derived > > from the ike-sa (as > > > mentioned by you the draft needs to be more specific at > > that place - some > > > parts are missing at the moment). > > > > Yes -- the IV is optional, I believe. > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jrv@umich.edu Tue Jul 8 23:04:32 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 08 Jul 2003 18:04:32 -0400 Subject: [eap] EAP-04 lower layer indications In-Reply-To: <3F0833BD.8060403@piuha.net> References: <052E0C61B69C3741AFA5FE88ACC775A608BB68@esebe023.ntc.nokia.com> <3F0833BD.8060403@piuha.net> Message-ID: <2418905.1057687472@localhost> --On Sunday, July 6, 2003 5:35 PM +0300 Jari Arkko wrote: > Pasi.Eronen@nokia.com wrote: > > > Section 3.4 says that > > > > "Section 4.2 defines the circumstances in which a peer, > > having concluded an EAP method with successful acknowledged > > result indications, may conclude that a Success packet has > > been lost after expiration of a timeout. In those same > > circumstances, if a peer receives a lower layer success > > indication as defined in Section 7.2, it MAY conclude that a > > Success packet has been lost without waiting for a > > timeout. This ensures that an attacker spoofing lower layer > > indications can at best succeed in a denial of service > > attack." > > > > This is not exactly what the current state machine does... > > > > The current text says that "if you are in a situation where a > > timeout would lead to success (that is, you have received a > > method-specific success indication), also lower-layer success > > indication does." > > > > What the current state mechine does is "if you are in a > > situation where receiving an EAP Success packet would lead to > > success, also lower-layer success indication does." Or in other > > words, the effect of receiving a lower-layer success indication > > is identical to receiving an EAP Success: if an EAP Success > > packet would be silently discarded, so is the lower-layer > > success indication. > > > > Both are IMHO quite reasonable approaches, and I just > > wanted to clarify which one we really want to use? > > Hmm... if we get a method specific success indication, shouldn't > we enable then in all three cases below: > (a) Success received > (b) Lower-layer success indication > (c) Timeout? > seems right to me > > A second issue: Earlier versions of the draft also mentioned > > lower-layer failure indications (e.g. "Lower layer failure > > indications provided to EAP by the lower layer MUST be processed > > and will cause an EAP exchange in progress to be aborted." in > > -03 version). This seems to be missing from -04, and I think > > the old text still applies? > > Can't remember what happened to this. > > --Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jrv@umich.edu Tue Jul 8 23:08:19 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 08 Jul 2003 18:08:19 -0400 Subject: [eap] Issue: Identity Response mismatch In-Reply-To: <006901c34444$3a825230$0200000a@amer.cisco.com> References: <006901c34444$3a825230$0200000a@amer.cisco.com> Message-ID: <2432510.1057687699@localhost> This seems good to me --On Sunday, July 6, 2003 9:57 PM -0700 Joseph Salowey wrote: > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date first submitted: 7/6/2003 > Reference: > Document: RFC2284bis, RFC 2869bis > Comment type: 'E' > Priority: '1' > Section: 7.3 > Rationale/Explanation of issue: > > I could not find a place in the draft where it covers the possiblity > that the Identity response differs from the identity that is > authenticated by the EAP method. > > Requested change: > > Perhaps the following should be added to the security considerations > section: > > "It is possible for the identity in the identity response to be > different from the identity authenticated by the EAP method. This may > be intentional in the case of identity privacy. An EAP method SHOULD > use the authenticated identity when making access control decisions. A > method MAY allow the use of the identity in the identity response if it > is an authnorized alias for the authenticated identity." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jrv@umich.edu Tue Jul 8 23:12:08 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 08 Jul 2003 18:12:08 -0400 Subject: [eap] Issue 156: Terminology reorganization In-Reply-To: References: Message-ID: <2446258.1057687928@localhost> I think this is good. --On Monday, July 7, 2003 8:09 PM -0700 Bernard Aboba wrote: > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: July 6, 2003 > Reference: > Document: EAP-04 > Comment type: T > Priority: S > Section: 1.2, 1.3, 7.2.1 > Rationale/Explanation of issue: > > The security claims terminology is best left with the rest of the security > claims section 7.2. > Also, the definitions of Man-in-the-Middle resistance and Cryptographic > binding appear to overlap. > > Change Section 1.2 to the following: > > "1.2 Terminology > > This document frequently uses the following terms: > > authenticator > The end of the link initiating EAP authentication. The > term Authenticator is used in [IEEE-802.1X], and > authenticator has the same meaning in this document. > > peer > The end of the link that responds to the authenticator. > In [IEEE-802.1X], this end is known as the Supplicant. > > backend authentication server > A backend authentication server is an entity that provides > an authentication service to an authenticator. When used, > this server typically executes EAP methods for the > authenticator. This terminology is also used in > [IEEE-802.1X]. > > Displayable Message > This is interpreted to be a human readable string of > characters. The message encoding MUST follow the UTF-8 > transformation format [RFC2279]. > > EAP server > The entity that terminates the EAP authentication method > with the peer. In the case where no backend authentication > server is used, the EAP server is part of the authenticator. > In the case where the authenticator operates in > pass-through mode, the EAP server is located on the backend > authentication server. > > Silently Discard > This means the implementation discards the packet without > further processing. The implementation SHOULD provide the > capability of logging the event, including the contents of > the silently discarded packet, and SHOULD record the event > in a statistics counter. > > Successful authentication > In the context of this document, "successful > authentication" is an exchange of EAP messages, as a result > of which the authenticator decides to allow access by the > peer, and the peer decides to use this access. The > authenticator's decision typically involves both > authentication and authorization aspects; the peer may > successfully authenticate to the authenticator but access > may be denied by the authenticator due to policy reasons. > > Message Integrity Check (MIC) > A keyed hash function used for authentication and integrity > protection of data. This is usually called a Message > Authentication Code (MAC), but IEEE 802 specifications (and > this document) use the acronym MIC to avoid confusion with > Medium Access Control. > > Cryptographic separation > Two keys (x and y) are "cryptographically separate" if an > adversary that knows all messages exchanged in the protocol > cannot compute x from y or y from x without "breaking" some > cryptographic assumption. In particular, this definition > allows that the adversary has the knowledge of all nonces > sent in cleartext as well as all predictable counter values > used in the protocol. Breaking a cryptographic assumption > would typically require inverting a one-way function or > predicting the outcome of a cryptographic pseudo-random > number generator without knowledge of the secret state. 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. > > Master Session Key (MSK) > Keying material that is derived between the EAP peer and > server and exported by the EAP method. The MSK is used > in the derivation of Transient Session Keys (TSKs) for > the ciphersuite negotiated between > the EAP peer and authenticator. Where a backend > authentication server is present, acting as an EAP server, > it will typically transport the MSK to the authenticator, > so that in this case, the MSK is available to the peer, > authenticator and authentication server. > > Extended Master Session Key (EMSK) > Additional keying material derived between the EAP client > and server that is exported by the EAP method. Unlike the > MSK, the EMSK is known only to the EAP peer and EAP server > and is not provided to a third party. The EMSK is reserved > for future uses that are not defined yet. For example, it > could be used to derive additional keying material for > purposes such as fast handoff, cryptographic binding, etc." > > Delete Section 1.3. > > Add Section 7.2.1: > > "7.2.1 Security claims terminology for EAP methods > > These terms are used to described the security properties of EAP > methods: > > Mutual authentication > This refers to an EAP method in which, within an > interlocked exchange, the authenticator authenticates the > peer and the peer authenticates the authenticator. Two > independent one-way methods, running in opposite directions > do not provide mutual authentication as defined here. > > Integrity protection > This refers to providing data origin authentication and > protection against unauthorized modification of information > for EAP packets (including EAP Requests and Responses). > When making this claim, a method specification MUST > describe the EAP packets and fields within the EAP packet > that are protected. > > Replay protection > This refers to protection against replay of an EAP method > or its messages, including method-specific success and > failure indications. > > Confidentiality > This refers to encryption of EAP messages, including EAP > Requests and Responses, and method-specific success and > failure indications. A method making this claim MUST > support identity protection (see Section 7.3). > > Key derivation > This refers to the ability of the EAP method to derive > exportable keying material such as the Master Session Key > (MSK), and Extended Master Session Key (EMSK). The MSK is > used only for further key derivation, not directly for > protection of the EAP conversation or subsequent data. Use > of the EMSK is reserved. > > Key strength > If the effective key strength is N bits, the best currently > known methods to recover the key (with non-negligible > probability) require an effort comparable to 2^N operations > of a typical block cipher. > > Dictionary attack protection > Where password authentication is used, users are > notoriously prone to select poor passwords. A method may > be said to be dictionary attack resistant if, when there is > a weak password in the secret, the method does not allow > an attack more efficient than brute force. > > Fast reconnect > The ability, in the case where a security association has > been previously established, to create a new or refreshed > security association in a smaller number of round-trips. > > Cryptographic binding > The demonstration of the EAP peer to the EAP server that a > single entity has acted as the EAP peer for all methods > executed within a tunnel method. Binding MAY also > imply that the EAP server demonstrates to the peer that a > single entity has acted as the EAP server for all methods > executed within a tunnel method. If executed > correctly, binding serves to mitigate man-in-the-middle > vulnerabilities. > > Acknowledged result indications > The ability within a method for the authenticator to indicate > to the peer whether it has successfully authenticated to it, > and for the peer to acknowledge receipt of that indication as > well as indicating to the authenticator whether it has > successfully authenticated to the peer. Since EAP Success > and Failure packets are neither acknowledged nor integrity > protected, this claim requires implementation of a > method-specific result exchange that is authenticated, > integrity and replay protected on a per-packet basis." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jrv@umich.edu Tue Jul 8 23:01:19 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 08 Jul 2003 18:01:19 -0400 Subject: [eap] EAP-04 comments In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222BB@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A61222BB@esebe023.ntc.nokia.com> Message-ID: <2407325.1057687279@localhost> --On Sunday, July 6, 2003 5:20 PM +0300 Pasi.Eronen@nokia.com wrote: comments in line > EAP-04 comments > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: July 6, 2003 > Reference: > Document: RFC2284bis > Comment type: E/T > Priority: 1 > Section: various > Rationale/Explanation of issue: > > Overall, the draft looks fine, and it seems that we're finally > close to getting it finished! In hindsight, there are a couple > of things that might have been clearer if organized differently, > but it probably doesn't make sense to do such changes at this > point. > I agree it is good, and thanks to all who worked on it, especially Nick and Pasi. > --- > > (Section 2) "Since EAP is a peer-to-peer protocol, an > independent and simultaneous authentication may take place in > the reverse direction. Both peers may act as authenticators > and authenticatees at the same time. For a discussion of > security issues in peer-to-peer operation, see Section 7.7. > > I think this does not apply to all lower layers. Perhaps it > should be rephrased to something like "Some lower layers for > carrying EAP, such as PPP, may support peer-to-peer operation, > in which an indendent and...". > I agree the meaning of this is not clear. I think it would be good to talk about the signalling between layers rather than what different layers do. This could be an interesting discussion. > --- > > (Section 4.2) "Success or Failure packets MUST NOT be sent by > an EAP authenticator prior to completion of the final round > of a given method. A peer EAP implementation receiving a > Success or Failure packet prior to completion of the method > in progress MUST silently discard it." > > I think there are several EAP methods where the number of rounds > varies (so the phrase "the final round" is not well defined), > depending on many issues, including whether the method is > going to succeed or not. > > Perhaps this would better take that into account? > > "Success and Failure packets MUST NOT be sent by an EAP > authenticator if the specification of the given method does not > allow the method to finish at that point. A peer EAP > implementation receiving a Success or Failure packet where > sending one is not allowed MUST silently discard it." > I like this > --- > > (Section 4.2) "If the peer attempts to authenticate to the > authenticator and fails to do so, the authenticator MUST send a > Failure packet and MUST NOT grant access by sending a Success > packet." > > I know that this was beaten to death already :-) But since > we have not defined what "failing to authenticate to the > authenticator" means, does this actually impose any > requirements for EAP implementations? > > (The problem is that "failing to authenticate" could be thought > as "not successfully authenticating"; but according to the > definition of "successful authentication" in Section 1.2, the > above requirement does not make much sense.) > > Perhaps this would capture the intent? > > "If the peer attempts to authenticate to the authenticator using > a method that provides key derivation, the authenticator SHOULD > NOT grant access by sending a Success packet if the key > derivation has failed for some reason." > I think key derivation is a method and RADIUS (or other) issue, not really EAP. Here I think Policy can come in play, and trying to avoid all policy gets counter productive at some point. Again an interesting discussion. > --- > > (Section 5.7) "EAP Types from 0 through 255 are semantically > identical whether they appear as single octet EAP Types or as > Vendor-Types when Vendor-Id is zero." > > (Section 5.7) "An implementation that supports the Expanded > attribute MUST treat EAP Types that are less than 256 > equivalently whether they appear as a single octet or as the > 32-bit Vendor-Type within a Expanded Type where Vendor-Id is > 0." and > > Otherwise fine, but Expanded Nak packets have a different format > than Legacy Nak packets, so they are not treated exactly > identically. > > Perhaps we should add something like "There is one exception to > this rule: Expanded Nak and Legacy Nak packets share the same > code, but must be treated differently because they have a > different format." (an alternative would be to change the > code of Expanded Naks to something else, but probably > this is easier?) > I like this > --- > > Appendix B: Two significant changes to RFC 2284 are not > mentioned: mutual authentication and key derivation > (RFC 2284 did not even mention either of them). > probably good to mention, but again these are method issues not "EAP" issues. Use of some policy makes these work. Perhaps that is where they should be mentioned. > ---- > > References: There are newer versions of RFC2869bis and SASLPREP > drafts available (Ok, RFC editor will probably handle these...) > > ---- > > References: PIC is most likely dead and superseded by IKEv2, so > maybe we should remove references to PIC and add a pointer to > IKEv2? > I like this idea very much. John > ---- > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jrv@umich.edu Tue Jul 8 23:16:38 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 08 Jul 2003 18:16:38 -0400 Subject: [eap] EAP-04 lower layer indications In-Reply-To: References: <052E0C61B69C3741AFA5FE88ACC775A61222BC@esebe023.ntc.nokia.com> <3F0A6F73.2000909@piuha.net> Message-ID: <2462434.1057688198@localhost> --On Tuesday, July 8, 2003 5:29 AM -0700 Bernard Aboba wrote: > > Ok, I see. There doesn't appear to be a security > > difference, since Success can most likely be spoofed > > at least as easily as lower-layer success indication. > > But there has been a lot of discussion around lower > > layer indications in the past, so I'm inclined to > > trust 2284bis more on this. Bernard, do you remember > > why 2284bis ignores lower-layer success indications? > > When we did the implementation survey, we found that nobody implemented > this part of the specification. Was there a reason we chose one rather than the other? I don't remember. John > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jsalowey@cisco.com Tue Jul 8 23:34:57 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Tue, 8 Jul 2003 15:34:57 -0700 Subject: [eap] Issue: Identity Response mismatch In-Reply-To: <3F09AEE0.8040109@piuha.net> Message-ID: <003a01c345a1$294031f0$0200000a@amer.cisco.com> After thinking about this more I think it may be more appropriate to specify the exact behavior in the mechanism specifications. Perhaps we should note that for some mechanisms the authenticated identity and the identity in the identity response may not be the same. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Monday, July 07, 2003 10:33 AM > To: Joseph Salowey > Cc: 'EAP mailing List' > Subject: Re: [eap] Issue: Identity Response mismatch > > > Joseph Salowey wrote: > > > [Joe] Yes, It should probably say > > > > If a the identity in the identity response is an authorized > alias of > > the authenticated identity the alias MAY use this identity > for making > > access control decisions. > > Hmm... if its an alias, there does not appear to be much of > a difference, or? > > > Alternatively we could just say that the authenticated > identity always > > takes precedence over the identity in the identity response > when they > > differ. > > This sounds good. > > --Jari > From aboba@internaut.com Tue Jul 8 23:18:27 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Jul 2003 15:18:27 -0700 (PDT) Subject: [eap] EAP-04 lower layer indications In-Reply-To: <2462434.1057688198@localhost> References: <052E0C61B69C3741AFA5FE88ACC775A61222BC@esebe023.ntc.nokia.com> <3F0A6F73.2000909@piuha.net> <2462434.1057688198@localhost> Message-ID: > Was there a reason we chose one rather than the other? I don't remember. > John I don't remember either. In fact, I don't even remember making a decision. I'll probably forget this email too, so please bring this subject up at IETF 57 so we can figure it out there :) From henrik@levkowetz.com Tue Jul 8 23:45:32 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Wed, 9 Jul 2003 00:45:32 +0200 Subject: [eap] EAP-04 lower layer indications In-Reply-To: <3F0833BD.8060403@piuha.net> References: <052E0C61B69C3741AFA5FE88ACC775A608BB68@esebe023.ntc.nokia.com> <3F0833BD.8060403@piuha.net> Message-ID: <20030709004532.7fdc8edc.henrik@levkowetz.com> Jari Arkko wrote in reply to Pasi Eronen: > > A second issue: Earlier versions of the draft also mentioned > > lower-layer failure indications (e.g. "Lower layer failure > > indications provided to EAP by the lower layer MUST be processed > > and will cause an EAP exchange in progress to be aborted." in > > -03 version). This seems to be missing from -04, and I think > > the old text still applies? > > Can't remember what happened to this. This was changed as part of the edits of issue 131. Issue 131: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20131 Diff: http://www.levkowetz.com/pub/ietf/drafts/eap/draft-ietf-eap-rfc2284bis-04.d-from-4.b.diff.html Henrik From jari.arkko@piuha.net Wed Jul 9 00:11:54 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 09 Jul 2003 02:11:54 +0300 Subject: [eap] Issue: Identity Response mismatch In-Reply-To: <003a01c345a1$294031f0$0200000a@amer.cisco.com> References: <003a01c345a1$294031f0$0200000a@amer.cisco.com> Message-ID: <3F0B4FBA.4060107@piuha.net> Joseph Salowey wrote: > After thinking about this more I think it may be more appropriate to > specify the exact behavior in the mechanism specifications. Perhaps we > should note that for some mechanisms the authenticated identity and the > identity in the identity response may not be the same. Ok. --Jari From aboba@internaut.com Wed Jul 9 05:44:57 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Jul 2003 21:44:57 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 153: EAP OTP Replay Protection Message-ID: The text of Issue 153 is enclosed below. The proposed fix is as follows: In Section 5.5, change: " Replay protection: No" To: " Replay protection: Yes" ------------------------------------------------------------------------- Issue 153: EAP OTP Replay Protection Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: July 6, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-July/001417.html Document: EAP-04 Comment type: T Priority: S Section: 5.5 Rationale/Explanation of issue: Does EAP-OTP provide replay protection? 2284bis-04 says no, but it seems that it should. From aboba@internaut.com Wed Jul 9 05:51:51 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Jul 2003 21:51:51 -0700 (PDT) Subject: [eap] Proposed Resolution of Issue 145: Terminology: MITM Resistance Message-ID: The text of Issue 145 is included below. The proposed fix is to delete the current definition of MITM and utilize the term "Cryptographic binding" instead. This is proposed in Issue 156, so that if this is acceptable, then Issue 145can be resolved as a duplicate of Issue 156 (Reject). -------------------------------------------------------------------------- Issue 145: Terminology: Man-in-the-Middle Resistance Submitter name: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: June 18, 2003 Reference: Document: EAP-04 Comment type: T Priority: S Section: Terminology and throughout Rationale/Explanation of issue: "Man-in-the-Middle resistance". I don't really feel comfortable with the use of this term. From what I know, Man-in-the-middle attacks have a well established existing meaning, while here we are defining something related which applies only to sequences or tunnelled methods. If a reader skips lightly over the definitions, and doesn't catch the limited meaning of this term, the classification of MitM resistance: N/A for the basic authentication methods will not make sense, or in the worst case be misleading. If I understand the issues correctly, all the basic authentication methods (MD5, OTP, GTC) *are* vulnerable to classic MitM attacks - but our MitM resistance term describes something else, and I'd therefore prefer to call it something else. [Jari Arkko] I agree. MITM is too general term. "Compound authentication Man-in-the-Middle attack resistance"? Shorter name would be useful. From aboba@internaut.com Wed Jul 9 05:54:48 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Jul 2003 21:54:48 -0700 (PDT) Subject: [eap] Proposed resolution of Issue 148: Sequences Message-ID: The text of Issue 148 is enclosed below. The proposed resolution is to Accept the proposed changes. Any objections? --------------------------------------------------------------------- Issue 148: Sequences Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: June 16, 2003 Reference: Document: EAP-04 Comment type: T Priority: 2 Section: 7.4 paragraph 2 Rationale/Explanation of issue: Security issues addressed in this section seem to address only what happens in an unprotected EAP method. Section 2.1 indicates that within a tunnel sequences may be used. Requested change: add the word "untunnelled" between the words "permit" and "sequences". [Jari Arkko]: Agree From aboba@internaut.com Wed Jul 9 05:58:45 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Jul 2003 21:58:45 -0700 (PDT) Subject: [eap] Proposed Resolution of Issue 143: EAP-04 Editorial Nits Message-ID: The text of Issue 143 is enclosed below. The proposed resolution is to accept the proposed changes. Any objections? ---------------------------------------------------------------------------- Issue 143: EAP-04 Editorial Nits Submitter name: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: June 18, 2003 Reference: Document: EAP-04 Comment type: E Priority: 1 Section: Various Rationale/Explanation of issue: Section 1.3: "Acknowledged result indications The ability of the authenticator to provide the peer with an indication of whether the peer has successfully authenticated to it, and for the peer to acknowledge receipt, as well as providing an indication of whether the authenticator has successfully authenticated to the peer. Since EAP Success and Failure packets are neither acknowledged nor integrity protected, this claim requires implementation of a method-specific result exchange that is authenticated, integrity and replay protected on a per-packet basis." s/authenticated, /authenticated and/ Section 2.2: "EAP packets with codes of Success or Failure do not include a Type, and therefore are not delivered to an EAP method. Success and Failure are discussed in Section 4.2." s/and therefore/and/ (- I don't see an immediate logic, so I'd rather just state the rule here.) Section 3.1: "[1] Unreliable transport. In EAP, the authenticator retransmits Requests that have not yet received Responses, so that EAP does not assume that lower layers are reliable. Since EAP defines it own retransmission behavior, when run over a reliable lower layer, it is possible (though undesirable) for retransmission to occur both in the lower layer and the EAP layer." Awkward. Rewrite last part to: "Since EAP defines its own retransmission behavior, it is possible (though undesirable) for retransmission to occur both in the lower layer and the EAP layer when EAP is run over a reliable lower layer." ... "After EAP authentication is complete, the peer will typically transmit data to the network via the authenticator. In order to provide assurance that the peer transmitting data is the same entity that successfully completed EAP authentication, the lower layer needs to bind per-packet integrity, authentication and replay protection to the original EAP authentication, using keys derived during EAP authentication. Alternatively, the lower layer needs to be physically secure. Otherwise it is possible for subsequent data traffic to be hijacked, or replayed." s/hijacked,/hijacked/ ... "In IEEE 802 media, key activation also typically occurs after completion of EAP authentication. Therefore an initial EAP exchange typically cannot be protected by lower layer ciphersuite, although an EAP re-authentication or pre-authentication exchange can be protected." s/by lower layer/by the lower layer/ Section 4.1: "Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests. The contents of the data field are dependent on the Request Type. The peer MUST send a Response packet in reply to a valid Request packet. Responses MUST only be sent in reply to a valid Request and never retransmitted on a timer." s/The contents of the data field are/The content of the data field is/ Section 5.3.2: "Length >=40" Is my math off today? I count the length to 20 octets or more, not 40 or more. s/40/20/ ... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (Nak) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 (OTP) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 20 (MIT) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ s/Length/Length=28/ An Expanded Nak Response indicating a no desired alternative would appear as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (Nak) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (No alternative) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ s/Length/Length=20/ Section 5.7: "The Expanded Type is also used to expand the global Method Type space beyond the original 255 values. A Vendor-Id of 0 maps the original 255 possible Types onto a namespace of 2^32-1 possible Types, allowing for virtually unlimited expansion. (Type 0 is only used in a Nak Response, to indicate no acceptable alternative)" s/namespace/number space/ s/, allowing for virtually unlimited expansion// (the last part of the sentence, while true, is maybe too much elaborating the obvious?) Section 7.4 Man-in-the-middle attacks: "As noted in Section 2.1, EAP does not permit sequences of authentication methods. Were a sequence of EAP authentication methods to be permitted, the peer might not have proof that a single entity has acted as the authenticator for all EAP methods within the sequence. For example, an authenticator might terminate one EAP method, then forward the next method in the sequence to another party without the peer's knowledge or consent. Similarly, the authenticator might not have proof that a single entity has acted as the peer for all EAP methods within the sequence. This enables an attack by a rogue EAP authenticator tunneling EAP to ..." s/This enables/Tunnelling EAP within another protocol enables/ Section 7.6: "Where EAP runs over lower layers which are not physically secure, in order to protect against dictionary attacks, an authentication algorithm resistant to dictionary attack (as defined in Section 7.2) SHOULD be used." Rewrite as: "In order to protect against dictionary attacks, an authentication algorithm resistant to dictionary attack (as defined in Section 7.2) SHOULD be used where EAP runs over lower layers which are not physically secure." "If an authentication algorithm is used that is known to be vulnerable to dictionary attack, then the conversation may be tunneled within a protected channel, in order to provide additional protection. However, as noted in Section 7.4, EAP tunneling may result in a man-in-the-middle vulnerability, and therefore dictionary attack resistant methods are preferred." s/channel,/channel/ Section Appendix B. Changes from RFC 2284: Add: "o In sections 5, 5.1 and 5.2, requirements has been added that fields with displayable messages should contain UTF-8 encoded ISO 10646 characters." From aboba@internaut.com Wed Jul 9 06:05:30 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Jul 2003 22:05:30 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 144: Use of a Zero in a Nak Message-ID: The text of Issue 144 is enclosed below. The proposed resolution is as follows: In Section 5.3.1, change: "Type zero (0) is used to indicate that the sender has no viable alternatives." To: "Type zero (0) is used to indicate that the sender has no viable alternatives, and therefore the authenticator SHOULD NOT send another Request after receiving a Nak Response containing a zero value." ---------------------------------------------------------------------- Issue 144: Use of Zero in a Nak Submitter name: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: June 18, 2003 Reference: Document: EAP-04 Comment type: T Priority: 1 Section: 5.3 Rationale/Explanation of issue: There is various text on the use of zero in a NAK, for instance, Section 5.3.1 says: "The legacy Nak Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains one or more authentication Types desired by the Peer. Type zero (0) is used to indicate that the sender has no viable alternatives." Reading this, I wondered: When is the value zero used in a NAK? When the peer doesn't want to *disclose* alternatives, or when there are none left? May the authenticator continue probing after receiving a zero NAK? [Jari Arkko] The text seems to say that the peer has no alternatives. Still, I wonder if zero is used for other purposes as well. Has it been used for implementations that can't tell what methods might be appropriate? If not, I'd rather say SHOULD NOT probe after receiving a zero NAK. From aboba@internaut.com Wed Jul 9 06:13:42 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 8 Jul 2003 22:13:42 -0700 (PDT) Subject: [eap] Proposed Resolution to Issue 147: Initial Key Activation Message-ID: The text of Issue 147 is enclosed below. The proposed fix is as follows: In Section 3.1, change: " In IEEE 802 media, key activation also typically occurs after completion of EAP authentication. Therefore an initial EAP exchange typically cannot be protected by lower layer ciphersuite, although an EAP re-authentication or pre-authentication exchange can be protected." To: " In IEEE 802 media, initial key activation also typically occurs after completion of EAP authentication. Therefore an initial EAP exchange typically cannot be protected by lower layer ciphersuite, although an EAP re-authentication or pre-authentication exchange can be protected." ----------------------------------------------------------------------------- Issue 147: Initial Key Activation Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: June 16, 2003 Reference: Document: EAP-04 Comment type: T Priority: 2 Section: 3.1 paragraph 5 Rationale/Explanation of issue: 802 key activation may be prolonged by authentication as well as initiated. The text here applies to initial authentication. Requested change: insert the word ", initial" between "media" and "key activation" [Jari Arkko] I think this is right. From henrik@levkowetz.com Wed Jul 9 08:39:39 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Wed, 9 Jul 2003 09:39:39 +0200 Subject: [eap] Proposed Resolution of Issue 145: Terminology: MITM Resistance In-Reply-To: References: Message-ID: <20030709093939.3e243e7f.henrik@levkowetz.com> On Tue, 8 Jul 2003 21:51:51 -0700 (PDT), Bernard Aboba wrote: > The text of Issue 145 is included below. The proposed fix is to delete the > current definition of MITM and utilize the term "Cryptographic binding" > instead. This is proposed in Issue 156, so that if this is acceptable, > then Issue 145can be resolved as a duplicate of Issue 156 (Reject). The resolution to 145 proposed in 156 looks good to me, I'm for it. Henrik > > -------------------------------------------------------------------------- > Issue 145: Terminology: Man-in-the-Middle Resistance > Submitter name: Henrik Levkowetz > Submitter email address: henrik@levkowetz.com > Date first submitted: June 18, 2003 > Reference: > Document: EAP-04 > Comment type: T > Priority: S > Section: Terminology and throughout > Rationale/Explanation of issue: > > "Man-in-the-Middle resistance". > > I don't really feel comfortable with the use of this term. From what I > know, Man-in-the-middle attacks have a well established existing > meaning, while here we are defining something related which applies only > to sequences or tunnelled methods. If a reader skips lightly over the > definitions, and doesn't catch the limited meaning of this term, the > classification of MitM resistance: N/A for the basic authentication > methods will not make sense, or in the worst case be misleading. > > If I understand the issues correctly, all the basic authentication > methods (MD5, OTP, GTC) *are* vulnerable to classic MitM attacks - > but our MitM resistance term describes something else, and I'd > therefore prefer to call it something else. > [Jari Arkko] > I agree. MITM is too general term. > > "Compound authentication Man-in-the-Middle attack resistance"? > > Shorter name would be useful. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Wed Jul 9 08:52:04 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 9 Jul 2003 00:52:04 -0700 (PDT) Subject: [eap] EAP key naming Message-ID: At IETF 56, during the AAA WG meeting, Russ Housley the Security Area Director, provided a roadmap for EAP and AAA keying, by listing the characteristics that a proposed solution MUST satisfy. This message summarizes current thinking on how the EAP Keying Framework satisfies those requirements. As noted below, we have a better handle on some of the Issues than others; in particular Issue 12 needs more work. The most current version of the EAP Keying Framework is available at: http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-07.txt Requirements for EAP Key Management A proposed solution MUST: 1. Be an algorithm independent protocol 2. For interoperability, select at least one suite of algorithms that MUST be implemented 3. Establish strong, fresh session keys 4. Maintain algorithm independence 5. Include replay detection mechanism 6. Authenticate all parties 7. Maintain confidentiality of authenticator 8. NO plaintext passwords 9. Perform client and NAS authorization 10. Maintain confidentiality of session keys 11. Confirm selection of best ciphersuite 12. Uniquely name session keys 13. Compromise of a single NAS cannot compromise any other part of the system, including session keys and long-term keys 14. Bind key to appropriate context The EAP Keying Framework document (http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-07.txt) has made progress on most of these items. For example, EAP supports multiple methods (algorithms), as well as ciphersuites and ensures that any method can work with any ciphersuite and media. So #1, and #4 are covered. RFC 2284bis includes a mandatory to implement algorithm, albeit one which does not generate keys or do mutual authentication. At IETF 56, EAP WG received a request from IEEE 802.11 to change the mandatory-to-implement algorithm to one which does derive keys. However, as discussed by Erik Nordmark, while it might make sense for EAP usage communities to define their own mandatory algorithms, it is likely that those communities would resist having a single mandatory-to-implement algorithm imposed on all of them. So Issue #2, appears to be the responsibility of individual EAP usage communities. Issue #3 can be handled by requiring that EAP methods generating keys provide freshness -- such as by including an exchange of nonces. It also makes sense to require that secure association protocols running after EAP (e.g. IEEE 802.11i 4-way handshake) provide freshness, so that TSKs are fresh, even if the MSK and EMSK are not. So overall, I think we've got a good handle on this one. Issue #5 relates to replay protection in EAP, in the secure association protocol as well as in AAA. RADIUS over IPsec with replay protection is now a SHOULD in RFC 2869bis; this is already supported in Diameter. So I think that AAA is covered. We will add a requirement for replay protection in the Secure Association protocol, as well as a requirement that key generating EAP methods support replay protection. If we do this, I think we are covered on Issue #5. Issue #6 requires mutual auth in all three legs -- EAP, AAA, and the secure association protocol. AAA protocols already do mutual authentication -- both RADIUS & Diameter handle this. So I think we need a requirement that EAP key deriving methods and secure association protocols support mutual authentication, and Issue #6 is handled. I believe that Issue #7 relates to AAA protocol confidentiality. RADIUS over IPsec and Diameter both support confidentiality. If this also encompasses Identity Protection this can be satisfied by methods which provide for a protected Identity exchange (e.g. EAP-Request/Identity is optional). EAP does not support plaintext passwords (no PAP). So Issue #8 is handled. On Issue #9, we have added language in both Diameter NASREQ and RFC 2869bis relating to NAS authorization. Client authorization is an intrinsic part of EAP, not just authentication. So I think we have some progress here as well. One Issue #10, we have discussed the use of Redirects in Diameter to ensure that the MSK is only available to the AAA Server, NAS and EAP peer. That is, through redirect the NAS and AAA Server can exchange keys directly. RADIUS does not support redirect, so that for Issue #10 to be satisfied it is necessary to have NAS devices talk directly to RADIUS servers. Since neither EAP nor AAA are involved in secure capabilities negotiation, Issue #11 is really a problem for the secure association protocol. Currently IEEE 802.11i does securely negotiate the ciphersuite, but unfortunately does not securely confirm the other capabilities -- creating a potential security vulnerability. But the basic requirements of Issue #11 appear to be met. Issue #13 appears to be met if the MSKs generated at each NAS are cryptographically independent of each other, OR if the EMSK is used to generate keys in such a way that a NAS with knowledge of its own key cannot guess the key of another NAS. Since the EMSK is never transported, a simple PRF construction can achieve this. So I think we can satisfy Issue #13. The remaining Issues are #12 and #14. These are a number of issues here and we will discuss these at IETF 57. Issue #12 is really about how to name the EAP SA and the associated key hierarchy (MSK, EMSK, etc.). Fundamentally, an EAP SA is negotiated between the EAP peer and EAP server, and is "named" by the individual EAP method. For example, EAP-TLS, PEAP, and EAP-TTLS use the TLS "Session-Id" to name the keys. So it would appear to me that the 3-tuple of the (Peer NAI, Server Name, EAP method key name) is sufficient to name the EAP SA. Note that this scheme assumes that it is possible for an EAP peer and EAP server to have more than one valid EAP SA at a time. One issue that arises here is that EAP, unlike IKE Phase 1, does not have an SA deletion operation. So once an EAP SA is formed, it stays around until its lifetime expires. However, there is no way for the peer and EAP server to negotiate exactly what that lifetime is, particularly since a NAS may decide to reboot or flush key state at any time. One interesting question is whether the NAS name enters into the EAP SA naming scheme. It is possible for the EAP client to learn the NAS name (e.g. through the EAP-Request/Identity), and while Issue #11 would be violated if the same MSK were to be reused on multiple NASes, I don't think that it is a good idea to tie an EAP SA to a particular NAS. If NAS devices provide failover, it well might be possible for an EAP SA to migrate from one NAS to a backup during a fault. Tying the EAP SA name to the NAS name would prevent such a migration from occuring. Since a secure association (Phase 2 SA) is derived from keying material established by EAP authentication (Phase 1 SA), to "bind" the two phases together, it is necessary for the secure association protocol to name the EAP keying material that it is based on. The EAP SA name may not be sufficiently granular for this -- since it doesn't distinguish between the MSK (or portions thereof, such as the PMK) and the EMSK. So some additional qualifiers may be needed to make this specific enough. One question is how all parties (EAP peer, AAA server, NAS) come to know the EAP SA name. The peer and EAP server come to know it via the EAP method conversation -- they exchange identities and the method provides a session identifier. One must then presume that the EAP server exports the EAP SA name along with the MSK and EMSK and binds this together within the AAA protocol packet sent to the NAS. That way the NAS not only gets the keys, but also the name associated with those keys, for use in the secure association protocol. The secure association protocol is where the binding of the EAP SA keying material to the "context" (e.g. Phase 2 secure association) occurs. This is how Issue #14 is addressed. While EAP is responsible for mutual auth, replay protection, and derivation of key material, including freshness and EAP SA key naming, the secure association protocol (Phase 2) does the heavy lifting. It is responsible for: a. Secure capabilities negotiation (including ciphersuites) b. Mutual authentication c. Transient session key derivation (including freshness) d. Secure association naming e. Binding of the EAP SA to the secure association (Phase 2 SA). This occurs by utilizing the EAP SA name within the Phase 2 exchange. f. TSK activation, deletion, and rekey. Since the secure association protocol handles secure capabilities negotiation there is no need for EAP or AAA to handle this. By supporing mutual auth, the secure association protocol confirms possession of the named EAP SA keying material on both sides. Note that if there is any vaguness in the naming of the EAP SA keying material, then this step might fail by mistake. By including freshness (e.g. a two-way nonce exchange) in the secure association protocol, the TSKs can be guaranteed to be fresh even if for some reason the EAP MSK and EMSK are not. So we have "belt and suspenders" protection against TSK reuse. We need to name the secure association (Phase 2) so that the derived TSKs can be bound to subsequent data traffic. In IPsec this is handled via the SPI and destination address; 802.10 had the SAID; 802.11 only has the keyID which is not a very good substitute. To make it clear which EAP SA is used to derive the Phase 2 SA, it becomes possible to bind the EAP SA to the "context" (e.g. secure associations) with which it will be used. Secure association protocols need to support both activation and deletion of transient session keys. Deletion is useful so that a NAS that needs to purge key state can securely notify peers that it is deleting their key state. This is not strictly required (the NAS could just age out the keys), but it does make it more possible for a highly secure EAP peer to refuse to act on insecure deletion messages. In effect, the IEEE 802.11 Disassociate and Deauthenticate messages are deletion messages, but they are not secured in IEEE 802.11i. TSK activation is equivalent to activating the Phase 2 (secure association), and as part of that process, an EAP peer is formally "joined" to the network -- data traffic can now be sent since keys are synchronized. That's why we call Phase 2 a secure association protocol -- it really is about creating a secure association, both in the IPsec (SA) sense (e.g. security parameters negotiated and bound), as well as in the IEEE 802.11 "Association" sense (peer negotiates capabilities and joins the network). From dpj@theworld.com Wed Jul 9 15:40:38 2003 From: dpj@theworld.com (David Jablon) Date: Wed, 09 Jul 2003 10:40:38 -0400 Subject: [eap] Issue 156: Terminology reorganization In-Reply-To: <2446258.1057687928@localhost> References: Message-ID: <5.1.0.14.0.20030709085420.00a2bec0@pop.theworld.com> I see some potential confusion in the proposed EAP-04 definition for "Dictionary attack protection". On Monday, July 7, 2003 8:09 PM -0700 Bernard Aboba wrote: >>"7.2.1 Security claims terminology for EAP methods ... >> Dictionary attack protection >> Where password authentication is used, users are >> notoriously prone to select poor passwords. A method may >> be said to be dictionary attack resistant if, when there is >> a weak password in the secret, the method does not allow >> an attack more efficient than brute force. Here's a suggested rewording. "Where password authentication is used, passwords are commonly selected from a set that is small, as compared to a set of N-bit keys. A method may be said to be dictionary attack resistant if, when it uses a password as a secret, the method does not allow an offline attack that has a work factor based on the number of passwords in an attacker's dictionary." The changes are intended to address the following concerns: -- Since dictionary attack may be regarded as a form of brute force attack, a reader might wonder how dictionary attack could ever be more efficient than brute force attack. A significant distinction can be drawn if "dictionary" more clearly refers to a work factor based on the set of password guesses rather than key size. -- Underqualified use of derogatory terms like "poor" and "weak" leads to a confusingly circular definition. The value of using a specific password depends, in part, on the characteristics of the method, one of which is being defined here. -- Users are not alone in being responsible for selecting passwords from a small set. Systems, including their developers and administrators, are "notoriously prone" to encouraging such practice too. -- There was no mention of whether the attack is offline or online. From aboba@internaut.com Wed Jul 9 16:01:02 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 9 Jul 2003 08:01:02 -0700 (PDT) Subject: [eap] Issue 156: Terminology reorganization In-Reply-To: <3F0C336F.4080206@lucent.com> References: <5.1.0.14.0.20030709085420.00a2bec0@pop.theworld.com> <3F0C336F.4080206@lucent.com> Message-ID: > Here's a suggested rewording. > > "Where password authentication is used, commonly selected > passwords are weak because they are selected from a > small set (as compared to a set of N-bit keys). > A method may be said to be dictionary attack resistant if, > when it uses a password as a secret, the method does not allow > an offline attack that has a work factor based on > the number of passwords in an attacker's dictionary." OK. I've revised the proposed fix in Issue 156. From uri@lucent.com Wed Jul 9 16:23:27 2003 From: uri@lucent.com (Uri Blumenthal) Date: Wed, 09 Jul 2003 11:23:27 -0400 Subject: [eap] Issue 156: Terminology reorganization References: <5.1.0.14.0.20030709085420.00a2bec0@pop.theworld.com> Message-ID: <3F0C336F.4080206@lucent.com> On 7/9/2003 10:40 AM, David Jablon wrote: > I see some potential confusion in the proposed EAP-04 definition > for "Dictionary attack protection". Based on David's proposed edits, I'd suggest the following: >>>"7.2.1 Security claims terminology for EAP methods >> > ... > >>> Dictionary attack protection >>> Where password authentication is used, users are >>> notoriously prone to select poor passwords. A method may >>> be said to be dictionary attack resistant if, when there is >>> a weak password in the secret, the method does not allow >>> an attack more efficient than brute force. Here's a suggested rewording. "Where password authentication is used, commonly selected passwords are weak because they are selected from a small set (as compared to a set of N-bit keys). A method may be said to be dictionary attack resistant if, when it uses a password as a secret, the method does not allow an offline attack that has a work factor based on the number of passwords in an attacker's dictionary." Thanks! Regards, Uri. From dpj@theworld.com Wed Jul 9 17:49:47 2003 From: dpj@theworld.com (David Jablon) Date: Wed, 09 Jul 2003 12:49:47 -0400 Subject: [eap] Issue 156: Terminology reorganization In-Reply-To: References: <3F0C336F.4080206@lucent.com> <5.1.0.14.0.20030709085420.00a2bec0@pop.theworld.com> <3F0C336F.4080206@lucent.com> Message-ID: <5.1.0.14.0.20030709123647.00a03910@pop.theworld.com> At 08:01 AM 7/9/03 -0700, Bernard Aboba wrote: >> Here's a suggested rewording. >> >> "Where password authentication is used, commonly selected >> passwords are weak because they are selected from a >> small set (as compared to a set of N-bit keys). >> A method may be said to be dictionary attack resistant if, >> when it uses a password as a secret, the method does not allow >> an offline attack that has a work factor based on >> the number of passwords in an attacker's dictionary." > >OK. I've revised the proposed fix in Issue 156. The first sentence in the above version has a problem similar to the original version. It does not make sense to characterize password quality outside the context of a specific method. How about: "Where password authentication is used, passwords are commonly selected from a small set (as compared to a set of N-bit keys), which raises the concern of dictionary attack. ..." -- David From jesse.walker@intel.com Wed Jul 9 21:52:24 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Wed, 9 Jul 2003 13:52:24 -0700 Subject: [eap] EAP key naming Message-ID: Bernard, This is a good summary. Thanks. I have a few comments below. > A proposed solution MUST: >=20 > 1. Be an algorithm independent protocol > 2. For interoperability, select at least one suite of=20 > algorithms that MUST > be implemented > 3. Establish strong, fresh session keys > 4. Maintain algorithm independence > 5. Include replay detection mechanism > 6. Authenticate all parties > 7. Maintain confidentiality of authenticator > 8. NO plaintext passwords > 9. Perform client and NAS authorization > 10. Maintain confidentiality of session keys > 11. Confirm selection of best ciphersuite > 12. Uniquely name session keys > 13. Compromise of a single NAS cannot compromise any other part of the > system, including session keys and long-term keys > 14. Bind key to appropriate context There is (at least) one missing requirement: a key deriving EAP method = must, if it completes successfully, leave the EAP Server and EAP Peer = with synchronized session state. At the very least the EAP Server and = EAP Peer must believe that the same NAIs have been authenticated, must = share the same session key, and must have the same name for the session = key. This does not follow necessarily from the other requirements. It may be worth devoting a few words to the effect that the requirements = are system requirements. Some of them apply to EAP methods, some to the = backend protocols like RADIUS or DIAMETER, some to system design, etc. = It is not clear to me that any of them apply to EAP per se. > RFC 2284bis includes a mandatory to implement algorithm,=20 > albeit one which > does not generate keys or do mutual authentication. At IETF=20 > 56, EAP WG > received a request from IEEE 802.11 to change the=20 > mandatory-to-implement > algorithm to one which does derive keys. However, as=20 > discussed by Erik > Nordmark, while it might make sense for EAP usage communities=20 > to define > their own mandatory algorithms, it is likely that those=20 > communities would > resist having a single mandatory-to-implement algorithm=20 > imposed on all of > them. So Issue #2, appears to be the responsibility of individual EAP > usage communities. This misconstrues IEEE 802.11's request. The observation is that the = base EAP document requires IEEE 802.11 systems with 802.1X Supplicants = to implement MD5 Challenge, when in fact it should expressly prohibit = their use in this context. Mandating its implementation without = prohibiting its use in certain contexts demands that users decide for = themselves in many contexts, and many users are not equipped to make = this decision. The mandatory-to-implement method either should be safe in all = environments, or else there should be no mandatory-to-implement method. = The line of reasoning you make above suggests you would support removing = MD5 Challenge as mandatory-to-implement. That would probably be an = acceptable resolution. However, the status quo is not acceptable. > Issue #3 can be handled by requiring that EAP methods generating keys > provide freshness -- such as by including an exchange of=20 > nonces. It also > makes sense to require that secure association protocols=20 > running after EAP > (e.g. IEEE 802.11i 4-way handshake) provide freshness, so=20 > that TSKs are > fresh, even if the MSK and EMSK are not. So overall, I think=20 > we've got a > good handle on this one. We should make random nonce exchange an explicit requirement for key = deriving EAP methods, so that everyone knows what we are really talking = about. We can require at least 128 bit random nonces, with 256 bits = being a should--random objects are subject to birthday attack. See more = below regarding issue #12. > Issue #5 relates to replay protection in EAP, in the secure=20 > association > protocol as well as in AAA. RADIUS over IPsec with replay=20 > protection is > now a SHOULD in RFC 2869bis; this is already supported in=20 > Diameter. So I > think that AAA is covered. We will add a requirement for=20 > replay protection > in the Secure Association protocol, as well as a requirement that key > generating EAP methods support replay protection. If we do=20 > this, I think > we are covered on Issue #5. This is not an EAP issue; it relates to the back-end. The key draft can = dismiss it as out of scope and point to some other document, e.g., a AAA = keying document. Even though it is out of scope, it is worth pointing out that the = assumption that IPsec can be used for replay protection is not valid for = key management protocols; key distribution isn't merely distributing so = many bits of data, which is the assumption behind IPsec. The use of = IPsec for replay in the key management function assumes that the entire = system at each end of the link has been evaluated to be secure. Such an = assumption would deny a great many markets to almost all servers made by = your company. > Issue #6 requires mutual auth in all three legs -- EAP, AAA, and the > secure association protocol. AAA protocols already do mutual > authentication -- both RADIUS & Diameter handle this. So I=20 > think we need > a requirement that EAP key deriving methods and secure association > protocols support mutual authentication, and Issue #6 is handled. Again, this is not an EAP issue, and I think it fair if the EAP key = naming draft punts on it. > I believe that Issue #7 relates to AAA protocol=20 > confidentiality. RADIUS > over IPsec and Diameter both support confidentiality. If this also > encompasses Identity Protection this can be satisfied by methods which > provide for a protected Identity exchange (e.g.=20 > EAP-Request/Identity is > optional). Issue #7 bears more discussion; I'm confused by it, any way. I don't = know what issue #7 is trying to say, but data confidentiality is a = radically different thing from "Identity Protection." Either the = discussion is wrong or the issue is not stated correctly, because the = two do not coincide. > One Issue #10, we have discussed the use of Redirects in Diameter to > ensure that the MSK is only available to the AAA Server, NAS=20 > and EAP peer. > That is, through redirect the NAS and AAA Server can exchange keys > directly. RADIUS does not support redirect, so that for Issue=20 > #10 to be > satisfied it is necessary to have NAS devices talk directly to RADIUS > servers. This one is outside the scope of EAP and should be dealt with in AAA or = RADIUS and the like. The EAP document should say this is a requirement = on the overall system design, not EAP or the EAP method. Having said that, if I understand what you wrote, it misses the point. = The point of issue #10 is that if the EAP Server generates a key for the = NAS, then the key is compromised from the EAP Peer's perspective if the = EAP Server shares the key with ***ANY*** party besides the particular = NAS the EAP Peer is dealing with. Indeed, we could reword Issue #10 to = "EAP Server will honor the EAP Peer's trust assumption, by not = (intentionally) revealing the MSK to any party but the Peer's NAS." When = symmetric keys are used to secure the channel between the EAP Server and = the NAS, this says that the EAP Server and NAS share a security = association directly between them for the express purpose of key = distribution. This is a requirement that most vendors and operators = hate, but it is what #10 is trying to say. People want public/private = key semantics at the cost of symmetric keys. No one has suggested how to = make such a design work. > So it would appear to me that the 3-tuple of the (Peer NAI,=20 > Server Name, > EAP method key name) is sufficient to name the EAP SA. Note that this > scheme assumes that it is possible for an EAP peer and EAP=20 > server to have > more than one valid EAP SA at a time. This almost but not quite right. Such a naming scheme does not = distinguish names across sessions between the same EAP Peer and EAP = Server. Think of the case where there is key roll-over due to = reauthentication. Does the name refer to the old or to the new key? It = refers to both, the scheme does not unambiguously identify the key, and = the parties will not be able to tell which to use (they will not = necessarily share the same notion of which one is current). There does = not seem to be any choice but to (a) mandate that key-deriving EAP = methods exchange nonces and (b) the nonces are part of the name. >=20 > One interesting question is whether the NAS name enters into=20 > the EAP SA > naming scheme. It is possible for the EAP client to learn the NAS name > (e.g. through the EAP-Request/Identity), and while Issue #11 would be > violated if the same MSK were to be reused on multiple NASes, I don't > think that it is a good idea to tie an EAP SA to a particular=20 > NAS. If NAS > devices provide failover, it well might be possible for an=20 > EAP SA to migrate from > one NAS to a backup during a fault. Tying the EAP SA name to=20 > the NAS name > would prevent such a migration from occuring. The NAS name is not germane. The relationship is between the EAP Peer = and the EAP Server. > Since a secure association (Phase 2 SA) is derived from=20 > keying material > established by EAP authentication (Phase 1 SA), to "bind" the=20 > two phases > together, it is necessary for the secure association protocol=20 > to name the > EAP keying material that it is based on. The EAP SA name may not be > sufficiently granular for this -- since it doesn't=20 > distinguish between the > MSK (or portions thereof, such as the PMK) and the EMSK. So some > additional qualifiers may be needed to make this specific enough. Since the MSK and ESMK are wholly compromised from the EAP Peer's = perspective if either is ever shared with more than one NAS, we know = that such key sharing cannot be allowed, so it is safe to use the NAS = name as part of the MSK name; indeed, it would be rather odd if this = were not the case. This would make the key name something like . If we are unlucky this can consume 832 = octets, assuming 32 octet nonces and full size NAIs. This may be too = heavy-weight to use in many of the contexts (e.g., roaming) that = motivate its definition. It would therefore be useful to define a = standard identifier similar to an X.509 certificate's fingerprint, e.g., KeyID =3D SHA1(Peer NAI | Server NAI | Peer Nonce | Server Nonce |NAS = NAI) This, of course, is not the question you were asking. To distinguish the = MSK from the EMSK, add an arbitrary label to the end of the tuple. > The secure association protocol is where the binding of the=20 > EAP SA keying > material to the "context" (e.g. Phase 2 secure association)=20 > occurs. This I'm not sure I follow this. There are at least two levels of security = association, at least implicitly, and it is not clear which issue #14 = refers to. If the "binding" language refers to the key derived by the EAP method, = then the binding is the collection of synchronized state. It is within = EAP's purview to establish requirements for this, as I indicated above = by pointing out that we missed the synchronization requirement. If issue #14 is refering to key distribution, then your discussion is = reasonable, but the whole thing falls outside of EAP's scope, as it = relates to the key distribution mechanism. I think? > is how Issue #14 is addressed. While EAP is responsible for=20 > mutual auth, > replay protection, and derivation of key material, including freshness > and EAP SA key naming, the secure association protocol (Phase=20 > 2) does the heavy lifting. > It is responsible for: >=20 > a. Secure capabilities negotiation (including ciphersuites) I think the EAP method should only be made accountable for negotiating = the cipher suites it uses itself? > We need to name the secure association (Phase 2) so that the=20 > derived TSKs > can be bound to subsequent data traffic. In IPsec this is=20 > handled via the > SPI and destination address; 802.10 had the SAID; 802.11 only has the > keyID which is not a very good substitute. No. 802.11i uses the MAC addresses of the STA and the AP to identify the = key. The (pairwise) key is always bound to WEP KeyID 0 in 802.11i, so = the KeyID does not tell us anything except that it is a pairwise key. In the case of 802.11, what is important is the right key gets delivered = to the right AP, and never to any other party whatsoever. Vis-a-vis the = binding discussion, this translates into a requirement for the EAP = Server to be able assert that the key is bound to the pair , because that is the only meaningful key = identifier at the MAC layer. This is what the Bindings field is for in = the Archie Response and Confirm messages. An alternate approach might be = to modify EAP directly to convey this information instead, since your = standard run-of-the-mill EAP method does not have this exchange built in = like Archie does. For other cases besides 802.11, mileage will vary; how to do the binding = will be protocol specific. That's my two cents, for what it is worth. -- Jesse From jsalowey@cisco.com Thu Jul 10 05:50:47 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 9 Jul 2003 21:50:47 -0700 Subject: [eap] EAP key naming In-Reply-To: Message-ID: <00e901c3469e$d4c39370$0200000a@amer.cisco.com> > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Wednesday, July 09, 2003 12:52 AM > To: eap@frascone.com > Subject: [eap] EAP key naming > > > At IETF 56, during the AAA WG meeting, Russ Housley the > Security Area Director, provided a roadmap for EAP and AAA > keying, by listing the characteristics that a proposed > solution MUST satisfy. > > This message summarizes current thinking on how the EAP > Keying Framework satisfies those requirements. As noted > below, we have a better handle on some of the Issues than > others; in particular Issue 12 needs more work. The most > current version of the EAP Keying Framework is available at: > > http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-probl > em-07.txt > > Requirements for EAP Key Management > > A proposed solution MUST: > > 1. Be an algorithm independent protocol > 2. For interoperability, select at least one suite of > algorithms that MUST > be implemented > 3. Establish strong, fresh session keys > 4. Maintain algorithm independence > 5. Include replay detection mechanism > 6. Authenticate all parties > 7. Maintain confidentiality of authenticator [Joe] I am confused by requirement 7, what does this mean? > 8. NO plaintext passwords > 9. Perform client and NAS authorization > 10. Maintain confidentiality of session keys > 11. Confirm selection of best ciphersuite > 12. Uniquely name session keys > 13. Compromise of a single NAS cannot compromise any other part of the > system, including session keys and long-term keys > 14. Bind key to appropriate context > > RFC 2284bis includes a mandatory to implement algorithm, > albeit one which does not generate keys or do mutual > authentication. At IETF 56, EAP WG received a request from > IEEE 802.11 to change the mandatory-to-implement algorithm to > one which does derive keys. However, as discussed by Erik > Nordmark, while it might make sense for EAP usage communities > to define their own mandatory algorithms, it is likely that > those communities would resist having a single > mandatory-to-implement algorithm imposed on all of them. So > Issue #2, appears to be the responsibility of individual EAP > usage communities. > [Joe] I'm not sure that this is sufficient to meet the requirement. EAP-MD5 does not cut it, there should be at least one generally applicable method that is widely implemented. Perhaps EAP-TLS would be good. > > I believe that Issue #7 relates to AAA protocol > confidentiality. RADIUS over IPsec and Diameter both support > confidentiality. If this also encompasses Identity > Protection this can be satisfied by methods which provide for > a protected Identity exchange (e.g. EAP-Request/Identity is optional). > [Joe] I have no idea what #7 is referring to. > Since neither EAP nor AAA are involved in secure capabilities > negotiation, Issue #11 is really a problem for the secure > association protocol. Currently IEEE 802.11i does securely > negotiate the ciphersuite, but unfortunately does not > securely confirm the other capabilities -- creating a > potential security vulnerability. But the basic requirements > of Issue #11 appear to be met. > [Joe] Individual EAP methods are responsible for securing the negotiation of ciphersuites they use such as TLS. In addition the same would be true for AAA protocols. > Issue #12 is really about how to name the EAP SA and the > associated key hierarchy (MSK, EMSK, etc.). Fundamentally, > an EAP SA is negotiated between the EAP peer and EAP server, > and is "named" by the individual EAP method. For example, > EAP-TLS, PEAP, and EAP-TTLS use the TLS "Session-Id" to name the keys. > [Joe] If I remember correctly the TLS session-ID lasts through session resumption so it is associated with more than one MSK. The client and server randoms can be used to identify an MSK. > So it would appear to me that the 3-tuple of the (Peer NAI, > Server Name, EAP method key name) is sufficient to name the > EAP SA. Note that this scheme assumes that it is possible for > an EAP peer and EAP server to have more than one valid EAP SA > at a time. > [Joe]If the EAP method key name includes information such as nonces that uniquely identify an EAP exchange it would seem that this is sufficient. How are these quantities derived? Is the Peer NAI from the identity request? What happens if there is no identity request? Then the name is method specific. This should be part of the EAP method key name. Where does the server name come from? This name is also EAP method specific and should be part of the EAP method key name. Perhaps the EAP method should export x number of bytes as the key name. The name would be derived from quantities know to the EAP method such as nonces identities etc. The method would explain how this dervation is done. For existing methods they keying draft could suggest something. > One issue that arises here is that EAP, unlike IKE Phase 1, > does not have an SA deletion operation. So once an EAP SA is > formed, it stays around until its lifetime expires. However, > there is no way for the peer and EAP server to negotiate > exactly what that lifetime is, particularly since a NAS may > decide to reboot or flush key state at any time. > > One interesting question is whether the NAS name enters into > the EAP SA naming scheme. It is possible for the EAP client > to learn the NAS name (e.g. through the > EAP-Request/Identity), and while Issue #11 would be violated > if the same MSK were to be reused on multiple NASes, I don't > think that it is a good idea to tie an EAP SA to a particular > NAS. If NAS devices provide failover, it well might be > possible for an EAP SA to migrate from one NAS to a backup > during a fault. Tying the EAP SA name to the NAS name would > prevent such a migration from occuring. > [Joe] An EAP SA is between the EAP-PEER and EAP-Server. The base SA is not NAS dependent. Since MSK should be transmitted to one and only one NAS perhaps the MSK can involve the NAS name, but the EMSK should not. > Since a secure association (Phase 2 SA) is derived from > keying material established by EAP authentication (Phase 1 > SA), to "bind" the two phases together, it is necessary for > the secure association protocol to name the EAP keying > material that it is based on. The EAP SA name may not be > sufficiently granular for this -- since it doesn't > distinguish between the MSK (or portions thereof, such as the > PMK) and the EMSK. So some additional qualifiers may be > needed to make this specific enough. > [Joe] I think you will need more granularity than this, the EMSK should not be used by itself additional application specific master keys (AMSK) should be derived from it. In any case the EAP SA name should be the base name. This can be extended in a standard to refer to keys derived from this base SA (MSK,EMSK,AMSK). This naming is also necessary when keys must be requested from the EAP server. > One question is how all parties (EAP peer, AAA server, NAS) > come to know the EAP SA name. The peer and EAP server come to > know it via the EAP method conversation -- they exchange > identities and the method provides a session identifier. One > must then presume that the EAP server exports the EAP SA name > along with the MSK and EMSK and binds this together within > the AAA protocol packet sent to the NAS. That way the NAS > not only gets the keys, but also the name associated with > those keys, for use in the secure association protocol. > > The secure association protocol is where the binding of the > EAP SA keying material to the "context" (e.g. Phase 2 secure > association) occurs. This is how Issue #14 is addressed. > While EAP is responsible for mutual auth, replay protection, > and derivation of key material, including freshness and EAP > SA key naming, the secure association protocol (Phase 2) does > the heavy lifting. It is responsible for: > > a. Secure capabilities negotiation (including ciphersuites) > b. Mutual authentication > c. Transient session key derivation (including freshness) > d. Secure association naming > e. Binding of the EAP SA to the secure association (Phase 2 > SA). This occurs by utilizing the EAP SA name within the > Phase 2 exchange. f. TSK activation, deletion, and rekey. > > Since the secure association protocol handles secure > capabilities negotiation there is no need for EAP or AAA to > handle this. By supporing mutual auth, the secure association > protocol confirms possession of the named EAP SA keying > material on both sides. Note that if there is any vaguness > in the naming of the EAP SA keying material, then this step > might fail by mistake. By including freshness (e.g. a > two-way nonce exchange) in the secure association protocol, > the TSKs can be guaranteed to be fresh even if for some > reason the EAP MSK and EMSK are not. So we have "belt and > suspenders" protection against TSK reuse. > [Joe] It should be a requirement that the EAP MSK and EMSK are fresh every time an EAP method is run. > We need to name the secure association (Phase 2) so that the > derived TSKs can be bound to subsequent data traffic. In > IPsec this is handled via the SPI and destination address; > 802.10 had the SAID; 802.11 only has the keyID which is not a > very good substitute. > > To make it clear which EAP SA is used to derive the Phase 2 > SA, it becomes possible to bind the EAP SA to the "context" > (e.g. secure associations) with which it will be used. > > Secure association protocols need to support both activation > and deletion of transient session keys. Deletion is useful > so that a NAS that needs to purge key state can securely > notify peers that it is deleting their key state. This is not > strictly required (the NAS could just age out the keys), but > it does make it more possible for a highly secure EAP peer to > refuse to act on insecure deletion messages. In effect, the > IEEE 802.11 Disassociate and Deauthenticate messages are > deletion messages, but they are not secured in IEEE 802.11i. > > TSK activation is equivalent to activating the Phase 2 > (secure association), and as part of that process, an EAP > peer is formally "joined" to the network -- data traffic can > now be sent since keys are synchronized. That's why we call > Phase 2 a secure association protocol -- it really is about > creating a secure association, both in the IPsec (SA) sense > (e.g. security parameters negotiated and bound), as well as > in the IEEE 802.11 "Association" sense (peer negotiates > capabilities and joins the network). > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Thu Jul 10 05:31:43 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 9 Jul 2003 21:31:43 -0700 (PDT) Subject: [eap] EAP key naming In-Reply-To: References: Message-ID: > There is (at least) one missing requirement: a key deriving EAP method must, > if it completes successfully, leave the EAP Server and EAP Peer with > synchronized session state. At the very least the EAP Server and EAP > Peer must believe that the same NAIs have been authenticated, must share the > same session key, and must have the same name for the session key. This > does not follow necessarily from the other requirements. That seems reasonable, although I am not clear that synchronization can be maintained beyond the initial exchange, since either the peer or EAP server can age out key state and there is no EAP "delete" message to ensure synchronization. > It may be worth devoting a few words to the effect that the requirements > are system requirements. Some of them apply to EAP methods, some to the > backend protocols like RADIUS or DIAMETER, some to system design, etc. > It is not clear to me that any of them apply to EAP per se. Yes. We'll need to make it clear what requirements apply to what protocols. There are some grey areas that may be worth discussing. > This misconstrues IEEE 802.11's request. The observation is that the base EAP > document requires IEEE 802.11 systems with 802.1X Supplicants to > implement MD5 Challenge, when in fact it should expressly prohibit their > use in this context. Mandating its implementation without prohibiting > its use in certain contexts demands that users decide for themselves in many > contexts, and many users are not equipped to make this decision. It seems reasonable to indicate that MD5 Challenge is inappropriate in some circumstances. Would you care to file an issue indicating what text you'd like to add? > The mandatory-to-implement method either should be safe in all environments, > or else there should be no mandatory-to-implement method. The line of > reasoning you make above suggests you would support removing MD5 > Challenge as mandatory-to-implement. That would probably be an > acceptable resolution. However, the status quo is not acceptable. I don't think that having no mandatory-to-implement method is an acceptable alternative. As noted in Erik Nordmark's presentation at IETF 56, we can add text to RFC 2284bis indicating the minimum requirements for various circumstances, and the security claims language should make it clear what methods meet those requirements (no methods defined in RFC 2284bis are appropriate for use with 802.11). There are lots of examples of mandatory-to-implement methods in IETF protocols that can be used inappropriately or may not work in all circumstances. So I'm not sure that it's necessary (or even possible) to create a single method that would be suitable for all potential uses of EAP. That's part of the problem -- getting agreement on what the mandatory method should be would probably require a formal beauty contest that could consume up to a year of the WG's time. As Erik suggested at IETF 56, our time would probably be better spent reviewing and publishing a variety of methods, and making sure their security properties were well understood and letting the market decide. > We should make random nonce exchange an explicit requirement for > key deriving EAP methods, so that everyone knows what we are really > talking about. We can require at least 128 bit random nonces, with 256 > bits being a should--random objects are subject to birthday attack. See > more below regarding issue #12. Yes, I think this makes sense. > This is not an EAP issue; it relates to the back-end. The key draft can > dismiss it as out of scope and point to some other document, e.g., a AAA > keying document. I wasn't clear what replay threat was to being referred to, so I assumed that it was all potential threats. It's not unreasonable to require replay protection in all three "legs", though. > Even though it is out of scope, it is worth pointing out that the > assumption that IPsec can be used for replay protection is not valid for > key management protocols; key distribution isn't merely distributing so > many bits of data, which is the assumption behind IPsec. The use of > IPsec for replay in the key management function assumes that the > entire system at each end of the link has been evaluated to be secure. It's true that IPsec typically only provides "machine authentication" and that IPsec SAs, once created, can be used by any process on the machine. So one has to depend on facilities of the operating system in order to make sure that keying material isn't leaked within the machine. Application layer confidentiality is better in that respect. It's worth noting that Diameter supports TLS so that an application-specific SA can be used to protect the keys. > > Issue #6 requires mutual auth in all three legs -- EAP, AAA, and the > > secure association protocol. AAA protocols already do mutual > > authentication -- both RADIUS & Diameter handle this. So I > > think we need > > a requirement that EAP key deriving methods and secure association > > protocols support mutual authentication, and Issue #6 is handled. Russ's requirements apply to the system as a whole, so it probably makes sense to describe the requirements for each piece. I don't think we can punt on this particular issue. > Issue #7 bears more discussion; I'm confused by it, any way. > I don't know what issue #7 is trying to say, but data confidentiality is > a radically different thing from "Identity Protection." Either the > discussion is wrong or the issue is not stated correctly, because the > two do not coincide. I'm obviously confused by Issue #7 too. I just took a guess at what it *might* mean. > This one is outside the scope of EAP and should be dealt with in AAA or > RADIUS and the like. The EAP document should say this is a requirement > on the overall system design, not EAP or the EAP method. Sure, that's reasonable. > Having said that, if I understand what you wrote, it misses the point. > The point of issue #10 is that if the EAP Server generates a key for the > NAS, then the key is compromised from the EAP Peer's perspective if the > EAP Server shares the key with ***ANY*** party besides the particular > NAS the EAP Peer is dealing with. Indeed, we could reword Issue #10 > to "EAP Server will honor the EAP Peer's trust assumption, by not > (intentionally) revealing the MSK to any party but the Peer's NAS." When > symmetric keys are used to secure the channel between the EAP Server and > the NAS, this says that the EAP Server and NAS share a security > association directly between them for the express purpose of key > distribution. This is a requirement that most vendors and operators > hate, but it is what #10 is trying to say. People want public/private > key semantics at the cost of symmetric keys. No one has suggested how to > make such a design work. Yes, I think this is what #10 is trying to say. > This almost but not quite right. Such a naming scheme does not > distinguish names across sessions between the same EAP Peer and EAP > Server. Think of the case where there is key roll-over due to > reauthentication. Does the name refer to the old or to the new key? It > refers to both, the scheme does not unambiguously identify the key, and > the parties will not be able to tell which to use (they will not > necessarily share the same notion of which one is current). There does > not seem to be any choice but to (a) mandate that key-deriving EAP > methods exchange nonces and (b) the nonces are part of the name. I agree that the EAP peer and EAP server names do not uniquely define the EAP SA. However, EAP method such as EAP-TLS often have a session-id or its equivalent. Certainly a nonce exchange can help, and since we are going to require that, perhaps your suggestions a) and b) are a way to guarantee that the requirements are satisfied. > The NAS name is not germane. The relationship is between the EAP Peer > and the EAP Server. Yes, I agree. > Since the MSK and ESMK are wholly compromised from the EAP Peer's perspective > if either is ever shared with more than one NAS, we know that such key > sharing cannot be allowed The EMSK is compromised if it is known by *any* NAS. The MSK is compromised if it is shared by more than one NAS. > so it is safe to use the NAS name as part of > the MSK name; indeed, it would be rather odd if this were not the case. So you're saying that the MSK name is different from the EAP SA name? Is this solely because the EAP SA is not "bound" to a NAS while the MSK is bound? What about the EMSK? This is not "bound" to a particular NAS -- so is it's name the same as the EAP SA name? What about quantities derived from the EMSK? How do we name those? > This would make the key name something like So the first 4 quantities are the EAP SA name, and the MSK name is the EAP SA name + the NAS NAI. Is it fair to say that the EMSK name is the same as the EAP SA name? > If we are unlucky this can consume 832 octets, assuming 32 octet nonces > and full size NAIs. This may be too heavy-weight to use in many of the > contexts (e.g., roaming) that motivate its definition. It would > therefore be useful to define a standard identifier similar to an X.509 > certificate's fingerprint, e.g., > > KeyID = SHA1(Peer NAI | Server NAI | Peer Nonce | Server Nonce |NAS NAI) OK -- at least the KeyID is a hash of the MSK name, and not a hash of the key itself as was originally proposed (shudder). > This, of course, is not the question you were asking. Actually, it is part of the question. > To distinguish the MSK from the EMSK, add an arbitrary label to the end > of the tuple. I think you mean "to distinguish the EAP SA from the EMSK" add an arbitrary label on the end of the EAP SA. I think that this would work as long as that label is guaranteed not to conflict with the NAS NAI. Since the EMSK is not bound to a NAS, I don't think that the NAS NAI can be part of its name. From jsalowey@cisco.com Thu Jul 10 06:09:44 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 9 Jul 2003 22:09:44 -0700 Subject: [eap] EAP key naming In-Reply-To: Message-ID: <00ea01c346a1$7a6b57c0$0200000a@amer.cisco.com> > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Walker, Jesse > Sent: Wednesday, July 09, 2003 1:52 PM > To: Bernard Aboba; eap@frascone.com > Subject: RE: [eap] EAP key naming > > > Bernard, > > This is a good summary. Thanks. I have a few comments below. > > > Since a secure association (Phase 2 SA) is derived from > > keying material > > established by EAP authentication (Phase 1 SA), to "bind" the > > two phases > > together, it is necessary for the secure association protocol > > to name the > > EAP keying material that it is based on. The EAP SA name may not be > > sufficiently granular for this -- since it doesn't > > distinguish between the > > MSK (or portions thereof, such as the PMK) and the EMSK. So some > > additional qualifiers may be needed to make this specific enough. > > Since the MSK and ESMK are wholly compromised from the EAP > Peer's perspective if either is ever shared with more than > one NAS, we know that such key sharing cannot be allowed, so > it is safe to use the NAS name as part of the MSK name; > indeed, it would be rather odd if this were not the case. > [Joe] You are absolutely correct for the MSK, but the EMSK should not be shared with anyone. It should only be know to the EAP-Peer and EAP-Server. Keys derived from the EMSK may be shared with other parties. The NAS name should not be used in a base identifier for the EAP Keys. Perhaps the base identifier can be augmented with the NAS name to identify the MSK. > This would make the key name something like NAI, Peer Nonce, Server Nonce, NAS NAI>. If we are unlucky > this can consume 832 octets, assuming 32 octet nonces and > full size NAIs. This may be too heavy-weight to use in many > of the contexts (e.g., roaming) that motivate its definition. > It would therefore be useful to define a standard identifier > similar to an X.509 certificate's fingerprint, e.g., > > KeyID = SHA1(Peer NAI | Server NAI | Peer Nonce | > Server Nonce |NAS NAI) > [Joe] EAP method should be required define a base SA id that is derived in a method specific way from its nonces, identities, etc. This id is fixed 16 bytes (perhaps more is better, but I'm feeling stingy and the moment). A hashing scheme like you propose above is an excellent way to get the appropriate length. This name can be decorated to refer to keys associated with this base SA such as the MSK and application master session keys (AMSK) derived from the EMSK. This decoration can involve the NAS NAI. > This, of course, is not the question you were asking. To > distinguish the MSK from the EMSK, add an arbitrary label to > the end of the tuple. > > > > > The secure association protocol is where the binding of the > > EAP SA keying > > material to the "context" (e.g. Phase 2 secure association) > > occurs. This > > I'm not sure I follow this. There are at least two levels of > security association, at least implicitly, and it is not > clear which issue #14 refers to. > > If the "binding" language refers to the key derived by the > EAP method, then the binding is the collection of > synchronized state. It is within EAP's purview to establish > requirements for this, as I indicated above by pointing out > that we missed the synchronization requirement. > > If issue #14 is refering to key distribution, then your > discussion is reasonable, but the whole thing falls outside > of EAP's scope, as it relates to the key distribution > mechanism. I think? > > > is how Issue #14 is addressed. While EAP is responsible for > > mutual auth, > > replay protection, and derivation of key material, > including freshness > > and EAP SA key naming, the secure association protocol (Phase > > 2) does the heavy lifting. > > It is responsible for: > > > > a. Secure capabilities negotiation (including ciphersuites) > > I think the EAP method should only be made accountable for > negotiating the cipher suites it uses itself? > > > We need to name the secure association (Phase 2) so that the > > derived TSKs > > can be bound to subsequent data traffic. In IPsec this is > > handled via the > > SPI and destination address; 802.10 had the SAID; 802.11 > only has the > > keyID which is not a very good substitute. > > No. 802.11i uses the MAC addresses of the STA and the AP to > identify the key. The (pairwise) key is always bound to WEP > KeyID 0 in 802.11i, so the KeyID does not tell us anything > except that it is a pairwise key. > > In the case of 802.11, what is important is the right key > gets delivered to the right AP, and never to any other party > whatsoever. Vis-a-vis the binding discussion, this translates > into a requirement for the EAP Server to be able assert that > the key is bound to the pair Address>, because that is the only meaningful key identifier > at the MAC layer. This is what the Bindings field is for in > the Archie Response and Confirm messages. An alternate > approach might be to modify EAP directly to convey this > information instead, since your standard run-of-the-mill EAP > method does not have this exchange built in like Archie does. > > For other cases besides 802.11, mileage will vary; how to do > the binding will be protocol specific. > > > > That's my two cents, for what it is worth. > > -- Jesse > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Thu Jul 10 05:48:00 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 9 Jul 2003 21:48:00 -0700 (PDT) Subject: [eap] EAP key naming In-Reply-To: <00e901c3469e$d4c39370$0200000a@amer.cisco.com> References: <00e901c3469e$d4c39370$0200000a@amer.cisco.com> Message-ID: > [Joe] I am confused by requirement 7, what does this mean? I obvious don't know either :) Will probably need to ask Russ for an explanation. > [Joe] I'm not sure that this is sufficient to meet the requirement. > EAP-MD5 does not cut it, there should be at least one generally > applicable method that is widely implemented. Perhaps EAP-TLS would be > good. EAP-TLS may not work in all circumstances -- it requires certificates, is client/server, not peer-to-peer, takes quite a few round-trips. I suspect that quite a few communities would object to one or more of these properties. > [Joe] I have no idea what #7 is referring to. I took a guess, based on what was in Russ's slides. If that's not the right guess, we can try another one :) > [Joe] Individual EAP methods are responsible for securing the > negotiation of ciphersuites they use such as TLS. In addition the same > would be true for AAA protocols. Sure. We should probably state that explicitly. > [Joe] If I remember correctly the TLS session-ID lasts through session > resumption so it is associated with more than one MSK. The client and > server randoms can be used to identify an MSK. Yes, the session-Id really names the MK, and the client and server randoms identify the MSK. > [Joe]If the EAP method key name includes information such as nonces that > uniquely identify an EAP exchange it would seem that this is sufficient. Yes, I think that makes sense. > Is the Peer NAI from the identity request? What happens if there is no > identity request? > Then the name is method specific. This should be part of the EAP method > key name. I think we get ourselves into trouble if the EAP SA name depends on an unsecured exchange such as EAP Identity Request/Response. So it makes sense to me to require some kind of method-specific protected name exchange and to base the EAP SA name on that. > Where does the server name come from? This name is also EAP method > specific and should be part of the EAP method key name. Yes, I think so. It certainly can't be expected to be provided in the EAP-Request/Identity -- that is created by the NAS in most cases. > Perhaps the EAP method should export x number of bytes as the key name. > The name would be derived from quantities know to the EAP method such as > nonces identities etc. The method would explain how this dervation is > done. For existing methods they keying draft could suggest something. Yes. That has the advantage of allowing the EAP SA and MSK names to be sent across to the NAS by the AAA server. > [Joe] An EAP SA is between the EAP-PEER and EAP-Server. The base SA is > not NAS dependent. Since MSK should be transmitted to one and only one > NAS perhaps the MSK can involve the NAS name, but the EMSK should not. Yes, I agree with this. > [Joe] I think you will need more granularity than this, the EMSK should > not be used by itself additional application specific master keys (AMSK) > should be derived from it. In any case the EAP SA name should be the > base name. This can be extended in a standard to refer to keys derived > from this base SA (MSK,EMSK,AMSK). This naming is also necessary when > keys must be requested from the EAP server. Yes. The question is how to name the derivatives of the EMSK. > [Joe] It should be a requirement that the EAP MSK and EMSK are fresh > every time an EAP method is run. Yes. From jsalowey@cisco.com Thu Jul 10 07:05:14 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 9 Jul 2003 23:05:14 -0700 Subject: [eap] EAP key naming In-Reply-To: Message-ID: <00eb01c346a9$3b58ab70$0200000a@amer.cisco.com> > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Walker, Jesse > Sent: Wednesday, July 09, 2003 1:52 PM > To: Bernard Aboba; eap@frascone.com > Subject: RE: [eap] EAP key naming > > > In the case of 802.11, what is important is the right key > gets delivered to the right AP, and never to any other party > whatsoever. Vis-a-vis the binding discussion, this translates > into a requirement for the EAP Server to be able assert that > the key is bound to the pair Address>, because that is the only meaningful key identifier > at the MAC layer. This is what the Bindings field is for in > the Archie Response and Confirm messages. An alternate > approach might be to modify EAP directly to convey this > information instead, since your standard run-of-the-mill EAP > method does not have this exchange built in like Archie does. > > For other cases besides 802.11, mileage will vary; how to do > the binding will be protocol specific. > [Joe] This is one area where chaining of additional messages after an EAP method can be really useful. Instead of having each method having to define channel bindings and other bindings for n different environments you define an EAP extension (for example an EAP-TLV message with a Channel-Binding TLV) to carry this information. It is authenticated and possibly encrypted using keys derived from the EMSK (shared only between the EAP-Peer and EAP-Server). This extension could be used with any key deriving EAP method. These two drafts provide some of the framework for this: http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-02.tx t What is left is to define a channel-binding-TLV (I think Jose may have one in his binding problem draft, if not I have one sketched out based on archie) and resolve the chaining issue (this requires a little bit more work). > > > That's my two cents, for what it is worth. > > -- Jesse > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From hannes.tschofenig@siemens.com Thu Jul 10 10:53:43 2003 From: hannes.tschofenig@siemens.com (Tschofenig Hannes) Date: Thu, 10 Jul 2003 11:53:43 +0200 Subject: [eap] EAP key naming Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFFCC@mchp905a.mch.sbs.de> hi joe, if i look at russ's requirements and then look at your draft http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-02.txt then i am not sure whether the requirements are met / are applicable. in your proposal you use the keying material based on the previous eap exchange to create this protected tlv. if you compare this with the handshake done in the ieee 802.11i 4 way handshake then there is some difference there. for me that is just fine. currently the requirements address the following protocols: a) the eap exchange itself b) the aaa protocol and c) the protocol which uses the keying material afterwards ((this is probably the most difficult part which was not discussed in detail so far) the characteristics of the protocol where eap should provide keying material will most likely vary a lot. hence i would like to better understand the requirements with regard to the different protocols that utilize the eap derived keying material. some examples of protocols which use the eap established keying material are: - ieee wlan environment - your protected tlv or the http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt - pana - pana dhcp bootstrapping - pana ipsec establishment, - etc. ciao hannes btw, i never fully understood your draft http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt. a number of protocol in the past proposed (e.g. pana, sip, some proposals in the 3gpp, pic, etc. etc.) to use eap to create keying material. since these protocols vary (as argued above) in their characteristics and requirements it will not work to define a single key derivation function for all of them. an example: jesse proposed to include certain identities into the key derivation. these identities heavily depend on the underlying protocol (e.g. sip uses different identities than wlans) should the draft be seen as a guidance? ciao hannes > -----Original Message----- > From: Joseph Salowey [mailto:jsalowey@cisco.com] > Sent: Thursday, July 10, 2003 8:05 AM > To: 'Walker, Jesse'; 'Bernard Aboba'; eap@frascone.com > Subject: RE: [eap] EAP key naming > > > > > > -----Original Message----- > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > > On Behalf Of Walker, Jesse > > Sent: Wednesday, July 09, 2003 1:52 PM > > To: Bernard Aboba; eap@frascone.com > > Subject: RE: [eap] EAP key naming > > > > > > > > In the case of 802.11, what is important is the right key > > gets delivered to the right AP, and never to any other party > > whatsoever. Vis-a-vis the binding discussion, this translates > > into a requirement for the EAP Server to be able assert that > > the key is bound to the pair > Address>, because that is the only meaningful key identifier > > at the MAC layer. This is what the Bindings field is for in > > the Archie Response and Confirm messages. An alternate > > approach might be to modify EAP directly to convey this > > information instead, since your standard run-of-the-mill EAP > > method does not have this exchange built in like Archie does. > > > > For other cases besides 802.11, mileage will vary; how to do > > the binding will be protocol specific. > > > > [Joe] This is one area where chaining of additional messages after an > EAP method can be really useful. Instead of having each method having > to define channel bindings and other bindings for n different > environments you define an EAP extension (for example an > EAP-TLV message > with a Channel-Binding TLV) to carry this information. It is > authenticated and possibly encrypted using keys derived from the EMSK > (shared only between the EAP-Peer and EAP-Server). This > extension could > be used with any key deriving EAP method. These two drafts > provide some > of the framework for this: > > http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt > http://www.ietf.org/internet-drafts/draft-salowey-eap-protecte dtlv-02.tx t What is left is to define a channel-binding-TLV (I think Jose may have one in his binding problem draft, if not I have one sketched out based on archie) and resolve the chaining issue (this requires a little bit more work). > > > That's my two cents, for what it is worth. > > -- Jesse > _______________________________________________ > 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 aboba@internaut.com Thu Jul 10 12:41:52 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 10 Jul 2003 04:41:52 -0700 (PDT) Subject: [eap] EAP key naming In-Reply-To: <00eb01c346a9$3b58ab70$0200000a@amer.cisco.com> References: <00eb01c346a9$3b58ab70$0200000a@amer.cisco.com> Message-ID: > >In the case of 802.11, what is important is the right key > gets delivered to the right AP, and never to any other party > whatsoever. Vis-a-vis the binding discussion, this translates > into a requirement for the EAP Server to be able assert that > the key is bound to the pair Address>, because that is the only meaningful key identifier > at the MAC layer. I'm not clear that the MSK is bound to the Calling-Station-Id. As we discussed previously, the MSK name is based on the tuple. That implies that the MSK is bound to the Peer, not to a particular interface. The question is whether a peer with multiple 802.11 interfaces could use an MSK derived through one interface on another interface. Intrinsically, I don't see anything wrong with this, although it does seem to imply that we have "late binding" -- the TSKs are bound to the pair but the the MSK is not. > This is what the Bindings field is for in > the Archie Response and Confirm messages. An alternate > approach might be to modify EAP directly to convey this > information instead, since your standard run-of-the-mill EAP > method does not have this exchange built in like Archie does. We've discussed how the EAP SA is between the EAP peer and EAP server, and therefore is not bound to a NAS. The MSK name is the EAP SA name + the NAS name. One issue is that is possible that the EAP peer may not know the NAS name, only the Called-Station-Id, because the NAS name may not be provided in the EAP-Request/Identity. So I think that the MSK name probably needs to include the Called-Station-Id as the NAS name. This also has an implication for encapsulations of EAP that use a multicast destination address, because in that case the Called-Station-Id may not be known -- I think this implies that if key derivation is required then unicast addresses must be used. > > For other cases besides 802.11, mileage will vary; how to do the > > binding will be protocol specific. EAP and AAA are media independent, so I don't think that this can be media specific. One way to deal with this is to require that the authentication server include the tuple in the Access Accept, along with the MSK Name. The Peer also has this information. Then during the secure association protocol exchange (4-way handshake), the EAP peer and NAS verify that they are using the same MSK and TSK names. This implies that the binding is verified during the secure association exchange (Phase 2), not in the EAP exchange (Phase 1). If so, then EAP methods don't need to include a binding exchange. From jari.arkko@piuha.net Thu Jul 10 14:24:00 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 10 Jul 2003 16:24:00 +0300 Subject: [eap] Revised (again) agenda for Vienna Message-ID: <3F0D68F0.8050002@piuha.net> Monday, July 14 at 1530-1730 =============================== Preliminaries (20 minutes) Bluesheets Minute Takers Agenda Bash Document Status Liason Statements RFC 2284bis (20 minutes), Henrik Levkowetz http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-04.txt http://www.levkowetz.com/pub/ietf/drafts/eap/draft-ietf-eap-rfc2284bis-04.html http://www.drizzle.com/~aboba/EAP/eapissues.html EAP State Machine (20 minutes), Pasi Eronen http://www.cs.umd.edu/~npetroni/EAP/draft-vollbrecht-eap-state-04.html http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-04.txt EAP Compound Binding (20 minutes), Jose Puthenkulam http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt Methods EAP SIM & AKA (10 minutes) H. Haverinen, J. Salowey, J. Arkko 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-SIM Security Analysis (20 minutes), Uri Blumenthal http://www.drizzle.com/~aboba/EAP/AnalyisOfEAP.pdf Thursday, July 17 at 1300-1500 =============================== EAP Client Side Transport (10 minutes), B. Boursetty http://www.ietf.org/internet-drafts/draft-boursetty-eap-cst-00.txt EAP Keying Framework (30 minutes), Bernard Aboba http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-07.txt Use of EAP Keying for DHCP Bootstrap (10 minutes), H. Tschofenig http://www.ietf.org/internet-drafts/draft-tschofenig-pana-bootstrap-rfc3118-00.txt EAP Key Derivation for Multiple Applications (10 minutes), H. Zhou http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt Methods (cont'd) EAP IKEv2 (10 minutes), H. Tschofenig http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-01.txt EAP LDAP (10 minutes), H. Mancini http://www.ietf.org/internet-drafts/draft-mancini-pppext-eap-ldap-00.txt EAP Support in Smartcard (10 minutes), P. Urien http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-02.txt http://www.ietf.org/internet-drafts/draft-urien-eap-ssc-00.txt PEAP Version 2 (10 minutes), J. Salowey/A. Palekar http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-06.txt EAP Archie (10 minutes), Jesse Walker http://www.ietf.org/internet-drafts/draft-jwalker-eap-archie-01.txt From jesse.walker@intel.com Thu Jul 10 15:01:15 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Thu, 10 Jul 2003 07:01:15 -0700 Subject: [eap] EAP key naming Message-ID: Joe: > [Joe] It should be a requirement that the EAP MSK and EMSK are fresh > every time an EAP method is run. This is a good requirement. I believe we should addit to the list. From jesse.walker@intel.com Thu Jul 10 15:55:24 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Thu, 10 Jul 2003 07:55:24 -0700 Subject: [eap] EAP key naming Message-ID: Bernard, > > There is (at least) one missing requirement: a key deriving=20 > EAP method must, > > if it completes successfully, leave the EAP Server and EAP Peer with > > synchronized session state. At the very least the EAP Server and EAP > > Peer must believe that the same NAIs have been=20 > authenticated, must share the > > same session key, and must have the same name for the=20 > session key. This > > does not follow necessarily from the other requirements. >=20 > That seems reasonable, although I am not clear that=20 > synchronization can be > maintained beyond the initial exchange, since either the peer or EAP > server can age out key state and there is no EAP "delete" message to > ensure synchronization. While this is true, the EAP method is responsible only for establishing = synchronization, not maintaining it. If the EAP method, however, does = not meet the synchronization requirement, then any keying material it = derives is not meaningful. If the peers have a different view of the = respective peer NAIs, or if they derive different keys, or different = names for the keys, then a man-in-the-middle has violated security. The = syncrhonization requirement is something that a key-deriving EAP method = must meet. The discussion of maintaining synchronization, and the discussion in = your original note, together imply that there is a lot more work to do = if we want to support keying. In particular, we need to expand the = document to discuss security association maintenance. Maybe each EAP = method needs companion session termination and session updates as well. = Or perhaps we can define these functions once in a way that applies to = all methods. I haven't thought about it. > > This misconstrues IEEE 802.11's request. The observation is=20 > that the base EAP > > document requires IEEE 802.11 systems with 802.1X Supplicants to > > implement MD5 Challenge, when in fact it should expressly=20 > prohibit their > > use in this context. Mandating its implementation without=20 > prohibiting > > its use in certain contexts demands that users decide for=20 > themselves in many > > contexts, and many users are not equipped to make this decision. >=20 > It seems reasonable to indicate that MD5 Challenge is inappropriate in > some circumstances. Would you care to file an issue=20 > indicating what text > you'd like to add? Here is strawman language: Unprotected MD5 Challenge is not suitable for some environments, such as IEEE 802.11 WLANs or across the unprotected Internet, because the protocol is not immune to man-in-the-middle attacks. It SHOULD never be used in such environments, and implementations SHOULD not expose this choice in such environments. > > The mandatory-to-implement method either should be safe in=20 > all environments, > > or else there should be no mandatory-to-implement method.=20 > The line of > > reasoning you make above suggests you would support removing MD5 > > Challenge as mandatory-to-implement. That would probably be an > > acceptable resolution. However, the status quo is not acceptable. >=20 > I don't think that having no mandatory-to-implement method is an > acceptable alternative. As noted in Erik Nordmark's=20 > presentation at IETF > 56, we can add text to RFC 2284bis indicating the minimum=20 > requirements for > various circumstances, and the security claims language should make it > clear what methods meet those requirements (no methods defined in RFC > 2284bis are appropriate for use with 802.11). > > There are lots of examples of mandatory-to-implement methods in IETF > protocols that can be used inappropriately or may not work in all > circumstances. So I'm not sure that it's necessary (or even=20 > possible) to > create a single method that would be suitable for all=20 > potential uses of > EAP. Ok; fair enough. If we have to have a mandatory-to-implement method, = then let's change the one we have. There are a number that might be = acceptable. My impression is that most folks prefer a method based on a = pre-shared key. I suggest EAP-Archie as a starting point, but then I'm = biased. > That's part of the problem -- getting agreement on what the mandatory > method should be would probably require a formal beauty=20 > contest that could > consume up to a year of the WG's time. As Erik suggested at=20 > IETF 56, our > time would probably be better spent reviewing and publishing=20 > a variety of > methods, and making sure their security properties were well > understood and letting the market decide. This is a fair comment. We should get a number of methods reviewed and = published as our first priority. However, the mandatory-to-implement = problem still exists, and it would be worthwhile trying to address it as = a secondary goal. If we can't, then we can't, but we should at least = try, given that the existing mandatory-to-implement method is not right. > > > Issue #6 requires mutual auth in all three legs -- EAP,=20 > AAA, and the > > > secure association protocol. AAA protocols already do mutual > > > authentication -- both RADIUS & Diameter handle this. So I > > > think we need > > > a requirement that EAP key deriving methods and secure association > > > protocols support mutual authentication, and Issue #6 is handled. >=20 > Russ's requirements apply to the system as a whole, so it=20 > probably makes > sense to describe the requirements for each piece. I don't=20 > think we can > punt on this particular issue. Ok, punt was definitely the wrong word. We need to talk about this being = a system requirement, but it is pretty clear that neither EAP nor EAP = methods can address this without changing in their fundamental natures. > > This almost but not quite right. Such a naming scheme does not > > distinguish names across sessions between the same EAP Peer and EAP > > Server. Think of the case where there is key roll-over due to > > reauthentication. Does the name refer to the old or to the=20 > new key? It > > refers to both, the scheme does not unambiguously identify=20 > the key, and > > the parties will not be able to tell which to use (they will not > > necessarily share the same notion of which one is current).=20 > There does > > not seem to be any choice but to (a) mandate that key-deriving EAP > > methods exchange nonces and (b) the nonces are part of the name. >=20 > I agree that the EAP peer and EAP server names do not=20 > uniquely define the > EAP SA. However, EAP method such as EAP-TLS often have a=20 > session-id or its > equivalent. Certainly a nonce exchange can help, and since=20 > we are going > to require that, perhaps your suggestions a) and b) are a way=20 > to guarantee > that the requirements are satisfied. Then the requirement is that key-deriving EAP methods must define = session discriminators that uniquely distinguish one session from = another. We can give examples such as the EAP-TLS session id and = EAP-Archie's NonceP and NonceS. =20 > > Since the MSK and ESMK are wholly compromised from the EAP=20 > Peer's perspective > > if either is ever shared with more than one NAS, we know=20 > that such key > > sharing cannot be allowed >=20 > The EMSK is compromised if it is known by *any* NAS. The MSK is > compromised if it is shared by more than one NAS. Agreed. > > so it is safe to use the NAS name as part of > > the MSK name; indeed, it would be rather odd if this were=20 > not the case. >=20 > So you're saying that the MSK name is different from the EAP SA > name? Is this solely because the EAP SA is not "bound" to a=20 > NAS while the > MSK is bound? What about the EMSK? This is not "bound" to a=20 > particular > NAS -- so is it's name the same as the EAP SA name? What=20 > about quantities > derived from the EMSK? How do we name those? If there are different keys, we need to name each differently. Since the = EMSK is an attribute of a session between the EAP Peer and EAP Server, = and not an attribute of any NAS, it needs to be named independently of = any NAS. It seems like the right way to name the EMSK is where tag is some arbitrary label. > So the first 4 quantities are the EAP SA name, and the MSK=20 > name is the EAP > SA name + the NAS NAI. Is it fair to say that the EMSK name=20 > is the same > as the EAP SA name? I am getting confused. Let me try to dig out, and you tell me if I what = I write seems right. All the keys need distinct names. I thought the = root session key is the MK. So it should be named MKID =3D It needs the Peer NAI as part of the name, because the MK is an = attribute of the EAP Peer's session. It needs the Server NAI as part of = the name, because the MK is an attribute of the EAP Server's session. It = needs some EAP method-specific session discriminator, to distinguish = this session between this Peer and Server from all other sessions = between the same peer. Perhaps we should include the method = discriminator as well, but anything that makes a reasonable method = specific session discriminator will have enough randomness to make it = unlikely that two session disriminators will collide. The MSK and EMSK names are derived from the MKID. The MSK is = NAS-specific, but the EMSK is not. So these two keys should be named MSKID =3D EMSKID =3D where I have chosen 0x00 as the tag; since the tag value is arbitrary, = replace it with anything you want if you don't like 0x00. If you derive something from the MSK, then that something is named SOMETHINGID =3D Or at least that is how I think of the naming. -- Jesse From jesse.walker@intel.com Thu Jul 10 15:58:05 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Thu, 10 Jul 2003 07:58:05 -0700 Subject: [eap] EAP key naming Message-ID: Joe: > > Since the MSK and ESMK are wholly compromised from the EAP=20 > > Peer's perspective if either is ever shared with more than=20 > > one NAS, we know that such key sharing cannot be allowed, so=20 > > it is safe to use the NAS name as part of the MSK name;=20 > > indeed, it would be rather odd if this were not the case. > > > [Joe] You are absolutely correct for the MSK, but the EMSK=20 > should not be > shared with anyone. It should only be know to the EAP-Peer and > EAP-Server. Keys derived from the EMSK may be shared with other > parties. The NAS name should not be used in a base identifier for the > EAP Keys. Perhaps the base identifier can be augmented with the NAS > name to identify the MSK. Right=20 -- Jesse From rgm-sec@htt-consult.com Thu Jul 10 16:20:13 2003 From: rgm-sec@htt-consult.com (Robert Moskowitz) Date: Thu, 10 Jul 2003 11:20:13 -0400 Subject: [eap] EAP key naming In-Reply-To: Message-ID: <5.1.0.14.2.20030710110808.00aa4000@localhost> At 12:52 AM 7/9/2003 -0700, Bernard Aboba wrote: >So it would appear to me that the 3-tuple of the (Peer NAI, Server Name, >EAP method key name) is sufficient to name the EAP SA. Note that this >scheme assumes that it is possible for an EAP peer and EAP server to have >more than one valid EAP SA at a time. Here is what I am working up as the key name: KeyID = Truncate-128(SHA1(NAI || EAP Method Type || Key || Called-Station-Id || Calling-Station-Id || "The name is the game")) And for 'Key' you can substitute: MK MSK EMSK PMK Not all of these may need Ids, but the option should be there. Note that this names the key as: Who is the key for From What system Through What authenticator (optionally on what network see Annex D of 802.1aa) Via What methodology It produces very unique KeyIDs, and peer and AS will have very few IDs built on the same information (AS will be timing old ones out, the peer will have to use heiristics to age old IDs). There are a few problems with this. Which NAI? The method 'knows' and should provide that going outward. E.G. PEAP/MSCHAPv2, it is the NAI in the MSCHAPv2 part. Which EAP Method Type? What would you use for PEAP/MSCHAPv2 compared to PEAP/TLS? I don't have the answer to that one. Robert Moskowitz TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From Pasi.Eronen@nokia.com Thu Jul 10 16:42:31 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Thu, 10 Jul 2003 18:42:31 +0300 Subject: [eap] RE: EAP key naming Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222C2@esebe023.ntc.nokia.com> Hi, I'm not sure if Russ actually intended his slides to be=20 used as a "checklist" (especially since it's not at all obvious what some of the items mean), but at least the list seems bring up some rather interesting=20 problems--here are my 0.02 euros on this :-) I haven't completely grasped this "key naming" issue yet, but I think it might be related to the "authenticate all parties" item? Authentication between peer<->server and AP<->server is well understood (some EAP method, and e.g. TLS when using Diameter), but the "third leg" between peer and AP seems to be quite different. So, I was thinking that actually the "key naming" tries to accomplish this, by authenticating the MAC addresses of the=20 peer and AP. (The four-way handshake includes the MAC addresses, but it does not authenticate them--since both=20 parties can freely put whatever they want as their own address). Suppose for a moment that the peer knows the MAC address of=20 the AP it wants to connect to. Currently any other AP can simply change its MAC address to this; the EAP conversation will=20 work just fine, and this rogue AP will get the MSK from the server. (Note that this basically requires that an authorized AP is compromised or turns evil--it can't be done by a total outsider). Jesse Walker's idea of including the AP's MAC address inside the EAP method (as done in EAP-Archie) seems to prevent this _if_ the server can authenticate the AP's MAC when delivering the=20 key (just comparing it with Called-Station-Id doesn't work).=20 If APs use e.g. Diameter-over-TLS to talk to the server,=20 the AP's MAC address could be maybe included in the=20 certificate or something. When the AP now proves that it knows the PMK in the four-way handshake, the peer knows that it is really talking to AP with the desired MAC address. So, it would be correct to say that the AP has authenticated this identity to the peer=20 (with help from a third party trusted by both of them). This doesn't give us authentication of the peer MAC address to the AP yet. A valid peer can change the WLAN card's address to VICTIM_MAC, authenticate as usual, and after a while, the AP=20 starts to use a key known to the attacker for encrypting traffic=20 to VICTIM_MAC. Including the peer's MAC address inside the EAP method, and comparing this with Calling-Station-Id doesn't help here. The server would need to know which user has which MAC address. This might be difficult (it could be included in a certificate, for instance, but I don't think this is likely?). I think that one difficulty here is that the identities that are currently authenticated are not the ones used to select which key to use (and "route" the packets). It seems that there might a similar issue present at one layer above; maybe this would give some insight? (or then again, maybe not--I'm not quite sure on this) Suppose that a client with IP 1.2.3.4 uses IKE to connect to some other host, and authenticates itself with a certificate (this might involve some back-end authentication server, but it's not visible to the client). If the client authenticates=20 as "bob@example.com", the responder will certainly _not_ set up=20 an SA that says "encrypt all traffic to 1.2.3.4 with this key". =20 It will require either a local database that says "bob@example.com has IP 1.2.3.4" or a certificate that contains 1.2.3.4 (an iPAddress subjectAltName). Or, in the case of "road warrior=20 gateway", it assigns a new IP address to the client (often=20 needed for sane routing anyway). Thus, to meet all of Russ's requirements, we would need to authenticate the MAC addresses or assign new MAC addresses after authentication? Oh , this does not look good... at least there'll be an interesting discussion in Vienna :-)=20 (Unfortunately I'll miss that one, since it's on Thursday... but if somebody's interested in a having "bar BOF" about=20 this Saturday..Tuesday, count me in!) Best regards, Pasi > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, July 10, 2003 2:42 PM > To: Joseph Salowey > Cc: 'Walker, Jesse'; eap@frascone.com > Subject: RE: [eap] EAP key naming >=20 >=20 > > >In the case of 802.11, what is important is the right key > > gets delivered to the right AP, and never to any other party > > whatsoever. Vis-a-vis the binding discussion, this translates > > into a requirement for the EAP Server to be able assert that > > the key is bound to the pair > Address>, because that is the only meaningful key identifier > > at the MAC layer. >=20 > I'm not clear that the MSK is bound to the Calling-Station-Id. As > we discussed previously, the MSK name is based on the name, AS name, NAS Name> tuple. That implies that the MSK is=20 > bound to the Peer, not to a particular interface. The question=20 > is whether a peer with multiple 802.11 interfaces could use=20 > an MSK derived through one interface on another interface.=20 > Intrinsically, I don't see anything wrong with this, although > it does seem to imply that we have "late binding" -- the TSKs=20 > are bound to the pair =20 > but the the MSK is not. > From rgm-sec@htt-consult.com Thu Jul 10 16:43:44 2003 From: rgm-sec@htt-consult.com (Robert Moskowitz) Date: Thu, 10 Jul 2003 11:43:44 -0400 Subject: [eap] FYI: Several new EAP-related internet-drafts In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222B8@esebe023.ntc.nokia. com> Message-ID: <5.1.0.14.2.20030710114210.02c63410@localhost> At 01:38 PM 7/4/2003 +0300, Pasi.Eronen@nokia.com wrote: >J. Arkko, H. Haverinen: EAP AKA Authentication >http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-10.txt I can't access ietf's web site. Is it me or is it hung??? Robert Moskowitz ICSAlabs/A Division of TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From jesse.walker@intel.com Thu Jul 10 16:47:54 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Thu, 10 Jul 2003 08:47:54 -0700 Subject: [eap] EAP key naming Message-ID: Bob > Here is what I am working up as the key name: >=20 > KeyID =3D Truncate-128(SHA1(NAI || EAP Method Type || Key ||=20 > Called-Station-Id || Calling-Station-Id || "The name is the game")) > > And for 'Key' you can substitute: >=20 > MK > MSK > EMSK > PMK >=20 > Not all of these may need Ids, but the option should be there. I wonder whether the naming scheme should reflect the hierarchy. Bernard = has already objected to insertion of the key into the naming scheme. = Also, Bernard's original note indicated a desire to have the naming = hierarchy explicitly visible, presumably so that the key names are = intelligible to the poor souls who have to trouble-shoot problems in the = network. On the other hand, a lot of protocols (like 802.11i) could = really use "more efficient" names, so having both human readable key = names and machine manipulatable key ids might be better. Something like MK Name =3D Peer NAI | Server NAI | EAP Method | Session Discriminator MKID =3D Truncate-128(SHA1(MK Name)) EMSK Name =3D MK Name | 0x00 EMSKID =3D Truncate-128(SHA1(EMSKID)) MSK Name =3D MK Name | NAS NAI MSKID =3D Truncate-128(SHA1(MSK Name)) etc. would seem to better meet these constraints. > Which NAI? The method 'knows' and should provide that going=20 > outward. E.G.=20 > PEAP/MSCHAPv2, it is the NAI in the MSCHAPv2 part. I think the naming scheme should include the names of any relevent = parties. > Which EAP Method Type? What would you use for PEAP/MSCHAPv2=20 > compared to=20 > PEAP/TLS? I don't have the answer to that one. The "right" answer is probably some standard encoding of the registered = EAP method identifier. From Pasi.Eronen@nokia.com Thu Jul 10 16:51:46 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Thu, 10 Jul 2003 18:51:46 +0300 Subject: [eap] FYI: Several new EAP-related internet-drafts Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB71@esebe023.ntc.nokia.com> Robert Moskowitz wrote: > At 01:38 PM 7/4/2003 +0300, Pasi.Eronen@nokia.com wrote: >=20 > >J. Arkko, H. Haverinen: EAP AKA Authentication > >http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-10.txt >=20 > I can't access ietf's web site. Is it me or is it hung??? The host www.ietf.org seems to have two A records (4.17.168.6 and=20 132.151.6.21); the latter work OK for me, but the former doesn't seem to answer... Try if these work: http://4.17.168.6/internet-drafts/draft-arkko-pppext-eap-aka-10.txt http://132.151.6.21/internet-drafts/draft-arkko-pppext-eap-aka-10.txt Best regards, Pasi From jsalowey@cisco.com Thu Jul 10 17:23:57 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Thu, 10 Jul 2003 09:23:57 -0700 Subject: [eap] EAP key naming In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BBFFCC@mchp905a.mch.sbs.de> Message-ID: <010a01c346ff$aae2f030$0200000a@amer.cisco.com> Hi Hannes, Thanks for taking a look at this, comments below. > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, July 10, 2003 2:54 AM > To: 'Joseph Salowey'; 'Walker, Jesse'; 'Bernard Aboba'; > eap@frascone.com > Subject: RE: [eap] EAP key naming > > > hi joe, > > if i look at russ's requirements and then look at your draft > http://www.ietf.org/internet-drafts/draft-salowey-eap-protecte > dtlv-02.txt > then i am not sure whether the requirements are met / are applicable. > [Joe] I may have misled you here. The protected TLV is an application of cryptographic key material established through the EAP authentication process. Its scope is much smaller than the general EAP key distribution problem. It is useful in extending the EAP exchange in a consistent way. > in your proposal you use the keying material based on the > previous eap exchange to create this protected tlv. if you > compare this with the handshake done in the ieee 802.11i 4 > way handshake then there is some difference there. > [Joe] true, but it is solving a different problem. > for me that is just fine. currently the requirements address > the following > protocols: > a) the eap exchange itself > b) the aaa protocol and > c) the protocol which uses the keying material afterwards > ((this is probably the most difficult part which was not > discussed in detail so far) > [Joe] Protected-TLV has to do with c, it is a usage of EAP derived keying material. > the characteristics of the protocol where eap should provide > keying material will most likely vary a lot. > hence i would like to better understand the requirements with > regard to the different protocols that utilize the eap > derived keying material. > > some examples of protocols which use the eap established > keying material > are: > - ieee wlan environment > - your protected tlv or the > http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt > - pana > - pana dhcp bootstrapping > - pana ipsec establishment, > - etc. > [Joe] The EAP key derivation draft has much broader applicability than protected-TLV. It is mostly focused on derivation of keys from the EMSK. There are several reasons for using the EMSK: 1. There is no guarantee on how the MSK will be used currently so deriving keys from it is a dangerous game. The original WEP specification is a case in point. 2. The MSK is known by the NAS so anything derived from it is known to the NAS. This does not provide separation between the NAS and other consumers of EAP key material. I think it is reasonable to use the EMSK for all applications that are not link layer ciphering. > ciao > hannes > > btw, i never fully understood your draft > http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deri > v-01.txt. a number of protocol in the past proposed (e.g. > pana, sip, some proposals in the 3gpp, pic, etc. etc.) to use > eap to create keying material. since these protocols vary (as > argued above) in their characteristics and requirements it > will not work to define a single key derivation function for > all of them. > [Joe] So while I agree that the needs of all applications are not met by a single KDF, I think the KDFs for applications need to be coordinated. This coordination is needed to eliminate the possibility of deriving keys that do not have good cryptographic separation. Fundamentally all of these applications require some shared key material to start with. The key derivation draft describes how you arrive at a shared key that is unique for an application and has a some independence from other keys derived for other applications. Once you have this application master session key (AMSK) you can use it to derive other keys for various uses (TSKs). This derivation is application specific and not defined in the draft so it can meet a wide variety of needs. > an example: jesse proposed to include certain identities into > the key derivation. these identities heavily depend on the > underlying protocol (e.g. sip uses different identities than wlans) > [Joe] This can be accomplished in one of two ways. Either derivation of AMSK from the EMSK can take the application specific data (this is partially specified in the draft). Or when the TSKs for the application are derived from the AMSK the can use a key derivation that incorporates this information. > should the draft be seen as a guidance? [Joe] The draft is more than a guidance, but it does not specify every thing need to derive keys for an application. The draft specifies how to get one or more AMSKs from the EMSK in a way that maintains the secrecy of the EMSK and provides separation between each of the AMSKs (and the MSK as well if the EMSK and MSK are independent). This is important so that if any of the application keys are compromised it does not directly lead to the compromise of any of the AMSKs or MSK. Applications are then free to derive there own TSKs from the AMSK in any way the see fit, and use them is any way they want. This is not to say that what is in the drafts cannot be improved upon. We are looking for feedback on how they can be improved to meet security and application requirements. Hope this helps, joe > > ciao > hannes > > > -----Original Message----- > > From: Joseph Salowey [mailto:jsalowey@cisco.com] > > Sent: Thursday, July 10, 2003 8:05 AM > > To: 'Walker, Jesse'; 'Bernard Aboba'; eap@frascone.com > > Subject: RE: [eap] EAP key naming > > > > > > > > > > > -----Original Message----- > > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > > > On Behalf Of Walker, Jesse > > > Sent: Wednesday, July 09, 2003 1:52 PM > > > To: Bernard Aboba; eap@frascone.com > > > Subject: RE: [eap] EAP key naming > > > > > > > > > > > > > In the case of 802.11, what is important is the right key > > > gets delivered to the right AP, and never to any other party > > > whatsoever. Vis-a-vis the binding discussion, this translates > > > into a requirement for the EAP Server to be able assert that > > > the key is bound to the pair > > Address>, because that is the only meaningful key identifier > > > at the MAC layer. This is what the Bindings field is for in > > > the Archie Response and Confirm messages. An alternate > > > approach might be to modify EAP directly to convey this > > > information instead, since your standard run-of-the-mill EAP > > > method does not have this exchange built in like Archie does. > > > > > > For other cases besides 802.11, mileage will vary; how to do > > > the binding will be protocol specific. > > > > > > > [Joe] This is one area where chaining of additional > messages after an > > EAP method can be really useful. Instead of having each > method having > > to define channel bindings and other bindings for n different > > environments you define an EAP extension (for example an EAP-TLV > > message with a Channel-Binding TLV) to carry this > information. It is > > authenticated and possibly encrypted using keys derived > from the EMSK > > (shared only between the EAP-Peer and EAP-Server). This > > extension could > > be used with any key deriving EAP method. These two drafts > > provide some > > of the framework for this: > > > > > http://www.ietf.org/internet-drafts/draft-> salowey-eap-key-deriv-01.txt > > http://www.ietf.org/internet-drafts/draft-salowey-eap-protecte > dtlv-02.tx > t > > What is left is to define a channel-binding-TLV (I think Jose > may have one in his binding problem draft, if not I have one > sketched out based on archie) and resolve the chaining issue > (this requires a little bit more work). > > > > > > > That's my two cents, for what it is worth. > > > > -- Jesse > > _______________________________________________ > > 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 jesse.walker@intel.com Thu Jul 10 16:10:26 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Thu, 10 Jul 2003 08:10:26 -0700 Subject: [eap] EAP key naming Message-ID: Joe: > > In the case of 802.11, what is important is the right key=20 > > gets delivered to the right AP, and never to any other party=20 > > whatsoever. Vis-a-vis the binding discussion, this translates=20 > > into a requirement for the EAP Server to be able assert that=20 > > the key is bound to the pair > Address>, because that is the only meaningful key identifier=20 > > at the MAC layer. This is what the Bindings field is for in=20 > > the Archie Response and Confirm messages. An alternate=20 > > approach might be to modify EAP directly to convey this=20 > > information instead, since your standard run-of-the-mill EAP=20 > > method does not have this exchange built in like Archie does. > >=20 > > For other cases besides 802.11, mileage will vary; how to do=20 > > the binding will be protocol specific. > >=20 >=20 > [Joe] This is one area where chaining of additional messages after an > EAP method can be really useful. Instead of having each method having > to define channel bindings and other bindings for n different > environments you define an EAP extension (for example an=20 > EAP-TLV message > with a Channel-Binding TLV) to carry this information. It is > authenticated and possibly encrypted using keys derived from the EMSK > (shared only between the EAP-Peer and EAP-Server). This=20 > extension could > be used with any key deriving EAP method. These two drafts=20 > provide some > of the framework for this: >=20 > http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt > http://www.ietf.org/internet-drafts/draft-salowey-eap-protecte > dtlv-02.tx > t > > What is left is to define a channel-binding-TLV (I think Jose may have > one in his binding problem draft, if not I have one sketched out based > on archie) and resolve the chaining issue (this requires a little bit > more work). I can live with a chained EAP method that is just to establish bindings, = if we can work out the security. If the original EAP method meets the synchronization requirement, then = it will not complete successfully if a man-in-the-middle between the EAP = Peer and EAP Server disrupts it. So the binding information between the = EAP Peer and EAP Server can be protected by the derived MK. What is not clear in this scheme is how the NAS is protected when the = bindings are decoupled from the original authentication. Perhaps the NAS = always should send its view of the bindings with every EAP method. If = the EAP Server is checking for bindings inconsistencies, then these will = either match the later chained method or it will not, and the EAP Server = will be able to make an appropriate assertion at that time. I don't = know; I haven't thought it through. The requirement is the EAP Server = should be able to assert that the MSK is bound to identities the EAP = Peer and NAS will verify as part of MSK usage. -- Jesse From aboba@internaut.com Thu Jul 10 17:04:25 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 10 Jul 2003 09:04:25 -0700 (PDT) Subject: [eap] Issue 159: Organization Issues Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: July 9, 2003 Reference: Document: EAP-04 Comment type: E Priority: 1 Section: 2.2, 4.1 Rationale/Explanation of issue: The organization of section 2.2 and 4.1 could be improved. Proposed changes: Delete the following text from Section 2.2: Paragraphs from "Where an authenticator operates as a pass-through..." to the end of the section (all material relating to pass-through operation). Add the following text to Section 2.3: 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 validity checks on the Code, Identifer 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. The forwarding model is illustrated in Figure 2. Compliant pass-through authenticator implementations MUST by default be capable of forwarding packets from any EAP method. The use of the RADIUS protocol for encapsulation of EAP in pass-through operation is described in [RFC2869bis]. Peer Pass-through Authenticator Authentication Server +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | V | | ^ | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | | | | | ! | |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." Replace Section 4.1 with the following: "4.1 Request and Response Description The Request packet (Code field set to 1) is sent by the authenticator to the peer. Each Request has a Type field which serves to indicate what is being requested. Additional Request packets MUST be sent until a valid Response packet is received, or an optional retry counter expires. Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests. The contents of the data field are dependent on the Request Type. The peer MUST send a Response packet in reply to a valid Request packet. Responses MUST only be sent in reply to a valid Request and never retransmitted on a timer. If a peer receives a valid duplicate Request for which it has already sent a Response, it MUST resend its original Response without reprocessing the Request. Requests MUST be processed in the order that they are received, and MUST be processed to their completion before inspecting the next Request. A summary of the Request and Response packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Type-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Code 1 for Request 2 for Response Identifier The Identifier field is one octet. The Identifier field MUST be the same if a Request packet is retransmitted due to a timeout while waiting for a Response. Any new (non-retransmission) Requests MUST modify the Identifier field. The Identifier field of the Response MUST match that of the currently outstanding Request. An authenticator receiving a Response whose Identifier value does not match that of the currently outstanding Request MUST silently discard the Response. In order to avoid confusion between new Requests and retransmissions, the Identifier value chosen for each new Request need only be different from the previous Request, but need not be unique within the conversation. One way to achieve this is to start the Identifier at an initial value and increment it for each new Request. Initializing the first Identifier with a random number rather than starting from zero is recommended, since it makes sequence attacks somewhat harder. Since the Identifier space is unique to each session, authenticators are not restricted to only 256 simultaneous authentication conversations. Similarly, with re-authentication, an EAP conversation might continue over a long period of time, and is not limited to only 256 roundtrips. Implementation Note: The authenticator is responsible for retransmitting Request messages. If the Request message is obtained from elsewhere (such as from a backend authentication server), then the authenticator will need to save a copy of the Request in order to accomplish this. The peer is responsible for detecting and handling duplicate Request messages before processing them in any way, including passing them on to an outside party. The authenticator is also responsible for discarding Response messages with a non-matching Identifier value before acting on them in any way, including passing them on to the backend authentication server for verification. Since the authenticator can retransmit before receiving a Response from the peer, the authenticator can receive multiple Responses, each with a matching Identifier. Until a new Request is received by the authenticator, the Identifier value is not updated, so that the authenticator forwards Responses to the backend authentication server, one at a time. Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Type-Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored on reception. A message with the Length field set to a value larger than the number of received octets MUST be silently discarded. Type The Type field is one octet. This field indicates the Type of Request or Response. A single Type MUST be specified for each EAP Request or Response. An initial specification of Types follows in Section 5 of this document. The Type field of a Response MUST either match that of the Request, or correspond to a legacy or Expanded Nak (see Section 5.3) indicating that a Request Type is unacceptable to the peer. A peer MUST NOT send a Nak (legacy or expanded) in response to a Request, after an initial non-Nak Response has been sent. An EAP server receiving a Response not meeting these requirements MUST silently discard it. Type-Data The Type-Data field varies with the Type of Request and the associated Response." From jsalowey@cisco.com Thu Jul 10 17:40:16 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Thu, 10 Jul 2003 09:40:16 -0700 Subject: [eap] EAP key naming In-Reply-To: <5.1.0.14.2.20030710110808.00aa4000@localhost> Message-ID: <010c01c34701$f21a86f0$0200000a@amer.cisco.com> What are the requirements for naming? Is something required beyond a unique identifier? If there are other requirements we need to explicitly state them. If it is uniquness that we are after then I don't see what is wrong with requiring the method to gereate a name from the random nonces it uses (it could use other data as well). Joe > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Robert Moskowitz > Sent: Thursday, July 10, 2003 8:20 AM > To: Bernard Aboba; eap@frascone.com > Subject: Re: [eap] EAP key naming > > > At 12:52 AM 7/9/2003 -0700, Bernard Aboba wrote: > > >So it would appear to me that the 3-tuple of the (Peer NAI, Server > >Name, EAP method key name) is sufficient to name the EAP SA. > Note that > >this scheme assumes that it is possible for an EAP peer and > EAP server > >to have more than one valid EAP SA at a time. > > Here is what I am working up as the key name: > > KeyID = Truncate-128(SHA1(NAI || EAP Method Type || Key || > Called-Station-Id || Calling-Station-Id || "The name is the game")) > > And for 'Key' you can substitute: > > MK > MSK > EMSK > PMK > [Joe] I don't think the > Not all of these may need Ids, but the option should be there. > > Note that this names the key as: > > Who is the key for > From What system > Through What authenticator > (optionally on what network see Annex D of 802.1aa) > Via What methodology > > It produces very unique KeyIDs, and peer and AS will have > very few IDs > built on the same information (AS will be timing old ones > out, the peer > will have to use heiristics to age old IDs). > > There are a few problems with this. > > Which NAI? The method 'knows' and should provide that going > outward. E.G. > PEAP/MSCHAPv2, it is the NAI in the MSCHAPv2 part. > > Which EAP Method Type? What would you use for PEAP/MSCHAPv2 > compared to > PEAP/TLS? I don't have the answer to that one. > > > Robert Moskowitz > TruSecure Corporation > Security Interest EMail: rgm-sec@htt-consult.com > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jsalowey@cisco.com Thu Jul 10 17:54:55 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Thu, 10 Jul 2003 09:54:55 -0700 Subject: [eap] EAP key naming In-Reply-To: Message-ID: <010d01c34703$fdf82d40$0200000a@amer.cisco.com> Hi Jesse > > I can live with a chained EAP method that is just to > establish bindings, if we can work out the security. > > If the original EAP method meets the synchronization > requirement, then it will not complete successfully if a > man-in-the-middle between the EAP Peer and EAP Server > disrupts it. So the binding information between the EAP Peer > and EAP Server can be protected by the derived MK. > > What is not clear in this scheme is how the NAS is protected > when the bindings are decoupled from the original > authentication. Perhaps the NAS always should send its view > of the bindings with every EAP method. If the EAP Server is > checking for bindings inconsistencies, then these will either > match the later chained method or it will not, and the EAP > Server will be able to make an appropriate assertion at that > time. I don't know; I haven't thought it through. The > requirement is the EAP Server should be able to assert that > the MSK is bound to identities the EAP Peer and NAS will > verify as part of MSK usage. I think I see what you are getting at, but I'm nto sure I completely follow it. As you mention the binding information is protected by a key that is derived from the MK from the authentication exchange. When the binding is run the verification is checked and should fail immediately if the varification fails. However I agree that there is some more thought that needs to go into this. A diagram might help I'll try to get something together Some of the difficulty has to do with the intracacies of chaining. If the chaining appears as one EAP conversation then the NAS information is typically provided in every RADIUS message in the called and calling station IDs which should be consistent trought the conversation. In the case that chaining is achieved as two separate eap conversations then there must be a way to associate one conversation from another. This is where naming would be really important! > > -- Jesse > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Thu Jul 10 17:41:18 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 10 Jul 2003 09:41:18 -0700 (PDT) Subject: [eap] RE: EAP key naming In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222C2@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A61222C2@esebe023.ntc.nokia.com> Message-ID: > Authentication between peer<->server > and AP<->server is well understood (some EAP method, > and e.g. TLS when using Diameter), but the "third leg" > between peer and AP seems to be quite different. I think of the "third leg" of the exchange as having many of the same properties as IKEv1 phase 2 -- it provides secure negotiation of the security parameters, including ciphersuite and modes (if relevant), provides freshness for transient session keys, proves possession of the keying material derived in Phase 1 (EAP), handles key activation/deletion/re-key. For this to work there has to be a binding between the Phase 2 SA and the Phase 1 (EAP) SA. > So, I was thinking that actually the "key naming" tries to > accomplish this, by authenticating the MAC addresses of the > peer and AP. Key naming and authentication are orthogonal issues. > (The four-way handshake includes the MAC > addresses, but it does not authenticate them--since both > parties can freely put whatever they want as their own address). In effect, Phase 2 "binds" the TSKs to the Called-Station-Id and Calling-Station-Id. If an EAP SA is named by the peer name and EAP server name as well as the nonces, then it is not bound to an L2 address -- and in fact the same EAP SA could be used on multiple interfaces. The MSK name is the EAP SA name + the NAS Address (L2, L3), since the same MSK cannot be reused on multiple NASes. The Phase 2 Exchange produces TSKs which are named by the tuple. As a result, Phase 2 is where the binding occurs, not EAP (Phase 1). > Suppose for a moment that the peer knows the MAC address of > the AP it wants to connect to. Currently any other AP can > simply change its MAC address to this; the EAP conversation will > work just fine, and this rogue AP will get the MSK from the server. Only an AP that is trusted by the AAA server can do this -- otherwise a mutually authenticating EAP method would fail. The NAS can not only lie about the Called-Station-Id, it can also lie about the NAS-IP-Address, the NAS-Identifier and the Calling-Station-Id. This is discussed in RFC 2869bis. There are ways for AAA proxies or servers to check for a forged NAS-Identifier or NAS-IP-Address, and at the same time they could check for a forged Called-Station-Id (e.g. it has to correspond to a non-forged NAS-Identifier or NAS-IP-Address). The Calling-Station-Id is harder since there is no way for the AAA server to verify that. Also, a NAS could communicate with the EAP peer using a different L2 address than it puts into the Called-Station-Id attribute sent to the AAA server. > (Note that this basically requires that an authorized AP is > compromised or turns evil--it can't be done by a total > outsider). Yes. It's not totally out of the realm of possibility for a NAS to get a virus, for example. > Jesse Walker's idea of including the AP's MAC address inside the > EAP method (as done in EAP-Archie) seems to prevent this _if_ > the server can authenticate the AP's MAC when delivering the > key (just comparing it with Called-Station-Id doesn't work). Yes, because the NAS can tell the AAA server and EAP peer different things. > If APs use e.g. Diameter-over-TLS to talk to the server, > the AP's MAC address could be maybe included in the > certificate or something. I think this doesn't help much because the AAA server can check the Called-Station-Id anyway, and the threat you outlined is about the NAS lying to the EAP peer. > When the AP now proves that it knows the PMK in the four-way > handshake, the peer knows that it is really talking to AP > with the desired MAC address. Not really. The AP can tell the AAA server and EAP peer different MAC addresses, and the 4-way handshake works just fine. > Including the peer's MAC address inside the EAP method, and > comparing this with Calling-Station-Id doesn't help here. The > server would need to know which user has which MAC address. > This might be difficult (it could be included in a certificate, > for instance, but I don't think this is likely?). I don't think there's anything that can prevent an EAP peer from changing their L2 address. Similarly, there's nothing that prevents an IKE Initiator from stealing another hosts's IP address, and initiating an IKE exchange using it. The only question is what the various keys are bound to and whether changing the L2 address invalidates the binding. > I think that one difficulty here is that the identities that are > currently authenticated are not the ones used to select which > key to use (and "route" the packets). Actually, I think the identities are different during each phase. In EAP (Phase 1), the relevant identities are those of the EAP peer and EAP server. Since EAP SAs aren't bound to L2 addresses, those aren't relevant. The MSK is bound to the EAP SA and NAS name, and it would appear that the Called-Station-Id is the only reliable surrogate for the NAS name. I think that the EMSK name is the EAP SA name + an additional identifier ("EMSK"?). Then the TSKs are bound to the tuple in the exchange "proving possession" of the MSK. Given all of this, I'm not sure exactly what it means to "authenticate" the tuple. Are we trying to prove that an EAP peer or NAS has the right to that MAC address? This would require some sort of certification from an authority (the IEEE), which seems somewhat impractical. Plus one of the major advantages of EAP is that the entities do *not* need to identified via their L2 addresses, which is an administrative headache. > Suppose that a client with IP 1.2.3.4 uses IKE to connect to > some other host, and authenticates itself with a certificate > (this might involve some back-end authentication server, but > it's not visible to the client). If the client authenticates > as "bob@example.com", the responder will certainly _not_ set up > an SA that says "encrypt all traffic to 1.2.3.4 with this key". Actually, quite a few implementations will do this. > It will require either a local database that says "bob@example.com > has IP 1.2.3.4" or a certificate that contains 1.2.3.4 (an > iPAddress subjectAltName). In practice, the IPAddress is not placed in the subjectAltName; that is where bob@example.com goes. This issue does arise more seriously in MIPv6 where there is a need to bind the Home Address to the IKE Identity-Payload. From aboba@internaut.com Thu Jul 10 17:51:40 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 10 Jul 2003 09:51:40 -0700 (PDT) Subject: [eap] EAP key naming In-Reply-To: <5.1.0.14.2.20030710110808.00aa4000@localhost> References: <5.1.0.14.2.20030710110808.00aa4000@localhost> Message-ID: > Here is what I am working up as the key name: > > KeyID = Truncate-128(SHA1(NAI || EAP Method Type || Key || > Called-Station-Id || Calling-Station-Id || "The name is the game")) > > And for 'Key' you can substitute: > > MK > MSK > EMSK > PMK I don't think that this formula works. As Joe noted, the MK is named by the EAP method, and since it is purely between the EAP peer and EAP server, it can have no dependence on Called-Station-Id, Calling-Station-Id and least of all the MK itself, which can't be exported. EAP methods have their own MK names (in TLS this is the session-id). As Jesse noted, the EAP SA is uniquely named by the combination of EAP peer NAI, the EAP server name, and the nonces. The called-station-id and calling-station-id do not play a role. As Jesse also noted, the MSK is named by the EAP SA name + a NAS name (for which the Called-Station-Id may be used as a surrogate). The Calling-Station-Id does not play a part, and neither does the actual MSK itself. The EMSK has a name of the EAP SA name + a static string. So the formula looks off there too. It would seem to me that the PMK has no unique name of its own, just the name of its parent + potentially an additional string. So if the PMK is derived from the MSK, then it has a name of the MSK name + "lower 32 bits" or something like that, whereas if it is derived from the EMSK, it has a name of the EMSK name + a static string. From aboba@internaut.com Thu Jul 10 18:09:28 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 10 Jul 2003 10:09:28 -0700 (PDT) Subject: [eap] Proposed Resolution to Issue 146: Multiplexing Model Requirements Message-ID: The text of Issue 146 is included below. The proposed fix is as follows: In Section 2.2, change: "Since EAP authentication methods may wish to access the Identity, the Identity Request and Response can be assumed to be accessible to authentication methods (Types 4 or greater) in addition to the Identity method. The Identity Type is discussed in Section 5.1." to: "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." ----------------------------------------------------------- Issue 146: Multiplexing Model Requirements Submitter name: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: June 18, 2003 Reference: Document: EAP-04 Comment type: T Priority: 1 Section: 2.2 Rationale/Explanation of issue: The draft says: "Since EAP authentication methods may wish to access the Identity, the Identity Request and Response can be assumed to be accessible to authentication methods (Types 4 or greater) in addition to the Identity method. The Identity Type is discussed in Section 5.1." There's a requirement on an implementation here, I think. Maybe we should say that the Identity Request and Response SHOULD or MUST be made accessible to authentication methods? [Jari Arkko] Yes. ... esponse SHOULD be accessible to ....? From aboba@internaut.com Thu Jul 10 18:12:32 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 10 Jul 2003 10:12:32 -0700 (PDT) Subject: [eap] Proposed Resolution to Issue 149: Reject Message-ID: The text of Issue 149 (and subsequent discussion) is included below. Based on discussion it would appear that there is no consensus for the change. The recommendation is that the change advocated in Issue 149 be rejected. ----------------------------------------------------- Issue 149: Peer Policy Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: June 16, 2003 Reference: Document: EAP-04 Comment type: T Priority: 2 Section: 7.8 Paragraph 2 Rationale/Explanation of issue: Peers may include policy, especially when connecting subnets. Additionally the same identity may have different permissions at different Access Points. Requested change: In paragraph 2 make the following 2 changes noted in quotes below - Within or associated with each authenticator, it is not anticipated that a particular named peer will support a choice of methods "for a given connection". This would make the peer vulnerable to attacks that negotiate the least secure method from among a set. Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name "at an access point". If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. [Jari Arkko] Hmm... I don't have a warm and fuzzy feeling about this. What if the attacker spoofs the name of the access point to get the bidding down attack started? [JRV] This is where policy must be involved. if the attacker AP bids up, the authentication should go up. If the attacker AP bids down, the authentication and also the rights should go down. Additional info may be involved, depending whether the AP is wireless or wired. Wireless may require Keys and a different authentication method than wired. I think the idea that there should be only one id for each authentication method is too restrictive. The same user should be able to get on in different places, with different rights, using different authentication methods. The user could have different ids for each authentication method and try to match the id to the access type, geographic location, etc. - but this seems unlikely in practice. [Jari Arkko] I can see your argument. But I'm still worried that without a specific model for what policies are possible, there'll be bidding down problems. For instance, the AP identity does not appear to be a good source for the policy, but link type (wired/wireless) might be slightly better. So, I'd rather err on the safe side and not allow such flexibility. The downside is that it might make things hard for some cases. But I'm not sure how typical the per-AP or per-link type credential policies are. Do you have any information on that? Compared to the SSID and other information presented by the authenticator? From aboba@internaut.com Thu Jul 10 18:16:29 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 10 Jul 2003 10:16:29 -0700 (PDT) Subject: [eap] Proposed Resolution to Issue 154: Identity Response Mismatch Message-ID: The text of Issue 154 (and subsequent discussion) is included below. The proposed resolution is as follows: In Section 7.3, add the following paragraph: "It is possible for the identity in the identity response to be different from the identity authenticated by the EAP method. This may be intentional in the case of identity privacy. An EAP method SHOULD use the authenticated identity when making access control decisions." ------------------------------------------------------------------- Issue 154: Identity Response Mismatch Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: July 6, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-July/001418.html Document: EAP-04 Comment type: T Priority: 1 Section: 7.3 Rationale/Explanation of issue: I could not find a place in the draft where it covers the possiblity that the Identity response differs from the identity that is authenticated by the EAP method. Requested change: Perhaps the following should be added to the security considerations section: "It is possible for the identity in the identity response to be different from the identity authenticated by the EAP method. This may be intentional in the case of identity privacy. An EAP method SHOULD use the authenticated identity when making access control decisions. A [Jari Arkko] Fine so far... method MAY allow the use of the identity in the identity response if it is an authorized alias for the authenticated identity." [Jari Arkko] This part I don't understand. Are you still talking about the case where the id resp != some method internal identity? [Joe Salowey] Yes, It should probably say "If the identity in the Identity Response is an authorized alias of the authenticated identity the alias MAY use this identity for making access control decisions." Alternatively we could just say that the authenticated identity always takes precedence over the identity in the identity response when they differ. From jesse.walker@intel.com Thu Jul 10 21:56:02 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Thu, 10 Jul 2003 13:56:02 -0700 Subject: [eap] RE: EAP key naming Message-ID: Pasi, Nice analysis. I have some comments at the end. > I'm not sure if Russ actually intended his slides to be=20 > used as a "checklist" (especially since it's not at all > obvious what some of the items mean), but at least > the list seems bring up some rather interesting=20 > problems--here are my 0.02 euros on this :-) >=20 > I haven't completely grasped this "key naming" issue yet, > but I think it might be related to the "authenticate > all parties" item? Authentication between peer<->server > and AP<->server is well understood (some EAP method, > and e.g. TLS when using Diameter), but the "third leg" > between peer and AP seems to be quite different. >=20 > So, I was thinking that actually the "key naming" tries to > accomplish this, by authenticating the MAC addresses of the=20 > peer and AP. (The four-way handshake includes the MAC > addresses, but it does not authenticate them--since both=20 > parties can freely put whatever they want as their own address). >=20 >=20 >=20 > Suppose for a moment that the peer knows the MAC address of=20 > the AP it wants to connect to. Currently any other AP can > simply change its MAC address to this; the EAP conversation will=20 > work just fine, and this rogue AP will get the MSK from the server. > (Note that this basically requires that an authorized AP is > compromised or turns evil--it can't be done by a total > outsider). >=20 > Jesse Walker's idea of including the AP's MAC address inside the > EAP method (as done in EAP-Archie) seems to prevent this _if_ > the server can authenticate the AP's MAC when delivering the=20 > key (just comparing it with Called-Station-Id doesn't work).=20 > If APs use e.g. Diameter-over-TLS to talk to the server,=20 > the AP's MAC address could be maybe included in the=20 > certificate or something. >=20 > When the AP now proves that it knows the PMK in the four-way > handshake, the peer knows that it is really talking to AP > with the desired MAC address. So, it would be correct to > say that the AP has authenticated this identity to the peer=20 > (with help from a third party trusted by both of them). >=20 >=20 >=20 > This doesn't give us authentication of the peer MAC address to > the AP yet. A valid peer can change the WLAN card's address > to VICTIM_MAC, authenticate as usual, and after a while, the AP=20 > starts to use a key known to the attacker for encrypting traffic=20 > to VICTIM_MAC. >=20 > Including the peer's MAC address inside the EAP method, and > comparing this with Calling-Station-Id doesn't help here. The > server would need to know which user has which MAC address. > This might be difficult (it could be included in a certificate, > for instance, but I don't think this is likely?). >=20 > I think that one difficulty here is that the identities that are > currently authenticated are not the ones used to select which > key to use (and "route" the packets). It seems that there might > a similar issue present at one layer above; maybe this would > give some insight? (or then again, maybe not--I'm not > quite sure on this) >=20 > Suppose that a client with IP 1.2.3.4 uses IKE to connect to > some other host, and authenticates itself with a certificate > (this might involve some back-end authentication server, but > it's not visible to the client). If the client authenticates=20 > as "bob@example.com", the responder will certainly _not_ set up=20 > an SA that says "encrypt all traffic to 1.2.3.4 with this key". =20 > It will require either a local database that says "bob@example.com > has IP 1.2.3.4" or a certificate that contains 1.2.3.4 (an > iPAddress subjectAltName). Or, in the case of "road warrior=20 > gateway", it assigns a new IP address to the client (often=20 > needed for sane routing anyway). >=20 >=20 >=20 > Thus, to meet all of Russ's requirements, we would need to > authenticate the MAC addresses or assign new MAC addresses > after authentication? Oh , this does not look > good... at least there'll be an interesting discussion > in Vienna :-)=20 >=20 > (Unfortunately I'll miss that one, since it's on Thursday... > but if somebody's interested in a having "bar BOF" about=20 > this Saturday..Tuesday, count me in!) The requirements for a solution are the EAP Server must attest to the = proper binding of the MSK to both the EAP Peer and the NAS. This cannot = be solved exclusively within EAP, because EAP does not require the NAS = to understand any of the contents of the messages exchanged. The EAP server needs to craft messages Server -> NAS: Attest to the binding Server -> Peer: Attest to the binding where Peer-ID and NAS-ID are identifiers from the "right" address family = (802 MAC addresses in your example), and MSK-ID identifies the MSK = distributed to the NAS to protect this session. Attest means = that the Server is guaranteeing that this binding is correct, so Peer-ID = and NAS-ID can be used as identifiers to mutually authenticate using the = MSK. In this protocol, the EAP Server would use the MK (or some key derived = from the MK) it established with the EAP Peer to form a MIC of the = information returned. The EAP Server would presumably establish an = analogous MK with the NAS when the two establish contact after = rebooting, and the EAP Server would use this MK (or rather an = authentication and a key encryption key derived from it) to protect the = binding and to distribute the MSK to the NAS. This kind of mechansim solves the problem you discuss; it could be used, = for example, to turn the 802.11i 4-way handshake into a genuine = authentication instead of just key proof-of-possession. In this case, = the mobile STA is the EAP Peer, and it "authenticates" the identity = NAS-ID, which is the AP's BSSID; similarly, the AP becomes the NAS, and = it "authenticates" the STA's MAC address, which is the right Peer-ID = value. The reason why this is authentication instead of mere key = confirmation is the EAP Server has authoritatively told both the AP and = the mobile STA that the BSSID and STA MAC address are the entity = identifiers bound to the MSK. Presumably the new message to the Peer would be in an EAP message, and = this EAP message would be forwarded to the NAS in the same message that = returns the attestation to the NAS (e.g., as a new TLV in the same = RADIUS Access-Challenge returning the new EAP message). There are at least two ways by which the EAP Server could obtain the = correct binding information. 1. For each device, the EAP server can maintain the pairing in its database. This is not very flexible and requires = configuration, but it would certainly be the simplest solution in terms = of protocol. 2. We could invent an Otway-Rees or 3PKD style protocol by which the EAP = Peer and the NAS report whom they think they are conversing with: 1. Peer -> NAS: EAP-Response(Peer NAI, NAS NAI, Peer-ID, NAS-ID) 2. NAS -> Server: EAP-Response(Peer NAI, NAS NAI, Peer-ID, NAS-ID), Peer NAI, NAS NAI, Peer-ID, NAS-ID ... Server checks: EAP-Response IDs match those from NAS' part of the = message 3. Server -> NAS: EAP-Request(Peer-ID, NAS-ID, MSK-ID, MIC1), Peer-ID, NAS-ID, MSK-ID, E-MSK, MIC2 NAS checks: Peer-ID and NAS-ID received from Server were in request MIC2 is valid 4. NAS -> Peer: EAP-Request(Peer-ID, NAS-ID, MSK-ID, MIC1) Peer checks: Peer-ID in EAP-Request match identifers in EAP-Response MIC1 is valid Here MIC1 is a message authentication code protecting Peer-ID, NAS-ID, = and MSK-ID, computed using MK (or some key derived from it). MIC2 is a = message authentication code protecting Peer-ID, NAS-ID, MSK-ID, and = E-MSK. E-MSK denotes the encrypted MSK. We would need to identify the = key used to protect the parameters meant for the NAS in message 3. This approach permits the parties to specify the identifiers they happen = to be using during this instance of the EAP method, so does not require = as much configuration and is more flexible. This does not work unless = both the NAS and the Peer check that the EAP Server attests to the = values they suggested, and the EAP Server checks that both the NAS and = the Peer have requested the same identifiers. A full protocol definition obviously requires further refinement (e.g., = binding the EAP messages between the Server and Peer to the AAA messages = between the NAS and Server), but I think there is enough here to = indicate that a solution ought to be with reach. If we agreed on such an = approach, much of it is outside the scope of EAP; we might have to = define a chained EAP binding procedure as Joe has suggested, and we = would need to define additional messages in, e.g., the AAA EAP = application; the EAP key document might be an appropriate place to = document how all the pieces get glued together. -- Jesse From josh_mendel@infonet.com Fri Jul 11 09:01:05 2003 From: josh_mendel@infonet.com (josh_mendel@infonet.com) Date: Fri, 11 Jul 2003 01:01:05 -0700 Subject: [eap] Josh Mendel/HQ/ISC is out of the office. Message-ID: I will be out of the office starting 07/10/2003 and will not return until 07/15/2003. For RADIUS support please email to AuthEngr@infonet.com. From Pasi.Eronen@nokia.com Fri Jul 11 14:33:53 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 11 Jul 2003 16:33:53 +0300 Subject: [eap] RE: EAP key naming Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB75@esebe023.ntc.nokia.com> Jesse, Thanks for your response! I'm beginning to get the feeling that we have actually several different problems we are trying to solve, and maybe not all of them can be solved easily... > The requirements for a solution are the EAP Server must=20 > attest to the proper binding of the MSK to both the EAP Peer=20 > and the NAS.=20 Yes, but I think this is not the same as binding the MSK to=20 their MAC addresses!=20 In both of the attacks in my previous e-mail, both the peer and the access point will have the same (peer_mac,ap_mac,msk) triplet. The problem was that this triplet was in "wrong" access point (in the first case; the AP was malicious) or "wrong" peer node (in the second case; the peer was malicious). This happens because a compromised AP can freely choose the value=20 of ap_mac (including a value "belonging" to someone else), and=20 likewise the peer can choose peer_mac freely. > 1. For each device, the EAP server can maintain the pairing NAI, Device-ID> in its database. This is not very flexible and > requires configuration, but it would certainly be the simplest > solution in terms of protocol. I agree, this would solve the problem presented above, but it's probably not feasible in terms of configuration. > 2. We could invent an Otway-Rees or 3PKD style protocol by which=20 > the EAP Peer and the NAS report whom they think they are=20 > conversing with: >=20 > 1. Peer -> NAS: EAP-Response(Peer NAI, NAS NAI, Peer-ID, NAS-ID) > 2. NAS -> Server: EAP-Response(Peer NAI, NAS NAI, Peer-ID, NAS-ID), > Peer NAI, NAS NAI, Peer-ID, NAS-ID > ... > Server checks: EAP-Response IDs match those from NAS' part of the=20 > message > > 3. Server -> NAS: EAP-Request(Peer-ID, NAS-ID, MSK-ID, MIC1), > Peer-ID, NAS-ID, MSK-ID, E-MSK, MIC2 > > NAS checks: Peer-ID and NAS-ID received from Server were in request > MIC2 is valid > > 4. NAS -> Peer: EAP-Request(Peer-ID, NAS-ID, MSK-ID, MIC1) > Peer checks: Peer-ID in EAP-Request match identifers in EAP-Response > MIC1 is valid I think this protocol is roughly what the current EAP-Archie protocol combined with Diameter-EAP-over-TLS (or RADIUS-over-IPsec) does already? For instance, Peer-ID and NAS-ID are transmitted in=20 RADIUS/Diameter Calling-Station-Id and Called-Station-Id attributes,=20 and so on. The only thing missing from the current protocol is the NAS NAI (which is sort of strange anyway; NAIs identify users, not devices--and how the peer knows what the NAS NAI is, when sending the first message?) But as you pointed out, the peer and NAS can freely choose the values of Peer-ID and NAS-ID--so this protocol does not solve the "problem" presented above. The protocol does "make sense", though--so maybe there is more than one problem to be solved, and this solves something else? (I need some time to think this through--especially the word "binding" seems to be quite dangerous, since it's sometimes difficult to see what attacks would be possible if such=20 "binding" was not present). Best regards, Pasi From Pasi.Eronen@nokia.com Fri Jul 11 15:21:52 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 11 Jul 2003 17:21:52 +0300 Subject: [eap] RE: EAP key naming Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB76@esebe023.ntc.nokia.com> Hi Bernard, Thanks for your comments; see my replies inline. > I think of the "third leg" of the exchange as having many of > the same properties as IKEv1 phase 2 -- it provides secure > negotiation of the security parameters, including ciphersuite > and modes (if relevant), provides freshness for transient > session keys, proves possession of the keying material derived > in Phase 1 (EAP), handles key activation/deletion/re-key. =20 > For this to work there has to be a binding between the Phase=20 > 2 SA and the Phase 1 (EAP) SA. There are many similarities, but the "third leg" is not exactly IKEv1 phase 2 either... in IKEv1, there are only two parties,=20 and many of the complexity here comes from having three (or=20 more) parties, and having to deal with the case where some trusted parties might be malicious. (If we can assume that all trusted APs and home servers are indeed trustworthy, then this whole issue becomes rather trivial--we need to consider only the interface between the peer and "the network".) > > If APs use e.g. Diameter-over-TLS to talk to the server, > > the AP's MAC address could be maybe included in the > > certificate or something. >=20 > I think this doesn't help much because the AAA server can check=20 > the Called-Station-Id anyway, and the threat you outlined is=20 > about the NAS lying to the EAP peer. Well, presumably the AAA server would then have a database of=20 pairs, and having this information in the certificate accomplish the same goal.. > > When the AP now proves that it knows the PMK in the four-way > > handshake, the peer knows that it is really talking to AP > > with the desired MAC address. >=20 > Not really. The AP can tell the AAA server and EAP peer different=20 > MAC addresses, and the 4-way handshake works just fine. It can in most existing EAP methods, but not if the peer includes the NAS MAC address inside the EAP messages=20 (like EAP-Archie does), right? > > Including the peer's MAC address inside the EAP method, and > > comparing this with Calling-Station-Id doesn't help here. The > > server would need to know which user has which MAC address. > > This might be difficult (it could be included in a certificate, > > for instance, but I don't think this is likely?). >=20 > I don't think there's anything that can prevent an EAP peer=20 > from changing their L2 address. Similarly, there's nothing that=20 > prevents an IKE Initiator from stealing another hosts's IP address,=20 > and initiating an IKE exchange using it. You're quite right in that nothing prevents someone from=20 stealing an IP address and initiating an IKE exchange (and from successfully completing phase 1). But the attacker still can't=20 set up a "phase 2" SA for that stolen IP address (unless the=20 responder's IKE policy is seriously misconfigured--you seem to=20 suggest below that this would actually be a common configuration?) > Actually, I think the identities are different during each=20 > phase. In EAP (Phase 1), the relevant identities are those of the=20 > EAP peer and EAP server. Since EAP SAs aren't bound to L2 addresses,=20 > those aren't relevant.=20 Actually, in EAP-Archie, the EAP SA is bound to the L2 addresses--but it isn't a problem, because the EAP SA isn't long-lived (it's destroyed immediately after sending the EAP Success message). (BTW, what does "naming" the EAP SA accomplish for methods that=20 don't store any state for "fast reconnect" or similar?) > Given all of this, I'm not sure exactly what it means to=20 > "authenticate" the tuple.=20 > Are we trying to prove that an EAP peer or NAS has the right to that=20 > MAC address? This would require some sort of certification from an=20 > authority (the IEEE), which seems somewhat impractical. Plus one of=20 > the major advantages of EAP is that the entities do *not* need to=20 > identified via their L2 addresses, which is an administrative = headache. Yes, I was sort of trying to prove the right to that MAC address. In this case it does not require certificates from IEEE, though: certificates from the home server (trusted by both users and NASes) is enough. I agree that this is not practical from administrative point of view, at least for users (it might be almost possible for NASes). > > Suppose that a client with IP 1.2.3.4 uses IKE to connect to > > some other host, and authenticates itself with a certificate > > (this might involve some back-end authentication server, but > > it's not visible to the client). If the client authenticates > > as "bob@example.com", the responder will certainly _not_ set up > > an SA that says "encrypt all traffic to 1.2.3.4 with this key". >=20 > Actually, quite a few implementations will do this. Hmm, do they? In what kind of circumstances would this make sense?=20 (I'm not exactly an IPsec expert...) =20 > > It will require either a local database that says "bob@example.com > > has IP 1.2.3.4" or a certificate that contains 1.2.3.4 (an > > iPAddress subjectAltName). >=20 > In practice, the IPAddress is not placed in the subjectAltName;=20 > that is where bob@example.com goes. This issue does arise more=20 > seriously in MIPv6 where there is a need to bind the Home Address=20 > to the IKE Identity-Payload. Well, the certificate might have two subjectAltNames, one for IPAddress and another for bob@example.com. Or can IP addresses appear in the Subject field (or is it always a Distinguished Name)? Best regards, Pasi From rgm-sec@htt-consult.com Fri Jul 11 16:45:04 2003 From: rgm-sec@htt-consult.com (Robert Moskowitz) Date: Fri, 11 Jul 2003 11:45:04 -0400 Subject: [eap] EAP key naming In-Reply-To: References: <5.1.0.14.2.20030710110808.00aa4000@localhost> <5.1.0.14.2.20030710110808.00aa4000@localhost> Message-ID: <5.1.0.14.2.20030711112810.02c4fba8@localhost> At 09:51 AM 7/10/2003 -0700, Bernard Aboba wrote: > > Here is what I am working up as the key name: > > > > KeyID = Truncate-128(SHA1(NAI || EAP Method Type || Key || > > Called-Station-Id || Calling-Station-Id || "The name is the game")) > > > > And for 'Key' you can substitute: > > > > MK > > MSK > > EMSK > > PMK > >I don't think that this formula works. Your. right. It only works for the PMK. A little too fast with the fingers there. >As Joe noted, the MK is named by the EAP method, and >since it is purely between the EAP peer and EAP server, it can have no >dependence on Called-Station-Id, Calling-Station-Id and least of all the >MK itself, which can't be exported. EAP methods have their own MK names >(in TLS this is the session-id). It can be based on the MK, as in a hash, it is not being 'exported', no mor that creating the MSK. Not the Called-Station-Id, granted. But I argue that the peer is on a station and the MK is only for the peer on that station. So I get: MKID = Truncate-128(SHA1(NAI || EAP Method Type || MK || Calling-Station-Id || "The Master name is the game")) >As Jesse noted, the EAP SA is uniquely named by the combination of EAP >peer NAI, >the EAP server name, and the nonces. The called-station-id and >calling-station-id do not play a role. Nonces? What Nonces? Do all EAP methods have nonces? EAP server name is nice, but does the peer 'know' it? The closest is the domain part of the NAI. Again, I was wrong on the called-Station-id, the MSK and EMSK are independent of the peer's connection to the network. It would be valuable to include the network name in here, but the PANA people seem to think that SAs will be portable across billing domains (I don't), and anyway there is no direct variable to get the network name into the process (in 802.11, the SSID is appended to the called-station-id). So I get: [E]MSKID = Truncate-128(SHA1(NAI || EAP Method Type || [E]MSK || Calling-Station-Id || "The Session name is the game")) >As Jesse also noted, the MSK is named by the EAP SA name + a NAS name (for >which the Called-Station-Id may be used as a surrogate). The >Calling-Station-Id does not play a part, and neither does the actual MSK >itself. The MSK can't have the NAS name in it, as that would limit the portablity of it across NASs for roaming. Though that may not really matter so much. >The EMSK has a name of the EAP SA name + a static string. So the formula >looks off there too. Even though the method may not have the information about its environment, that information can readily be made available to it by making called-station-id and calling-station-id global variables. As I noted, called-station-id may not apply, other than to pick off the network name. Naming SAs in this manner is very valuable. Of course it is not necessary, as these values will be variables in the SA anyway. >It would seem to me that the PMK has no unique name of its own, just the >name of its parent + potentially an additional string. So if the PMK is >derived from the MSK, then it has a name of the MSK name + "lower 32 bits" >or something like that, whereas if it is derived from the EMSK, it has a >name of the EMSK name + a static string. Again. a name by any name. these values are available at the time of name construction. they are part of the PMK. THere is no reason NOT to include them. Given the way hash functions supposedly work, it would seem that including the addional bytes don't hurt and should help. PMKID = Truncate-128(SHA1(NAI || EAP Method Type || PMK || Called-Station-Id || Calling-Station-Id || "The name is the game")) Robert Moskowitz ICSAlabs/A Division of TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From jesse.walker@intel.com Fri Jul 11 16:57:11 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Fri, 11 Jul 2003 08:57:11 -0700 Subject: [eap] RE: EAP key naming Message-ID: Pasi, > > The requirements for a solution are the EAP Server must=20 > > attest to the proper binding of the MSK to both the EAP Peer=20 > > and the NAS.=20 >=20 > Yes, but I think this is not the same as binding the MSK to=20 > their MAC addresses!=20 >=20 > In both of the attacks in my previous e-mail, both the peer and > the access point will have the same (peer_mac,ap_mac,msk) > triplet. The problem was that this triplet was in "wrong" access > point (in the first case; the AP was malicious) or "wrong" peer > node (in the second case; the peer was malicious). I am not sure the assurance you want is entirely feasible, unless the = EAP server knows all of the aliases that will be used by all of the = systems, both EAP Peers and NASes, and also knows a priori which alias = will map to which NAI. There seem to be two ways to think about this problem. Either this = information can be configured, or each system, when it makes initial = contact with the EAP server, registers the aliases it intends to use, = and the server maintaining the registration database that the EAP Server = consults is responsible for checking that none of the aliases are = already registered to another system. In cases like MAC addresses, the = latter is normally a benign requirement, because a MAC address ought not = change in ordinary operation. In the case of a more dynamic alias, such = as an IP address, it is not clear how to make this work. -- Jesse From Pasi.Eronen@nokia.com Fri Jul 11 17:36:56 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 11 Jul 2003 19:36:56 +0300 Subject: [eap] RE: EAP key naming Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222C3@esebe023.ntc.nokia.com> Jesse Walker wrote: > > Yes, but I think this is not the same as binding the MSK to=20 > > their MAC addresses!=20 > >=20 > > In both of the attacks in my previous e-mail, both the peer and > > the access point will have the same (peer_mac,ap_mac,msk) > > triplet. The problem was that this triplet was in "wrong" access > > point (in the first case; the AP was malicious) or "wrong" peer > > node (in the second case; the peer was malicious). >=20 > I am not sure the assurance you want is entirely feasible,=20 > unless the EAP server knows all of the aliases that will be=20 > used by all of the systems, both EAP Peers and NASes, and=20 > also knows a priori which alias will map to which NAI. I think you're probably right in that this might not be=20 feasible--but this might also mean that satisfying all the=20 requirements of "ideal and perfect key exchange protocol" in=20 Russ's slides is not feasible! And I have a gut feeling that=20 the effects of this are not limited to just one of the=20 items listed there, but have wider consequences... If this is indeed the case, I think we should work hard to identify=20 what exactly is feasible and what is not--and hopefully not try to=20 convince ourselves that the requirements are met (I fear this might=20 happen if we start adding some protocol features that are=20 so complex that we can't really tell if they work or not :-) (I'm not saying that the "key names", "EAP SA names" and "bindings" discussed here recently don't work--just that it=20 requires more work to see what they actually achieve. =20 And if it would turn out that, e.g., having "key names"=20 does not prevent any attacks or enable any new features,=20 well, then we at least understand the system much better.) > There seem to be two ways to think about this problem. Either=20 > this information can be configured, or each system, when it=20 > makes initial contact with the EAP server, registers the=20 > aliases it intends to use, and the server maintaining the=20 > registration database that the EAP Server consults is=20 > responsible for checking that none of the aliases are already=20 > registered to another system. In cases like MAC addresses,=20 > the latter is normally a benign requirement, because a MAC=20 > address ought not change in ordinary operation. In the case=20 > of a more dynamic alias, such as an IP address, it is not=20 > clear how to make this work. Hmm, requiring that the EAP server knows the MAC addresses of all NASes might be almost feasible, but certainly this does not apply to peers. There is one possible way this might=20 work (similar to the one used in "road warrior" IPsec gateways):=20 assign a new MAC address after authentication. But I guess this would require non-trivial changes to 802.11... (BTW, this could also help in solving some other problems with=20 globally unique and permanent MAC addresses: they have privacy problems, and help attackers in targeting a particular user's traffic. Henry Haverinen said that something like this=20 had actually been suggested at IEEE years ago, but rejected...) -Pasi From jari.arkko@piuha.net Sat Jul 12 23:17:27 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 13 Jul 2003 01:17:27 +0300 Subject: [eap] EAP key naming In-Reply-To: References: Message-ID: <3F1088F7.9040207@piuha.net> Walker, Jesse wrote: > It may be worth devoting a few words to the effect that the requirements are system requirements. Some of them apply to EAP methods, some to the backend protocols like RADIUS or DIAMETER, some to system design, etc. It is not clear to me that any of them apply to EAP per se. Yes. > This is not an EAP issue; it relates to the back-end. The key draft can dismiss it as out of scope and point to some other document, e.g., a AAA keying document. ... > Again, this is not an EAP issue, and I think it fair if the EAP key naming draft punts on it. I agree that some of the requirements that Bernard listed are not EAP issues. However, the requirements put forward from the IESG are clearly system requirements, and attempts to ensure that we understand the properties of the system as a whole. I think we need to document these issues in the keying draft, even if parts of the actual realization of the requirements may fall on AAA or link layers. --Jari From jari.arkko@piuha.net Sun Jul 13 06:26:59 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 13 Jul 2003 08:26:59 +0300 Subject: [eap] comments on the keying draft Message-ID: <3F10EDA3.4010308@piuha.net> Bernard, We've take a big step forward with the new version of the keying draft, and you summary note to the list. Thanks! I'm quite happy with the document, though of course you mentioned some of the question marks in your note. I also have a few comments: 1) Section 1.3, AN-Token: AAA-EAP-02 lacks the lifetime etc AVPs. 2) A related but general question. Assuming current RFC 2548 model and RADIUS vs. the discussion about key naming and DIAMETER keying work -- will the latter be backwards compatible with the former? 3) Section 2.1.2, "EAP methods MUST support creation and naming of EAP (Phase 1) Security Associations". All methods or just key generating methods need to support naming? Come to think of it, is there a security association if there is no keys? 4) Section 4.2, Security Services. It might be useful to point out here that the AN-Token protection defined later will require confidentiality. It looked odd to me to say confidentiality is optional. In fact, I have some trouble understanding the difference between the three first three items in this section vs. the AN-Token protection. Doesn't AN-Token protection cover everything that we need? 5) Section 4.2, Mutual Authentication. Hmm... does RADIUS with proxies support mutual authentication? 6) Section 4.2, Forgery Protection. The Diameter scheme should be listed here as well. 7) Section 4.5 "absent the TSK derivation step, EAP mutual authentication only proves that the authenticator is trusted by the backend authentication server; the identity of the authenticator is not confirmed". I wonder if "the authenticator" is shown to be trusted. I suspect that its *some* authenticator that must be trusted, but not necessarily the one that the peer is talking to. A rogue authenticator could channel the EAP protocol run to a real, trusted authenticator and act as a man-in-the-middle peer for him. 8) Section 4.5, "data object security SHOULD be used..." Are we back into requiring Diameter CMS? Is that really necessary, even if we avoid proxies? 9) Section 5.2, "impersonation detection requires DNS A/AAAA and PTR RRs to be properly configured". Hmm.... I wonder if we can use AltSubjName vs. claimed domain name checks as in https? 10) Section 5.3, "where PFS is implemented, compromise of the MSK does enable" -- a missing "not" before "enable"? 11) Section 5.3, mitigation by redirects. Still, its the proxy that controls the redirection. If we assume proxies are bad, can't proxy.foo.com redirect you to proxy2.foo.com instead of home.bar.com? --Jari From jari.arkko@piuha.net Sun Jul 13 10:38:55 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 13 Jul 2003 12:38:55 +0300 Subject: [eap] presentations for IETF-57 Message-ID: <3F1128AF.3090201@piuha.net> If you are going to have a presentation in the IETF-57 at the EAP WG, please send your slides to Bernard and myself. Thanks, --Jari From aboba@internaut.com Mon Jul 14 09:06:25 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 14 Jul 2003 01:06:25 -0700 (PDT) Subject: [eap] Slides for IETF 57 Message-ID: If you have slides for IETF 57 and haven't already done so, please send these to me. From yohba@tari.toshiba.com Mon Jul 14 15:24:52 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Mon, 14 Jul 2003 07:24:52 -0700 Subject: [eap] eap state machine implementation Message-ID: <20030714142452.GA1401@steelhead> I have made my EAP state machine implementation (written in C++) be freely available under LGPL license. The state machine implementation is based on the latest version of the state machine draft (meaning that it will automatically be RFC2284bis-conformant). I hope this helps to address implementation-related isssues (if any). The implementation includes: - Peer implementation - Authenticator implementation (both backend and non-backend) - Passthrough implementation - C++ API - Sample program The source code works on Linux (it will be ported to Windows as well). Note that the status of the code is still pre-alpha and I'll continue to work on it. The source code can be obtained from Open Diameter CVS repository in sourceforge in the following way: cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/diameter login (Enter Return key when asked password.) cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/diameter co c_server/libeap The work is done in Open Diameter project in sourceforge (http://www.sourceforge.net/projects/diameter). Regards, Yoshihiro Ohba From jrv@umich.edu Mon Jul 14 15:36:03 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 14 Jul 2003 10:36:03 -0400 Subject: [eap] Proposed Resolution to Issue 149: Reject In-Reply-To: References: Message-ID: <821498.1058178963@[81.160.245.11]> I continue to think people will want to use the same id from different locations. If they do then different authentication methods may be accepted at different locations, with different permissions. I don't think we should require different ids for different locations even if the locations require different authentications. I don't agree with dropping this without conversation. John --On Thursday, July 10, 2003 10:12 AM -0700 Bernard Aboba wrote: > The text of Issue 149 (and subsequent discussion) is included below. Based > on discussion it would appear that there is no consensus for the change. > The recommendation is that the change advocated in Issue 149 be rejected. > > ----------------------------------------------------- > Issue 149: Peer Policy > Submitter name: John Vollbrecht > Submitter email address: jrv@umich.edu > Date first submitted: June 16, 2003 > Reference: > Document: EAP-04 > Comment type: T > Priority: 2 > Section: 7.8 Paragraph 2 > Rationale/Explanation of issue: > > Peers may include policy, especially when > connecting subnets. Additionally the same identity may have different > permissions at different Access Points. > > Requested change: In paragraph 2 make the following 2 changes noted in > quotes below - > > Within or associated with each authenticator, it is not anticipated that a > particular named peer will support a choice of methods "for a given > connection". This would make the peer vulnerable to attacks that negotiate > the least secure method from among a set. Instead, for each named peer > there SHOULD be an indication of exactly one method used to authenticate > that peer name "at an access point". If a peer needs to make use of > different authentication methods under different circumstances, then > distinct identities SHOULD be employed, each of which identifies exactly > one authentication method. > > [Jari Arkko] > Hmm... I don't have a warm and fuzzy feeling about this. > What if the attacker spoofs the name of the access point > to get the bidding down attack started? > > [JRV] > This is where policy must be involved. if the attacker AP bids up, the > authentication should go up. If the attacker AP bids down, the > authentication and also the rights should go down. > > Additional info may be involved, depending whether the AP is wireless or > wired. Wireless may require Keys and a different authentication method > than wired. > > I think the idea that there should be only one id for each authentication > method is too restrictive. The same user should be able to get on in > different places, with different rights, using different authentication > methods. The user could have different ids for each authentication method > and try to match the id to the access type, geographic location, etc. - > but this seems unlikely in practice. > > [Jari Arkko] > I can see your argument. > > But I'm still worried that without a specific model > for what policies are possible, there'll be bidding down > problems. For instance, the AP identity does not appear to be > a good source for the policy, but link type (wired/wireless) > might be slightly better. > > So, I'd rather err on the safe side and not allow such > flexibility. The downside is that it might make things > hard for some cases. But I'm not sure how typical the > per-AP or per-link type credential policies are. Do > you have any information on that? Compared to the SSID > and other information presented by the authenticator? > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From keith@rucus.ru.ac.za Mon Jul 14 17:41:30 2003 From: keith@rucus.ru.ac.za (Keith Burdis) Date: Mon, 14 Jul 2003 17:41:30 +0100 Subject: [eap] EAP SRP method Message-ID: <20030714164130.GA2020@mail.spheniscidae.co.uk> Hi there Raif Naffah and I have been working on an SRP SASL mechanism for a while now. After publishing the most recent draft we were asked by Sam Hartman to specify a compatible SRP GSS-API specification so that there would be no duplication of effort - both in terms of review and implementation time. In modifying the draft to specify both an SASL and GSS-API mechanism we realised that the majority of the specification was authentication framework agnostic. This made is relatively easy to specify how it could be used with EAP as well. However, neither Raif or I are EAP experts, so we are unsure whether or not what we have specified is sufficient. We have attempted to follow all of the requirements set out in rfc2284bis, in particular the Security Claims, but we need people who really know EAP to review this. The (now misnamed) draft is: draft-burdis-cat-srp-sasl-08.txt Thanks. - Keith PS: I am in Vienna and would be happy to have a face-to-face discussion with anyone about this. From Hubert.Ertl@de.gi-de.com Tue Jul 15 18:03:10 2003 From: Hubert.Ertl@de.gi-de.com (Hubert.Ertl@de.gi-de.com) Date: Tue, 15 Jul 2003 19:03:10 +0200 Subject: [eap] Hubert Ertl/GDM/GuD is out of the office. Message-ID: Ich werde ab 12.07.2003 nicht im B=FCro sein. Ich kehre zur=FCck am 20.07.2003. I will read my email during my absence and will respond to your messag= e when I return on July 21th.= From wouter@raaktechnologies.com Wed Jul 16 17:05:38 2003 From: wouter@raaktechnologies.com (Wouter Habraken) Date: Wed, 16 Jul 2003 11:05:38 -0500 Subject: [eap] WLAN-SIM Spec Announcements Message-ID: <004f01c34bb4$23a072a0$6501a8c0@www.raak2.local> Today the WLAN Smart Card Consortium (WLAN-SCC) announced the first draft version of the WLAN-SIM specification for public comment. This specification is expected to be supported by all the major SIM smart card vendors, and enables support for several EAP-SIM functions directly on the smart card, including identity management, random number generation and the EAP-SIM challenge and re-authentication functions. I would encourage anyone interested in EAP and SIM authentication to review the spec. We would very much appreciate you comments and feedback. Spec (150kb pdf): http://www.wlansmartcard.org/specs/WLAN-SIM_V01.PDF (PR: http://www.wlansmartcard.org/html/news.html) This spec is the first of several planned by the WLAN-SCC. Others will provide support for additional authentication methods (see the urien-eap-smartcard IETF draft), configuration management, QOS and VoIP. Cheers, Wouter Habraken Raak Technologies whabraken@raaktechnologies.com From jesse.walker@intel.com Thu Jul 17 12:57:38 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Thu, 17 Jul 2003 04:57:38 -0700 Subject: [eap] Rekeying reference Message-ID: A good paper that talks about the issues we have been considering = regarding key derivation is http://www-cse.ucsd.edu/users/mihir/papers/rekey.html The authors discuss particular techniques, but these correspond exactly = to some key derivation models we have discussed, and lends hope that = other similar derivation methods can receive a similar treatment. (As = with all theoretical work, the results depend on the assumptions, but = the assumptions appear benign in our environment.) -- Jesse From florent.bersani@francetelecom.com Thu Jul 17 14:07:51 2003 From: florent.bersani@francetelecom.com (Florent Bersani) Date: Thu, 17 Jul 2003 15:07:51 +0200 Subject: [eap] State machine 04 : Issue with bidirectionnal authentication and demultiplexing ? Message-ID: <000b01c34c64$6e002650$cf8ca051@pprofesseur> Hi, I think I have an issue with the current state machine : 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) ? Florent From Pasi.Eronen@nokia.com Thu Jul 17 14:39:51 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Thu, 17 Jul 2003 16:39:51 +0300 Subject: [eap] State machine 04 : Issue with bidirectionnal authentication and demultiplexing ? Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222C4@esebe023.ntc.nokia.com> Florent Bersani wrote: > Hi, >=20 > I think I have an issue with the current state machine : >=20 > When two peers simultaneously perform EAP authentications=20 > (that is to say A acts as a peer in dialog #1 with B which=20 > acts as an authenticator and, at the same time, A acts as=20 > an authenticator in dialog #2 with B which acts as > a peer) the EAP dialogs have to get demultiplexed: this can=20 > easily be done according to the EAP code field (responses go=20 > to the authenticator and other codes - requests, success and=20 > failure - go to the peer). >=20 > The question is : who does this demultiplexing ? Should it be=20 > the lower layer (which then would have to read and understand=20 > the EAP layer) or the EAP state machine (which then should be=20 > modified, I think) ? I think the demultiplexing should be done by the lower layer. The state machine doc should probably be updated to say this, and describe how the demultiplexing is done (it=20 should work the way you proposed). This way we don't have to unnecessarily complicate the state=20 machines with this detail (bidirectional authentication with two conversations is anyway an obsolete feature that's=20 probably not used anywhere, right?). Best regards, Pasi From porcher@funk.com Thu Jul 17 16:14:16 2003 From: porcher@funk.com (Tom Porcher) Date: Thu, 17 Jul 2003 11:14:16 -0400 Subject: [eap] WLAN-SIM Spec Announcements In-Reply-To: <004f01c34bb4$23a072a0$6501a8c0@www.raak2.local> References: <004f01c34bb4$23a072a0$6501a8c0@www.raak2.local> Message-ID: <3F16BD48.9030700@funk.com> This is a multi-part message in MIME format. --------------060308040302010401050906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Wouter, Thank you for publishing this specification. I have been implementing EAP/SIM for Funk Software and I have a number of comments. Is there a forum for discussing this specification? The EAP mailing-list is probably not the right venue for further discussions of this specific a topic. 1. General - use of numbers - Some of the numbers appear to be hexadecimal, while others appear to be decimal. I would recommend explictly stating that all numbers are decimal unless indicated otherwise. Those numbers in hexadecimal should be noted as such. 2. 2 References - Can you tell me how to get [3] and [4]? For [3], the spec number TS 102.221 is out of the range of available specifications from 3GPP. For [4], there is no information on the publisher. 3. 5.2 PIN Management - If this is implemented on a SmartCard that also supports "traditional" GSM SIM operations, is the PIN the same as the GSM PIN? 4. 5.3 Get-Preferred-Identity - this "may" require PIN access rights? I think this MUST require PIN access rights. 6. 5.5 Get-Preferred-Identity - this appears to be the same function as Select-Identity of type '13'. If this is intnetional, I think it is confusing to list it as a seperate function. Anyone implementing EAP/SIM would need to know that they are the same. 7. 5.4 Select-Identity - This MUST require PIN access rights also. 8. 5.4 Select-Identity - The EAP/SIM identity as specified in [0] includes a username and an "@realm" portion. The "@realm" is not used by EAP/SIM but may be needed to direct the request to a particular server. This part would normally be supplied by the EAP/SIM client. How is the "@realm" portion supplied to the selected identity? Does it differ for the different identity types? 9. 5.4 Select-Identity - is the "permanent identity" always based on the IMSI as recommended in [0] (i.e. 1@realm) or can it take other forms? Does it always include the "1" and the "@realm"? 10. 5.6 Process-EAP - also requires GET CURRENT VERSION to set the authenticator's version list before executing this command. 11. 5.6 Process-EAP - AT_CHECKCODE not supported - is it ignored if received or does it cause an error? 12. 5.6 Process-EAP - authentication type 01 - does this use only the IMSI in the operation or the identity based on the IMSI (i.e. 1@realm)? 13. 5.6 Process-EAP - authentication type 01 - how is this useful? The cryptographic operations need to use the EAP/SIM Identity actually used in the EAP/Request/Identity or EAP/SIM/Start message, so a Select-Identity is required in any case. If this does not serve a purpose I would suggest removing it. 14. 5.8 - Get-Current-Version - this command also sets the version list received from the authenticator. This is not clear from either the name or the description. In addition to adding this to the description, I would suggest using "Version List Length" instead of "XX" as the description of the Lc parameter and make Version-Type 1 say "get version and set version list for EAP/SIM". 15. 5.8 - Get-Current-Version - should state that this command is required before Process-EAP. 16. 5.8 - Get-Current-Version - is the version reported as '00', '01' or '01', '00'? That isn't clear from '0001'. 17. 5.8 - Get-Current-Version - there is no specific error code for "version not supported" if the authenticator's version list does not contain a supported version. Is this checked? A specific error code for this condition would be useful. 18. 5.8 - Get-Current-Version - This should require PIN access rights since executing it can affect an authentication in progress. Thank you. --Tom Porcher -- Tom Porcher | porcher@funk.com voice: 978.371.3980 x108 Consulting Engineer | http://www.funk.com fax: 978.371.3990 Funk Software, Inc. | Concord, Massachusetts, USA, Earth Wouter Habraken wrote: >Today the WLAN Smart Card Consortium (WLAN-SCC) announced the first >draft version of the WLAN-SIM specification for public comment. > >This specification is expected to be supported by all the major SIM >smart card vendors, and enables support for several EAP-SIM functions >directly on the smart card, including identity management, random number >generation and the EAP-SIM challenge and re-authentication functions. > >I would encourage anyone interested in EAP and SIM authentication to >review the spec. We would very much appreciate you comments and >feedback. > >Spec (150kb pdf): http://www.wlansmartcard.org/specs/WLAN-SIM_V01.PDF >(PR: http://www.wlansmartcard.org/html/news.html) > >This spec is the first of several planned by the WLAN-SCC. Others will >provide support for additional authentication methods (see the >urien-eap-smartcard IETF draft), configuration management, QOS and VoIP. > >Cheers, > >Wouter Habraken >Raak Technologies >whabraken@raaktechnologies.com > > > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap > > --------------060308040302010401050906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Wouter,

Thank you for publishing this specification.  I have been implementing EAP/SIM for Funk Software and I have a number of comments.

Is there a forum for discussing this specification?  The EAP mailing-list is probably not the right venue for further discussions of this specific a topic.
  1. General - use of numbers - Some of the numbers appear to be hexadecimal, while others appear to be decimal.  I would recommend explictly stating that all numbers are decimal unless indicated otherwise.  Those numbers in hexadecimal should be noted as such.
  2. 2 References - Can you tell me how to get [3] and [4]?  For [3], the spec number TS 102.221 is out of the range of available specifications from 3GPP.  For [4], there is no information on the publisher.
  3. 5.2 PIN Management - If this is implemented on a SmartCard that also supports "traditional" GSM SIM operations, is the PIN the same as the GSM PIN?
  4. 5.3 Get-Preferred-Identity - this "may" require PIN access rights?  I think this MUST require PIN access rights.
  5. 5.5 Get-Preferred-Identity - this appears to be the same function as Select-Identity of type '13'.  If this is intnetional, I think it is confusing to list it as a seperate function.  Anyone implementing EAP/SIM would need to know that they are the same.
  6. 5.4 Select-Identity - This MUST require PIN access rights also.
  7. 5.4 Select-Identity - The EAP/SIM identity as specified in [0] includes a username and an "@realm" portion.  The "@realm" is not used by EAP/SIM but may be needed to direct the request to a particular server.  This part would normally be supplied by the EAP/SIM client.  How is the "@realm" portion supplied to the selected identity?  Does it differ for the different identity types?
  8. 5.4 Select-Identity - is the "permanent identity" always based on the IMSI as recommended in [0] (i.e. 1<IMSI>@realm) or can it take other forms?  Does it always include the "1" and the "@realm"?
  9. 5.6 Process-EAP - also requires GET CURRENT VERSION to set the authenticator's version list before executing this command.
  10. 5.6 Process-EAP - AT_CHECKCODE not supported - is it ignored if received or does it cause an error?
  11. 5.6 Process-EAP - authentication type 01 - does this use only the IMSI in the operation or the identity based on the IMSI (i.e. 1<IMSI>@realm)?
  12. 5.6 Process-EAP - authentication type 01 - how is this useful?  The cryptographic operations need to use the EAP/SIM Identity actually used in the EAP/Request/Identity or EAP/SIM/Start message, so a Select-Identity is required in any case.  If this does not serve a purpose I would suggest removing it.
  13. 5.8 - Get-Current-Version - this command also sets the version list received from the authenticator.  This is not clear from either the name or the description. In addition to adding this to the description, I would suggest using "Version List Length" instead of "XX" as the description of the Lc parameter and make Version-Type 1 say "get version and set version list for EAP/SIM".
  14. 5.8 - Get-Current-Version - should state that this command is required before Process-EAP.
  15. 5.8 - Get-Current-Version - is the version reported as '00', '01' or '01', '00'?  That isn't clear from '0001'.
  16. 5.8 - Get-Current-Version - there is no specific error code for "version not supported" if the authenticator's version list does not contain a supported version.  Is this checked?  A specific error code for this condition would be useful.
  17. 5.8 - Get-Current-Version - This should require PIN access rights since executing it can affect an authentication in progress.
Thank you.
                     --Tom Porcher
-- 
Tom Porcher          | porcher@funk.com    voice: 978.371.3980 x108
Consulting Engineer  | http://www.funk.com   fax: 978.371.3990
Funk Software, Inc.  | Concord, Massachusetts, USA, Earth


Wouter Habraken wrote:
Today the WLAN Smart Card Consortium (WLAN-SCC) announced the first
draft version of the WLAN-SIM specification for public comment.

This specification is expected to be supported by all the major SIM
smart card vendors, and enables support for several EAP-SIM functions
directly on the smart card, including identity management, random number
generation and the EAP-SIM challenge and re-authentication functions.

I would encourage anyone interested in EAP and SIM authentication to
review the spec. We would very much appreciate you comments and
feedback.

Spec (150kb pdf): http://www.wlansmartcard.org/specs/WLAN-SIM_V01.PDF
(PR: http://www.wlansmartcard.org/html/news.html)

This spec is the first of several planned by the WLAN-SCC.  Others will
provide support for additional authentication methods (see the
urien-eap-smartcard IETF draft), configuration management, QOS and VoIP.

Cheers,

Wouter Habraken
Raak Technologies
whabraken@raaktechnologies.com



_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap
  





--------------060308040302010401050906--


From ltarkkal@ssh.com  Mon Jul 21 18:16:03 2003
From: ltarkkal@ssh.com (Lauri Tarkkala)
Date: Mon, 21 Jul 2003 20:16:03 +0300
Subject: [eap] minimum MTU undefined
Message-ID: <20030721171603.GA1163@tehdas>

Minimum MTU not defined.

Submitter name: Lauri Tarkkala
Submitter email address: ltarkkal@ssh.com
Date first submitted: 2003-07-21
Reference: 
Document: RFC2284bis
Comment type: 'T'
Priority: 'S'
Section:
Rationale/Explanation of issue:

The current RFC2284bis draft does not define a minimum MTU that EAP
methods can rely on. At least the following EAP methods do not
do fragmenting:
- Identity
- Notification
- MD5-Challenge
- .. etc
(- and Nak, which is not a method, but anyway)

Currently the "minimum MTU" is "inherited" from PPP (1500 bytes),
but all uses of EAP do not conform to this (e.g. PPPoe).
A minimum MTU must be defined such that embeddings of EAP into
other protocols will be such that implementations of these
methods will always operate correctly. There are also
the implied architectural limitations, which will cut
across any system architecture which contains EAP:

- Maximum identity length (unfragmented MTU - headers bytes -
  maximum length of piggy-backed option settings)
- Maximum notification length 

The defined minimum MTU should be defined to be as large
as possible, due to the lossage implied when doing
fragmentation/reassembly in a lock-step
protocol. Note also that the composite protocol
architecture may be doing fragmentation/reasembly
in both the EAP transport and the EAP method, if
the usage is improper.

The proposed solution is in a nutshell:
- Define that minimum frame size that can be sent/received unfragmented
  by EAP as X bytes.
- State the maximum notification length as X - headers.
- State the maximum identity req/resp lengths as  
  Y = X - headers - possible options 
- State that because EAP is a lock-step protocol and if latency
  is important and methods with large frames are used, the
  EAP transport protocol SHOULD provide fragmentation and
  reassembly services for frames upto 2^16 bytes.
- Initial proposal of X as 1400 bytes. If somebody knows any protocols
  that use EAP with MTU's then I'm sure we'd all like to hear about it.

Hopefully somebody has the relevant experience from all EAP implementations
to specify better values for X and Y than in the text below (1400 and
1024 respectively).

Requested change:

In section 3.1 ("Lower layer requirements") add below.

"[4] MTU known a-priori.  The EAP layer does not support
 fragmentation and reassembly.  However, EAP methods SHOULD be capable of
 handling fragmentation and reassembly.  As a result, EAP is
 capable of functioning across a range of MTU sizes, as long as
 the MTU is known a-priori.  EAP does not support path MTU discovery."

to

"[5] Minimum MTU. The EAP layer, the EAP Identity method,
 EAP Notification method and the NAK responses do NOT support
 fragmentation and reassembly. EAP methods designed originally 
 for use within PPP (where a 1500 byte MTU is guaranteed for
 control frames [RFC1661]) also lack fragmentation and reassembly features.
 The lower layer transporting EAP MUST therefore be capable of carrying
 EAP frames of upto 1400 bytes unfragmented. Note also that EAP is a
 lock-step protocol, which implies a certain inefficiency when doing
 fragmentation and reassembly. The lower layer therefore SHOULD
 provide fragmentation and reassembly services."

... and Change the numbering of the following items from [5] -> [6] and
[6] -> [7].

After the first paragraph in "Section 5.1" add:

"Some implementations of EAP tend to piggy-back into an Identity
 Request or Response various options after a NUL-character. An EAP
 implementation SHOULD NOT assume that usernames or displayable messages
 over 1024 bytes in Identity Requests or Responses will work in all
 environments."

Add to first paragraph in "Section 5.2" the sentences:

"Note that the maximum length of a notification messages that can be used
 reliably in all EAP implementations is 1400 bytes. The length
 of the human readable message SHOULD therefore be at most 1395 bytes."

-- 
Lauri Tarkkala
SSH Communications Security Corp
http://www.ssh.com/

From ltarkkal@ssh.com  Mon Jul 21 18:23:36 2003
From: ltarkkal@ssh.com (Lauri Tarkkala)
Date: Mon, 21 Jul 2003 20:23:36 +0300
Subject: [eap] minor editorial nit
Message-ID: <20030721172336.GA1316@tehdas>

Minor Editorial Nit

Submitter name: Lauri Tarkkala
Submitter email address: ltarkkal@ssh.com
Date first submitted: 2003-07-21
Document: RFC2284bis
Comment type: 'E'
Priority: '2'
Section: 2.1
Rationale/Explanation of issue:

Third paragraph in Section 2.1 states

"A peer MUST NOT send a Nak (legacy or expanded) in reply to a
 Request, after an initial non-Nak Response has been sent.  Since
 spoofed EAP Request packets may be sent by an attacker, an
 authenticator receiving an unexpected Nak SHOULD silently
 discard it and log the event."

and in Section 1.2 we have the definition of silently discard:

"This means the implementation discards the packet
 without further processing.  The implementation
 SHOULD provide the capability of logging the
 event, including the contents of the silently discarded packet,
 and SHOULD record the event in a statistics counter."

Recommended change:

In section 2.1 change the third paragraph quoted above to
read:

"A peer MUST NOT send a Nak (legacy or expanded) in reply to a
 Request, after an initial non-Nak Response has been sent.  Since
 spoofed EAP Request packets may be sent by an attacker, an
 authenticator receiving an unexpected NAK SHOULD 
 discard it and log the event."

(e.g. remove the "silently", at first read I found this
 a bit confusing).

-- 
Lauri Tarkkala
SSH Communications Security Corp
http://www.ssh.com/

From ltarkkal@ssh.com  Mon Jul 21 19:15:11 2003
From: ltarkkal@ssh.com (Lauri Tarkkala)
Date: Mon, 21 Jul 2003 21:15:11 +0300
Subject: [eap] keying framework architectural considerations
Message-ID: <20030721181511.GA1423@tehdas>

(.. this is as a follow-up to a discussion at IETF7 about the
DHCP+PANA+EAP and key mgmt framework presentation...)

I am not submitting this as an issue, as I do not wish to propose
a single concrete solution at this point. At IETF57 Bernard Aboba presented
the keying framework draft, and after a brief discussion it was
agreed that lifetimes of SA's should be specified in more detail.
A view different from the one used in the keying framework document,
however was the "DHCP + EAP + PANA" architecture which was presented,
here two different SA protocols were used, as opposed to one in
the keying framework.

Currently the division into "Phase 0", "Phase 1" and "Phase 2"
and "EAP SA" and "SA protocol" is IMHO ok. The way I think
about it is that (although it is not currently explicitly specified) that
based on current uses of EAP the EAP SA semantics are inherited
from the SA protocol. If the AAA system wishes to impose
some additional semantics, this must be done via the SA protocol
(communicating these across EAP is not possible).

This is in contrast to at least some SA management protocols, where
generally what in the keying framework draft terminology would be "Phase 2"
SA semantics are inherited from "Phase 1" SA. On the other hand, if
an EAP SA inherits it's semantics (e.g. domain of validity, and what
not) from the "SA protocol", there will be an interesting situation
when more than one "SA protocol" is attached to the "EAP SA".

A possible solution is to require that all protocols present
a single set of semantics for EAP SA mgmt to the EAP instance.
In essence this is like having a thin abstraction layer
between EAP and the "SA protocol"-bundle (I couldn't resist ;),
in the case that they are not equivalent.

At least the following properties are required, IMHO:

1) SA validity is propagated from an SA protocol SA instance to all
   other dependent SA protocol SAs and the EAP SA instance.

  -> If a SA protocol thinks that an EAP SA is invalid, then ALL
     SA protocol SAs attached to that EAP SA must immediately be
     invalidated.

2) Each SA protocol must be able to perform the 
   SA protocol SA -> EAP SA association.

3) The EAP instance must be able to perform the "EAP SA" -> "All SA
   protocols" map.

These are pretty obvious, but these require a somewhat integrated
architecture, and then I am not sure whether a
"n * SA protocols + 1 * EAP SA" will benefit so much from the modularity
they might be trying to achieve. The system is especially fragile
int the "EAP SA" -> "SA protocol" and "SA protocol" -> "EAP SA"
maps, if there is a possibility that these associations may
become conflicting, then all bets are pretty much off regarding
any possibility of recovering synch.

Because the SA protocols are dependent upon EAP to generate an SA,
the only SA "management" feature that is valid to use in this
scenario is a "dead-peer detection" style feature in the "SA protocol".

As such, I would impose an additional demand on the keying framework,
particularly key naming.

- All EAP SA's have a unique identity. Call EAP SA's which have the
  same domain and are associated with the same credentials and
  identities as "similar".

- The SA protocol -> EAP SA association can be performed to the extent
  that the correct credentials and correct identities can be determined,
  even if the EAP SA is unavailable.

- There must exist a partial ordering of EAP SAs such that there
  always exists an unambiguous bottom (or top ;) element.
  This EAP SA should determine the "SA protocol SA" to use in
  sending packets, in cases where several candidate SA protocol SAs
  exist. If the choice of SA protocol would be ambiguous, then
  a similar ordering must be used to determine the correct one.
  These orderings must be globally defined.

This hopefully could take care of the signaling "SA protocol SA" ->
"EAP SA" -> "SA protocol SAs". 

If any modularity is required across architectures, the only shared
attribute for SA protocol SA's should be their dependence
on the same EAP SA instance. Especially if the SA protocols are 
different.

Does the WG have any ideas regarding this ? Is this sufficient ?

Lauri

-- 
Lauri Tarkkala
SSH Communications Security Corp
http://www.ssh.com/

From alper@docomolabs-usa.com  Wed Jul 23 04:08:10 2003
From: alper@docomolabs-usa.com (Alper Yegin)
Date: Tue, 22 Jul 2003 20:08:10 -0700
Subject: [eap] keying framework architectural considerations
In-Reply-To: <20030721181511.GA1423@tehdas>
Message-ID: 

Hello Lauri,

I need to understand couple of things in your message before I can fully
digest it. Please see below...

> 
> (.. this is as a follow-up to a discussion at IETF7 about the
> DHCP+PANA+EAP and key mgmt framework presentation...)
> 
> I am not submitting this as an issue, as I do not wish to propose
> a single concrete solution at this point. At IETF57 Bernard Aboba presented
> the keying framework draft, and after a brief discussion it was
> agreed that lifetimes of SA's should be specified in more detail.
> A view different from the one used in the keying framework document,
> however was the "DHCP + EAP + PANA" architecture which was presented,
> here two different SA protocols were used, as opposed to one in
> the keying framework.

Both DHCP SA and PANA SA are generated from EAP SA. Does the keying
framework document limit the EAP child SA to exactly one?

> 
> Currently the division into "Phase 0", "Phase 1" and "Phase 2"
> and "EAP SA" and "SA protocol" is IMHO ok. The way I think
> about it is that (although it is not currently explicitly specified) that
> based on current uses of EAP the EAP SA semantics are inherited
> from the SA protocol. If the AAA system wishes to impose
> some additional semantics, this must be done via the SA protocol
> (communicating these across EAP is not possible).
> 
> This is in contrast to at least some SA management protocols, where
> generally what in the keying framework draft terminology would be "Phase 2"
> SA semantics are inherited from "Phase 1" SA. On the other hand, if
> an EAP SA inherits it's semantics (e.g. domain of validity, and what
> not) from the "SA protocol", there will be an interesting situation
> when more than one "SA protocol" is attached to the "EAP SA".

Can you give an example to SA protocol in here? My example would be: 802.11i
4-way handshake is the "SA protocol" that turns EAP SA into L2-cipher SA. I
don't see what EAP SA should inherent from the 4-way handshake protocol.

> 
> A possible solution is to require that all protocols present
> a single set of semantics for EAP SA mgmt to the EAP instance.
> In essence this is like having a thin abstraction layer
> between EAP and the "SA protocol"-bundle (I couldn't resist ;),
> in the case that they are not equivalent.
> 
> At least the following properties are required, IMHO:
> 
> 1) SA validity is propagated from an SA protocol SA instance to all
>  other dependent SA protocol SAs and the EAP SA instance.

Based on my example above, I don't understand why L2-cipher SA (is this your
"SA protocol SA"?) should alter EAP SA.

> 
> -> If a SA protocol thinks that an EAP SA is invalid, then ALL
>    SA protocol SAs attached to that EAP SA must immediately be
>    invalidated.
> 
> 2) Each SA protocol must be able to perform the
>  SA protocol SA -> EAP SA association.
> 
> 3) The EAP instance must be able to perform the "EAP SA" -> "All SA
>  protocols" map.
> 
> These are pretty obvious, but these require a somewhat integrated
> architecture, and then I am not sure whether a
> "n * SA protocols + 1 * EAP SA" will benefit so much from the modularity
> they might be trying to achieve. The system is especially fragile
> int the "EAP SA" -> "SA protocol" and "SA protocol" -> "EAP SA"
> maps, if there is a possibility that these associations may
> become conflicting, then all bets are pretty much off regarding
> any possibility of recovering synch.
> 
> Because the SA protocols are dependent upon EAP to generate an SA,
> the only SA "management" feature that is valid to use in this
> scenario is a "dead-peer detection" style feature in the "SA protocol".

EAP lower-layer can help here. For example, PANA termination message can
clean-up EAP SA.

> 
> As such, I would impose an additional demand on the keying framework,
> particularly key naming.
> 
> - All EAP SA's have a unique identity. Call EAP SA's which have the
> same domain and are associated with the same credentials and
> identities as "similar".
> 
> - The SA protocol -> EAP SA association can be performed to the extent
> that the correct credentials and correct identities can be determined,
> even if the EAP SA is unavailable.
> 
> - There must exist a partial ordering of EAP SAs such that there
> always exists an unambiguous bottom (or top ;) element.
> This EAP SA should determine the "SA protocol SA" to use in
> sending packets, in cases where several candidate SA protocol SAs
> exist. If the choice of SA protocol would be ambiguous, then
> a similar ordering must be used to determine the correct one.
> These orderings must be globally defined.
> 
> This hopefully could take care of the signaling "SA protocol SA" ->
> "EAP SA" -> "SA protocol SAs".
> 
> If any modularity is required across architectures, the only shared
> attribute for SA protocol SA's should be their dependence
> on the same EAP SA instance. Especially if the SA protocols are
> different.
> 
> Does the WG have any ideas regarding this ? Is this sufficient ?
> 
> Lauri

Alper


From aboba@internaut.com  Wed Jul 23 16:48:57 2003
From: aboba@internaut.com (Bernard Aboba)
Date: Wed, 23 Jul 2003 08:48:57 -0700 (PDT)
Subject: [eap] Re: keying framework architectural considerations
Message-ID: 

Lauri --

Thank you very much for your message.  My coments and
questions are prefaced by [BA] below.

--------------------------------------------------------------------
(.. this is as a follow-up to a discussion at IETF7 about the
DHCP+PANA+EAP and key mgmt framework presentation...)

I am not submitting this as an issue, as I do not wish to propose
a single concrete solution at this point. At IETF57 Bernard Aboba
presented the keying framework draft, and after a brief discussion it was
agreed that lifetimes of SAs should be specified in more detail.

[BA] At present EAP does not negotiate an EAP SA lifetime; in AAA we have
discussed including a lifetime in the Group Keying AVP. The secure
association protocol may or may not negotiate a lifetime. And of course
any of the parties (EAP peer, Authenticator and AAA server) may discard SA
state at any time.

A view different from the one used in the keying framework document,
however was the "DHCP + EAP + PANA" architecture which was presented,
here two different SA protocols were used, as opposed to one in
the keying framework.

[BA] EAP SAs are the focus of the Keying Framework document, but secure
association (Phase 2) SAs are also discussed. There are also the SAs
created for protection of the AAA protocol.

Currently the division into "Phase 0", "Phase 1" and "Phase 2"
and "EAP SA" and "SA protocol" is IMHO ok. The way I think
about it is that (although it is not currently explicitly specified) that
based on current uses of EAP the EAP SA semantics are inherited
from the SA protocol.

[BA] Actually I think that the EAP SA semantics are inherited from the
method. The "secure association" protocol only influence the Phase 2
semantics. For example, some methods (e.g. EAP-TLS) can support fast resume and
therefore the EAP SA is presumed to remain beyond the completion of the
authentication. In other methods this might not be the case.




If the AAA system wishes to impose
some additional semantics, this must be done via the SA protocol
(communicating these across EAP is not possible).

[BA] The AAA server isn't a party to the secure association (Phase 2)
protocol, although I suppose it could send some attributes. So I'm not
sure how much leeway the server really has.

The AAA system can send a Key-Lifetime AVP along with the key.
However, this is only advisory even if the authenticator echoes it,
indicating acceptance.  And as you say, this can't be communicated across
EAP so that the EAP peer does not know what the lifetime is.  The result
is that the EAP peer can't make any assumptions about whether the EAP SA
still exists when a future Phase 2 conversation takes place.

Given this, the Key-Lifetime AVP enables the AAA server to influence
but not control key caching.



This is in contrast to at least some SA management protocols, where
generally what in the keying framework draft terminology would be "Phase
2" SA semantics are inherited from "Phase 1" SA. On the other hand, if
an EAP SA inherits it's semantics (e.g. domain of validity, and what
not) from the "SA protocol", there will be an interesting situation
when more than one "SA protocol" is attached to the "EAP SA".

[BA] The way I think of this is that the Phase 2 SA depends on the EAP SA,
but does not modify the semantics of the EAP SA.  This raises the issue of
whether a Phase 2 SA terminates when the Phase 1 SA is deleted.  I don't
necessary think there is a link there;  an AP can continue to use
transient session keys after it has deleted the PMK, but it won't be able
to rerun the 4-way handshake at a later time on that PMK.


A possible solution is to require that all protocols present
a single set of semantics for EAP SA mgmt to the EAP instance.
In essence this is like having a thin abstraction layer
between EAP and the "SA protocol"-bundle (I couldn't resist ;),
in the case that they are not equivalent.

At least the following properties are required, IMHO:

1) SA validity is propagated from an SA protocol SA instance to all
   other dependent SA protocol SAs and the EAP SA instance.

  -> If a SA protocol thinks that an EAP SA is invalid, then ALL
     SA protocol SAs attached to that EAP SA must immediately be
     invalidated.

[BA] Not sure there is a link here. If the EAP SA is invalidated, it seems
like it is still possible for the Phase 2 SAs to remain valid. It's weird,
though.

2) Each SA protocol must be able to perform the
   SA protocol SA -> EAP SA association.

[BA] Yes, I think there needs to be a binding here.  The AAA server may
send "key context" AVPs along with the key itself.  This can include the
key name, lifetime, etc. These specify properties of the AAA-Key, which is
used in establishing the Phase 2 SA.  If there is any inheritance of Phase
2 from Phase 1, then the inherited "context" needs to be understood.  In
particular, if Phase 2 SA lifetimes can't extend beyond the life of the
Phase 1 SA, then this has to be taken into account.


3) The EAP instance must be able to perform the "EAP SA" -> "All SA
   protocols" map.

These are pretty obvious, but these require a somewhat integrated
architecture, and then I am not sure whether a
"n * SA protocols + 1 * EAP SA" will benefit so much from the modularity
they might be trying to achieve. The system is especially fragile
int the "EAP SA" -> "SA protocol" and "SA protocol" -> "EAP SA"
maps, if there is a possibility that these associations may
become conflicting, then all bets are pretty much off regarding
any possibility of recovering synch.

Because the SA protocols are dependent upon EAP to generate an SA,
the only SA "management" feature that is valid to use in this
scenario is a "dead-peer detection" style feature in the "SA protocol".

As such, I would impose an additional demand on the keying framework,
particularly key naming.

- All EAP SAs have a unique identity. Call EAP SA's which have the
  same domain and are associated with the same credentials and
  identities as "similar".

- The SA protocol -> EAP SA association can be performed to the extent
  that the correct credentials and correct identities can be determined,
  even if the EAP SA is unavailable.

- There must exist a partial ordering of EAP SAs such that there
  always exists an unambiguous bottom (or top ;) element.
  This EAP SA should determine the "SA protocol SA" to use in
  sending packets, in cases where several candidate SA protocol SAs
  exist. If the choice of SA protocol would be ambiguous, then
  a similar ordering must be used to determine the correct one.
  These orderings must be globally defined.

This hopefully could take care of the signaling "SA protocol SA" ->
"EAP SA" -> "SA protocol SAs".

If any modularity is required across architectures, the only shared
attribute for SA protocol SA's should be their dependence
on the same EAP SA instance. Especially if the SA protocols are
different.

Does the WG have any ideas regarding this ? Is this sufficient ?

Lauri

-- 
Lauri Tarkkala
SSH Communications Security Corp
http://www.ssh.com/




From aboba@internaut.com  Wed Jul 23 22:20:38 2003
From: aboba@internaut.com (Bernard Aboba)
Date: Wed, 23 Jul 2003 14:20:38 -0700 (PDT)
Subject: [eap] Proposed Resolution to Issue 157: Order of attribute processing
Message-ID: 

The text of Issue 157 is enclosed below.  During IETF 57, we discussed the
issue and Pasi Eronen suggested that the best solution might not be to
specify the order of attribute processing in RFC 2869bis, since it might
not be the same for all media.

I think that makes sense. However, we do need to make sure that
the attributes get processed before the Accept/Reject indication. For
example, when receiving Access-Reject with EAP-Failure the EAP-Failure
needs to be sent before the port goes down or elese the EAP peer won't
receive the EAP-Failure and could hang.

There was also some discussion as to whether the User-Name in the
Access-Accept needs to be the same as in the Access-Request.

RFC 2865 indicates that the User-Name in the Access-Accept can
be different than the one in the Access-Request. For example,
the text below from Section 5.1 would have no purpose if they were
required to be the same:

"It MAY be sent in an Access-Accept packet, in which case the
client SHOULD use the name returned in the Access-Accept packet in
all Accounting-Request packets for this session. If the Access-
Accept includes Service-Type = Rlogin and the User-Name attribute,
a NAS MAY use the returned User-Name when performing the Rlogin
function."

Proposed fix:

Change Section 2.6.4 to:

"A RADIUS Access-Accept or Access-Reject packet may contain
EAP-Message attribute(s). In order to ensure
the correct processing of RADIUS packets, the NAS
MUST first process the attributes, including the
EAP-Message attribute(s), prior to processing the
Accept/Reject indication."

In Section 3 , change:

"difficult to manage."

To:

"difficult to manage. The User-Name attribute within the Access-Accept
packet need not be the same as the User-Name attribute in the Access-
Request."

In Appendix B , delete:
"EAP-Message attributes are processed last (Section 2.6.4)."

-------------------------------------------------------
Issue 157: Order of attribute processing
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: July 6, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-July/001429.html
Document: RFC 2869bis-22
Comment type: T
Priority: S
Section: 2.6.4, 3, Appendix B
Rationale/Explanation of issue:

Existing implementations process EAP-Message attributes first, and
changing the processing order will cause backward compatibility issues as
well as problems with operation of IEEE 802.11i. If approved, this change
will be made in Author 48 hours, since the draft has already been approved
for publication as an RFC.

In Section 2.6.4, change:

"Reject or Access-Challenge, the NAS SHOULD process other attributes
first, then decapsulate EAP-Message attribute(s), reconstitute the EAP
packet and send it to the peer."

To:

"Reject or Access-Challenge, the NAS SHOULD first decapsulate EAP-Message
attribute(s), reconstitute the EAP packet and send it to the peer, then
process other attributes."

In Section 3 , change:

"difficult to manage."

To:

"difficult to manage. The User-Name attribute within the Access-Accept
packet need not be the same as the User-Name attribute in the Access-
Request."

In Appendix B , change:

"EAP-Message attributes are processed last (Section 2.6.4)."

To:

"EAP-Message attributes are processed first (Section 2.6.4)."


From victor.lortz@intel.com  Mon Jul 28 15:36:06 2003
From: victor.lortz@intel.com (Lortz, Victor)
Date: Mon, 28 Jul 2003 07:36:06 -0700
Subject: [eap] Issue 142 suggestion:  syntax for network info hint in Type-Data field of Identity-Request
Message-ID: 

In Issue 142, Bernard has suggested that specification of the Type-Data =
field data of Identity-Request after the nul character should include:
=20
a) An ABNF describing the grammar for the parameters and values;
b) IANA considerations for allocation of parameters and values.

Here is a suggestion for dealing with points a) and b).

Suppose we use XML syntax instead of the previously proposed syntax for =
this data.  IANA considerations can  be dealt with using the XML =
namespace mechanism.  Here is an example:

display-string\0

The schema associated with urn:ietf.org:EAP:Netinfo would define the =
attributes networkid, nasid, portid,  and whatever else might be =
appropriate.  The leading  is not strictly necessary, but it might =
be useful to help avoid confusion with existing practice that uses =
comma-separated attribute=3Dvalue syntax.

One advantage of this approach is that vendor or domain-specific =
extensions can easily be added without requiring additional IANA =
requests.  For example,

display-string\0

To simplify parsing, it might be preferable that the schema restrict the =
NetInfo element to have only attributes, as shown in these examples (no =
child elements).   Besides the parsing simplifications that this =
restriction would provide, attributes are also more compact than =
elements (no need for a trailing   tag). =20

Regards,
Vic Lortz
Intel Corporation


From jsalowey@cisco.com  Wed Jul 30 06:21:57 2003
From: jsalowey@cisco.com (Joseph Salowey)
Date: Tue, 29 Jul 2003 22:21:57 -0700
Subject: [eap] Issue 164: conflicting implementation note
Message-ID: <00ce01c3565a$7fcf4000$0200000a@amer.cisco.com>

The implementation note in section 5.1 seems to conflict with text in
section 2[3]

Submitter name: Joe Salowey 
Submitter email address: jsalowey@cisco.com 
Date first submitted: 7/29/2003
Reference: 
Document: RFC2284bis
Comment type: T
Priority: S
Section: 5.1
Rationale/Explanation of issue: 

In section 2 [3] there is the following text
"After a suitable number of
       retransmissions, the authenticator SHOULD end the EAP
       conversation.  The authenticator MUST NOT send a Success or
       Failure packet when retransmitting or when it fails to get a
       response from the peer."

In section 5.1 there is the following text in the implementation note:

"It is suggested that the Identity Request be
         retried a minimum of 3 times before terminating the
         authentication phase with a Failure reply."

This seems contradictory.

Requested change: 

Section 5.1 

"It is suggested that the Identity Request be
         retried a minimum of 3 times before terminating the
         authentication."


From jari.arkko@piuha.net  Wed Jul 30 18:17:07 2003
From: jari.arkko@piuha.net (Jari Arkko)
Date: Wed, 30 Jul 2003 20:17:07 +0300
Subject: [eap] Issue 164: conflicting implementation note
In-Reply-To: <00ce01c3565a$7fcf4000$0200000a@amer.cisco.com>
References: <00ce01c3565a$7fcf4000$0200000a@amer.cisco.com>
Message-ID: <3F27FD93.8040907@piuha.net>

> In section 2 [3] there is the following text
> "After a suitable number of
>        retransmissions, the authenticator SHOULD end the EAP
>        conversation.  The authenticator MUST NOT send a Success or
>        Failure packet when retransmitting or when it fails to get a
>        response from the peer."
> 
> In section 5.1 there is the following text in the implementation note:
> 
> "It is suggested that the Identity Request be
>          retried a minimum of 3 times before terminating the
>          authentication phase with a Failure reply."
> 
> This seems contradictory.

Yes.

> Requested change: 
> 
> Section 5.1 
> 
> "It is suggested that the Identity Request be
>          retried a minimum of 3 times before terminating the
>          authentication."

Right. Thanks for observing this!

--Jari




From jari.arkko@piuha.net  Wed Jul 30 18:20:20 2003
From: jari.arkko@piuha.net (Jari Arkko)
Date: Wed, 30 Jul 2003 20:20:20 +0300
Subject: [eap] minor editorial nit
In-Reply-To: <20030721172336.GA1316@tehdas>
References: <20030721172336.GA1316@tehdas>
Message-ID: <3F27FE54.7010202@piuha.net>

Lauri Tarkkala wrote:

> Third paragraph in Section 2.1 states
> 
> "A peer MUST NOT send a Nak (legacy or expanded) in reply to a
>  Request, after an initial non-Nak Response has been sent.  Since
>  spoofed EAP Request packets may be sent by an attacker, an
>  authenticator receiving an unexpected Nak SHOULD silently
>  discard it and log the event."
> 
> and in Section 1.2 we have the definition of silently discard:
> 
> "This means the implementation discards the packet
>  without further processing.  The implementation
>  SHOULD provide the capability of logging the
>  event, including the contents of the silently discarded packet,
>  and SHOULD record the event in a statistics counter."
> 
> Recommended change:
> 
> In section 2.1 change the third paragraph quoted above to
> read:
> 
> "A peer MUST NOT send a Nak (legacy or expanded) in reply to a
>  Request, after an initial non-Nak Response has been sent.  Since
>  spoofed EAP Request packets may be sent by an attacker, an
>  authenticator receiving an unexpected NAK SHOULD 
>  discard it and log the event."
> 
> (e.g. remove the "silently", at first read I found this
>  a bit confusing).

Perhaps you are right. For Henrik: if you edit this, change
s/NAK/Nak/ in Lauri's text.

Another alternative is to simple say "... SHOULD silently
discard it", since the definition of silent discard already
includes logging...

--Jari




From jari.arkko@piuha.net  Wed Jul 30 18:23:46 2003
From: jari.arkko@piuha.net (Jari Arkko)
Date: Wed, 30 Jul 2003 20:23:46 +0300
Subject: [eap] minimum MTU undefined
In-Reply-To: <20030721171603.GA1163@tehdas>
References: <20030721171603.GA1163@tehdas>
Message-ID: <3F27FF22.7010707@piuha.net>

Lauri Tarkkala wrote:

> The current RFC2284bis draft does not define a minimum MTU that EAP
> methods can rely on. At least the following EAP methods do not
> do fragmenting:
> - Identity
> - Notification
> - MD5-Challenge
> - .. etc
> (- and Nak, which is not a method, but anyway)
> 
> Currently the "minimum MTU" is "inherited" from PPP (1500 bytes),
> but all uses of EAP do not conform to this (e.g. PPPoe).
> A minimum MTU must be defined such that embeddings of EAP into
> other protocols will be such that implementations of these
> methods will always operate correctly. There are also

I agree.

> the implied architectural limitations, which will cut
> across any system architecture which contains EAP:
> 
> - Maximum identity length (unfragmented MTU - headers bytes -
>   maximum length of piggy-backed option settings)
> - Maximum notification length 

Yep.

> The defined minimum MTU should be defined to be as large
> as possible, due to the lossage implied when doing
> fragmentation/reassembly in a lock-step
> protocol. Note also that the composite protocol
> architecture may be doing fragmentation/reasembly
> in both the EAP transport and the EAP method, if
> the usage is improper.
> 
> The proposed solution is in a nutshell:
> - Define that minimum frame size that can be sent/received unfragmented
>   by EAP as X bytes.
> - State the maximum notification length as X - headers.
> - State the maximum identity req/resp lengths as  
>   Y = X - headers - possible options 
> - State that because EAP is a lock-step protocol and if latency
>   is important and methods with large frames are used, the
>   EAP transport protocol SHOULD provide fragmentation and
>   reassembly services for frames upto 2^16 bytes.
> - Initial proposal of X as 1400 bytes. If somebody knows any protocols
>   that use EAP with MTU's then I'm sure we'd all like to hear about it.

Sounds good!

--Jari