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.
|