Meeting Minutes of the EAP WG at IETF #57

LOCATION: Vienna Austria DATE: July 2003 SLIDES: 
http://www.drizzle.com/~aboba/EAP/ NOTES: Dirk Kroeselberg, John 
Vollbrecht, and Henrik Levkowetz (edited by Jari Arkko)

SESSION I, MONDAY

o Preliminaries (Jari Arkko)

 - Bluesheets - Agenda Bash

 No comments on the agenda.

o Document Status (Jari Arkko)

 - Base spec finished second last call with 4 open issues left, one of them 
major.

 Glenn asked about the 3 issues left for 2284bis(?), and said he'd found 3 
editorial issues already on the first page. The chairs requested Glenn to 
report the issues he found.

 - 2869bis approved by IESG, however some issues were found 
afterwards with 802.11i.

 - State machine to become WG item.

 - Binding problem according to the authors has no open issues left after 
list discussion.

 - Methods need expert review, can be informational or standard, but 
cannot progress before base docs are done.

o EAP RADIUS - RFC 2869bis update, Bernard Aboba

 - Bernard talked about the 2869bis status. It has been approved for 
publication as an RFC. But two issues were raised afterwards, the 
intention is to discuss these and fix the document in author's 48 hours. The 
proposed fixes were

 (1) Order of attribute processing #157: Proposal to resolve by adding some 
correctional text. Jesse Walker: Agreed. Pasi Eronen: Order change is 
fine, but not sure whether this should be in 2869bis, because the order can 
be different for different link layers. Bernard Aboba: This is an EAP 
problem, because the order affects the operation of the protocol.

 (2) Identity privacy. Proposed Change:  $B!H (Bthe user-name 
attribute within the access-accept packet need not be the same as the 
user-name attribute in the access-request $B!I (B) John Vollbrecht: 
thinks the user-name content has to be the same.

 Jari Arkko: Its unclear, who are we trying to protect. The AAA server does 
send ID of the user to the NAS anyway. Bernard Aboba: It is not only the 
identity of the user, but whatever is in the accounting message.

 Decision: Issues taken to the list for further discussion.

o EAP Base - RFC 2284bis, Henrik Levkowetz

 
http://www.ietf.org/internet-drafts/draf
t-ietf-eap-rfc2284bis-04.txt 
http://www.levkowetz.com/p
ub/ietf/drafts/eap/draft-ietf-eap-rfc2284bis-04.html 
http://www.dri
zzle.com/~aboba/EAP/eapissues.html

 - Remaining issues are 150, 151, 152, and 160.

 - Issue 150: lower-layer behaviour for limited access: Put to the list, as 
this needs more discussion

 - Issue 152: Lower layer indications: Text in 3.4 is not aligned with 
state machine draft. Clarified by Pasi Eronen: If you loose success 
packet, you can count on lower layers success indication. State machine 
does this  $B!H (Balways $B!I (B, EAP spec only allows this for methods 
with success acknowledgement.

 Bernard Aboba: following a survey, no one did implement this. So it is no 
useful.

 John Vollbrecht: State machine approach the is better approach

 Jari Arkko and Pasi Eronen: The practical impact is a long timeout if you do 
it as EAP specifies

 Bernard Aboba: The major impact is for PPP.

 Pasi Eronen: In WLAN there is a higher possibility of loosing the 
success packet, so this is affected as well.

 Bernard Aboba: Why would a mutually authenticated method not have 
success indication. This would be basically saying the client is happy when 
he authenticates the server.

 Pasi Eronen: But the server sends a link-layer success.

 John Vollbrecht: It may have been one of the major design flaws in EAP 
that both sides do not really know whether it succeeded

 Decision: The issue needs to be looked at in detail on the list.

 - Issue 160: Network selection assistance.

 EAP identity request, type field MUST not be null terminated 
according to spec. Some implementations embed a null octet to separate the 
message into a displayable and a non-displayable part.

 Glen Zorn: Not sure what the proposed solution is. Must be 
backwards-compatible. It is inappropriate to provide guidance on this.

 Someone: Need something, but it does not matter how this is done. Could be 
done as in the past with the null string.

 Zorn: The issue is at least 2 layers above EAP, not to be solved here.

 Conclusion: Discussion moved to the list?

o EAP State Machine, Pasi Eronen

 
http://www.cs.umd.edu/~npetroni/EAP/draf
t-vollbrecht-eap-state-04.html 
http://www.ietf.org/inter
net-drafts/draft-vollbrecht-eap-state-04.txt

 - Pasi Eronen spoke about the state of the EAP state machine draft. 
Significant progress has been made since the previous IETF, and a 
pre-alpha implementation by Yoshihiro Ohba.

 . Data flows are now shown in the diagram

 . Packets that should not occur are silently discarded.

 . Etc

 - Version 03 of the draft is incorporated in IEEE P802.1aa draft 6.1 
(annex).

 - Discussion on the  $B!H (Bpass-through & backend $B!I (B slide. 
Bernard Aboba: I don't understand what the passthrough method does - it 
confuses the AAA action and the lower layer interfaces. There used to be a 
AAA layer in there, but now it is gone. That is the flaw. Glenn Zorn: The 
state machine has to look the same whether there is AAA or not. Pasi 
Eronen: Then I'd split the authenticator and back-end state machines, so 
that we can show how one gets the same result whether one uses a backend or 
not. First we specified one authentication diagram. Then did two 
separate, one for passthrough, one for back end. Bernard Aboba: AAA 
client has to be there: It is a pass-through until the last EAP 
message. Pasi Eronen: That is already reflected in the current draft, but 
not in a very elegant way.

 - Farid Adrangi: State which parts have to be implemented and which not? 
Pasi Eronen: The whole doc is informative, the specs are 2284bis and 
2869bis. There are some cases where 2284bis says should but state 
machine does not cover the alternative. Therefore it has to stay 
informative. Future work may happen on EAP for tunnelled methods.

 In case there is a disagreement, 2284bis will be the normative 
document.

 - Jari Arkko: Will this become WG doc? There are still issues, so fix 
them, issue a new version and then make it WG doc. Bernard Aboba: How many 
read the draft? Result: About 3-4. All want to make it WG item. 
Decision: this will become a WG item.

o Network Selection, Farid Adrangi

 - Farid Adrangi held a presentation on network selection in EAP. This 
draft is related to some potential requirements from 3GPP on EAP.

 Visited networks have different agreements with home; user

 1) wants to be provided with a list of available visited networks 2) 
should be able to specify the VN

 Focus here on the first question. Presentation proposal: Open work item in 
EAP to analyse present requirements in an attempt to convey 
information (through EAP) to the UE for network selection.

 - Glenn Zorn: What is the use of this? Why would the client want to 
choose network?

 - Farid Adrangi: Because the different networks may have different 
services or costs. Glenn Zorn: Why can't you first authenticate, and then 
use some other protocol to choose? Farid Adrangi: It can cost to 
authenticate.

 - Glenn Zorn: Again, cannot this pre pre-configured, 
automatically updated? Farid Adrangi: The number of operator can be in the 
100's, there is a scalability issue with Glenn's proposed method

 - Someone: This is not really a thing for EAP, you are looking for a 
service discovery method.

 - Glenn: Could you describe the difference between a service and a 
network providing a service? Farid Adrangi: Trying to find a way to 
select what network should route the packages.

 - Jari Arkko: Talk to the interested people to figure out what the right 
protocol for network selection is, and then submit a draft to that WG.

o EAP SIM & AKA P. Eronen

 
http://www.ietf.org/internet-drafts/draf
t-haverinen-pppext-eap-sim-11.txt 
http://www.ietf.org/int
ernet-drafts/draft-arkko-pppext-eap-aka-10.txt

 - Pasi Eronen did a presentation on EAP SIM and AKA. The documents are 
quite stable now. They has been aligned with the key derivation as per 
2284bis.

 - EAP-SIM: Recent clarification added related to the security analysis 
(see below). When multiple RAND values are used, check that they are 
different. Clarified security considerations.

 - EAP-AKA has relatively similar changes.

 - Next steps: Get reviews, wait until 2284bis is finished. Proposal to 
publish method as informational

o EAP-SIM Security Analysis, Uri Blumenthal

 
http://www.drizzle.com/~aboba/EAP/AnalyisOfEAP.pdf

 - Uri Blumenthal presented the security analysis of EAP SIM.

 - There are some keyspace and mutual authentication weaknesses of 
EAP-SIM compared to what the specification currently says.

 - EAP SIM claims to enhance the security to 128bits, mutually 
authenticated with independent sessions. The analysis shows the 
possibility of two 64-bit attacks, and disproves session 
independence.

 - Glen Zorn: Is that an EAP-SIM or a GSM issue? Uri Blumenthal: The 
presentation just addresses the claims made in the EAP-SIM spec.

 - Bernard Aboba: Is the request, that lack of session independence 
should be added to the security considerations? Uri Blumenthal: yes.

EAP-SIM Analysis response, Pasi Eronen

 - Pasi Responded as follows:

 1) The text in the draft on key strength is somewhat different from what 
the Security Analysis addresses as claim (see slides).

 2) There's a difference between an attack with probability 2^-64, and an 
attack which requires work of 2 to the 64 (and give an attack 
probability of 1)

 3) The current document strongly recomments using 2 or 3 triplets, 
giving ~128 bit strength, rather than 1 triplet (giving ~64).

 In the newest version, text has been added to the latest draft that both 
client and server must use at least 2 triplets.

 EAP-SIM requires that the server always uses fresh RANDs, but the client 
cannot check (i.e. store). This is extensively discussed in security 
considerations.

 4) The SIM used for authentication SHOULD NOT be used in GSM, because then 
attacks can be done on that network which has weaknesses not present in EAP 
SIM

 5) There is no need to use SRES to increase key strength.

 - Jari Arkko: The conclusion is that methods need security review -- 
would be interesting with a similar analysis of AKA, for instance. It is 
essential that we agree what the security properties of the methods are 
(but users of EAP may have different opinions on what properties they 
require).

 We may also need additional requirements in 2284bis about session 
independence.

SESSION II, THURSDAY

o Report of the 802.1x ad-hoc interop test event (Karen O'Donoghue)

 - This event took place April 7-9, 2003 in Belmont, CA. Goal was to gain 
insight into status of products, to improve state of 802.1X 
interoperability, and to provide feedback to standards groups.

 - Issues identified were:

 . Specification interpretation issues. . Re-authentication, non-EAP 
agnostic authenticators (EAP type support, negotiation). . Inner auth 
methods (PEAP, TTLS), Wireless VLANs (no standards) . Bugs, bugs... . 
Administrative issue: Certificates are hard. Setting up took up a day, so 
prepare for more time next time.

 - Most of the problems were operational and implementation related. They 
may have been a few issues related to the clarity of of 
specifications, and Karen will send more information later on those.

 - InteropNet Labs is planning interop for next year. Test-suites are 
developed by the University of New Hampshire.

o EAP Keying Framework (Bernard Aboba)

 
http://www.drizzle.com/~aboba/EAP/draft-
aboba-pppext-key-problem-07.txt

 - Goal is to provide framework for evaluation of EAP key derivation 
mechanisms and transport mechanisms. EAP invariants are 
Media/Ciphersuite/Method independence.

 There are different relevant phases:

 0) Discovery phase; discover authenticator (out-of-band for EAP): Phase 0. 
It is not secure.

 1) EAP is Phase 1 between EAP peer and server. EAP SAs are 
bi-directional, Mutual authentication is required for key-deriving 
methods. Method provides keys (MSK, EMSK). EAP only supports key 
creation, no deletion.

 Running this phase does not mean that client want to connect at that time - 
preauthentication SA may be bidirectional.

 2) SA Protocol (Phase 2): Used by EAP peer to derive SA with the EAP 
authenticator to protect data. Demonstrates 
"proof-of-possession " of phase 1 SA (key binding).

 - Jesse Walker: Are we going to discuss key/SA lifetime issue? Bernard 
Aboba: Currently no lifetime negotiated. There is the lifetime of EAP, or 
data, SA. EAP SA lifetime not relevant. Data SA lifetime should be done by 
Data SA protocol. This should still be discussed at some point.

 Jesse Walker: Usually its time, but often with cryptographic devices it is 
also other things, such as usage of a key for a large amount of data. 
Bernard Aboba: There are two lifetimes, the phase 1 and phase 2. it is 
conceivable that phase 1 could be used too many times, to cause 
sequence number overflow or something. Jesse Walker: I don't think we need to 
worry about that but the data key lifetime is relevant.

 - Why is binding/naming important? EAP and SA protocol may not run 
between same parties. EAP key name required to identify SAs. A link that the 
EAP runs on may have multiple authentications so need a name to be sure 
know which authentication to base a secure association on.

 - James Kempf: Is it the name of the key or the SA? Bernard Aboba: in this 
case it is the name of the key.

 - Lauri Tarkkala: Why not just refer to the latest key? If eap does not 
have a delete mechanism, why bother with the naming. As EAP does not 
delete keys, what is the policy how many keys are cached? 
Implementation specific logic required, but this may lead to 
interoperability issues.

 Bernard Aboba: Depends on the implementation or the load of the 
affected device. No specification required here. For instance, how busy the 
AP is could affect whether phase 1 can be cached for a day or 5 
minutes. Lauri Tarkkala: I can agree with you reasoning, but it creates 
application specific reasoning. in ikev1 this has caused problems. 
Bernard Aboba: post the issue to the list so we can track this.

 - Bernard Aboba: EAP is a peer-to-peer protocol, but: AAA may not 
support role reversal; EAP methods may be client/server.

 - Open issues:

 . Issue 15: missing security requirements. Proposal: add material to 
address this in -07 draft

 . Issue 47: Key requirements unspecified (size of MSK/EMSK). 
Proposal: add nonce exchange requirement.

 The proposals or 15 and 47 were accepted.

 . Issue 99: Double expansion: occurs from MK to MSK and MSK to TSK: 
Proposal: reject, key strength is the issue, not double expansion.

 Jesse Walker: it is, there are papers. Bernard: please post 
references.

 . Issue 119: EAP is inappropriate for peer-to-peer. Proposal: reject.

 Jari Arkko: This may belong to RFC 2284bis.

 Jesse Walker: Not enough implementation experience that people really know 
about 119. Bernard Aboba: TLS methods are client-server, as they need 
different credentials on both sides. However, the best thing to find out is 
to try.

 . Issue 135: include SSID in PRF: Proposal: Reject (EAP is media 
independent, SSID does not exist on all media. During 
pre-authentication, SSID may not be available. There are issues for 
virtual APs).

 Alper Yegin: Other counterexamples are PANA and IKEv2.

 Lauri Tarkkala: SSID is too 802.1x-specific.

 Jari Arkko: Don't think there is a practical problem here. Jari: What 
about authorization? AP has to figure out which Phase 1 SAs it can use for 
which SSIDs. Isn't this an authorization problem?

 Jesse Walker: The real question is if MSK can be given to more than one 
NAS. If yes, don't care about the SSID. If no, Sometimes the 
information has to be given to the client that these are all the same 
thing so the MSK "compromise" is.

 Pat Calhoun: I ship a product that does this. Most clients get 
confused on multiple SSIDs, need to use virtual APs. I don't think we 
should share MSKs or move between virtual APs.

 - Bernard Aboba: I'll continue with updating 07 doc, resolve open 
issues.

 - Discussion continued about Russ Housley's requirements for key 
derivation presented at last IETF:

 . Key naming: Proposal for appropriate naming of EAP-SA, MK, MSK, EMSK, 
TSK. Issue: How do the NAS, EAP peer and AAA server come to agree on the key 
names? (NAS operates in pass-through, does not have access to MK or EMSK. 
Solution: AAA server needs to transmit this.

 . Comment: Discussion on this should be made part of the 2284bis Jari 
Arkko: Better to keep separate in the informational keying framework doc. 
Bernard Aboba: One document is standards track, the other is 
informational.

 . Alper Yegin: Where does the peer obtain the call-station-ID from? 
Bernard Aboba: usually lower layer; in the case of PANA this might be the IP 
address.

 . Someone: why is this keying framework informational? Bernard Aboba: 
there is a lot of informational stuff in the keying framework.

 . Jari Arkko: The mandatory parts will go in 2284bis in the end.

o EAP Key Derivation for Multiple Applications, H. Zhou

 
http://www.ietf.org/internet-drafts/draf
t-salowey-eap-key-deriv-01.txt

 - The idea of this draft is that multiple applications can be keyed from 
same MSK (protected-TLV, DHCP, PANA, fast roaming). Derive AMSK 
(application master keys) from EMSK.

 - Open issues: . KDF refinement . AAA attributes to request and deliver 
keys . Integration with key naming

o Use of EAP Keying for DHCP Bootstrap (Hannes Tschofenig)

 
http://www.ietf.org/internet-drafts/draf
t-tschofenig-pana-bootstrap-rfc3118-00.txt

 - Draft addresses EAP keying (derivation, distribution of MSK, derive PANA 
key). Key derivation for DHCP is based on PANA. There is a relation to "EAP 
Key Derivation for Multiple Applications" work.

 - Jari Arkko: What makes DHCP special, there are a lot of other things to be 
done for network access?

 - Hannes Tschofenig: network entities are different here.

 - Alper Yegin: Work is primarily for DHCP WG. An out-of-band key 
derivation scheme is missing. This is not meant to solve all the network 
access problems.

 - James Kempf: Why is PANA used here, couldn't we just use 802.1x or 
something that is there?

 - Hannes Tschofenig: PANA required; provides an additional set of 
nonces. Carries additional parameters required to establish SA with DHCP 
server. 802.1x does not allow this.

 - Kempf: One could extend 802.1x. Alper Yegin: Yes.

 - Result: Discussion taken offline.

o EAP Compound Binding (Farid Adranghi)

 
http://www.ietf.org/internet-drafts/draf
t-puthenkulam-eap-binding-03.txt

 - Issues addressed in new version:

 . #64: Problem statement addressed in new version.

 . #65: Downgrading attack: Current draft now explains this.

 . #70: Which PRFs should be used? draft now says should be based on what 
tunnelling protocol is used.

 . #88: Why tunnel keys are used? use keys of the inner methods? not 
changed, tunnel keys are stronger.

 . #89: Review of version 1 draft now addressed.

 . #123: Non-key generating methods and binding: now addressed in 3.2.

 - Process for the doc: Submit for final crypto review, resolve new 
issues.

 - Farid: Time is of essence, should become WG doc soon.

 - Jari Arkko: former reviewers still need time to check their issues

o EAP Client Side Transport (Florent Bersani)

 
http://www.ietf.org/internet-drafts/draf
t-boursetty-eap-cst-00.txt

 - Presentation just gives a concept, does not really fit in the WG right 
now. Splits EAP endpoints in AuthToken (peer side) and AuthServer for 
authentication; integrity/encryption runs between client (peer) and 
server. Idea is separating authentication and service used later on. 
Approach motivated by smartcards / security tokens.

 - Separate authentication from service carrying authentication. Don't need 
to support smart cards inside device, e.g. can authenticate with Smart card 
on phone to use notebook/pc talks about tokens rather than client 
authenticator.

o EAP Archie (Jesse Walker)

 
http://www.ietf.org/internet-drafts/draf
t-jwalker-eap-archie-01.txt

 - Some Changes in -01 version: . Altered to use only one crypto 
primitive . Bindings changed to use define numbers address family

 - No further changes planned. Will only evolve in response to Bugs, 
suggestions to simplify.

 - Uri Blumenthal and Jesse Walker designing new Archie-like protocol 
(based on Archie and SKE).

 - John Vollbrecht: Make it either a straight or a tunnelled protocol? 
Jesse: No technical reasons against this, depends on the group's 
feedback.

o EAP IKEv2 ( Hannes Tschofenig)

 
http://www.ietf.org/internet-drafts/draf
t-tschofenig-eap-ikev2-01.txt

 - Idea is to reuse good crypto and flexibility of IKEv2 as EAP method. 
Inherits IKEv2 security properties, including DoS protection. Does not 
exchange IPsec SA payloads.

 - Next steps: Incorporate comments already received, address key 
derivation and naming according to the current discussion. Stable 
version for the next IETF.

 - Open issues are sequencing of EAP methods, secure address 
configuration, protection of outer EAP methods (needed?).

o EAP LDAP, Avi Lior

 
http://www.ietf.org/internet-drafts/draf
t-mancini-pppext-eap-ldap-00.txt

 - EAP-LDAP is a challenge-based authentication using MD5, in 
conjunction with the encryption algorithm used to store the password 
within the LDAP identity store. Recommended to use in conjunction with 
tunneled methods. Could be extended to any other data store. Idea is to 
allow validation without passing password in clear. Draft requested to be WG 
draft.

 - Uri Blumenthal: But the cryptographic attack is the same for this as for 
MD5, you just do an extra step, but a dictionary attack is still 
possible.

 - Discussion: Comments moved to the list.

o PEAP Version 2 (J. Salowey/A. Palekar) (Hao Zhou)

 
http://www.ietf.org/internet-drafts/draf
t-josefsson-pppext-eap-tls-eap-06.txt

 - New draft addresses compound binding problem. Clarifications for 
implementors. Supports sequencing of methods in PEAP tunnel.

 - Lauri Tarkkala: Microsoft has IPR statement regarding PEAP. Does this 
apply to the new draft? They have stated there is nothing on the new 
draft? Zhou: cannot tell, not with MS.

 - Bernard Aboba: Why compound MAC and compound key are both done for 
binding? IKEv2 did only one of them? Zhou: Authors felt compound key does 
better security; did both however.

o EAP Support in Smartcard, P. Urien

 
http://www.ietf.org/internet-drafts/draf
t-urien-eap-smartcard-02.txt 
http://www.ietf.org/intern
et-drafts/draft-urien-eap-ssc-00.txt

 - Defines universal ISO 7816 interface; EAP-application on 
smartcard, that may be associated with different EAP-types. Supports lots of 
services and EAP SIM is supported, others under discussion.

 - Current Interfaces are network / OS+terminal / 
management+personalization / user. EAP-SSC (secure smartcard channel): uses 
single EAP type, defines symmetric or asymmetric key exchange 
procedures.

 - Future work: Rand number format rules for asymmetric case; message 
ciphering support.