| minutes from the interim meeting | <– Date –> <– Thread –> |
From: Jari Arkko (jari.arkko piuha.net)
|
|
| Date: Wed, 29 Oct 2003 23:21:09 -0600 (CST) | |
Extensible Authentication Protocol (eap) Interim Meeting Herndon, VA October 15, 2003 0900 - 1230 EAP WG Interim Meeting 1330 - 1700 EAP WG - IEEE 802.11i Joint Meeting
Chair(s): Bernard Aboba <aboba [at] internaut.com> Jari Arkko <Jari.Arkko [at] ericsson.com>
READING MATERIAL ================
o General Information: http://www.drizzle.com/~aboba/EAP/interim.txt
o EAP Key Framework http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-00.txt
o EAP State Machine http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-00.txt http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-00.pdf
o RFC 2284bis http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.txt
o IEEE 802.11i D6.0 http://grouper.ieee.org/groups/802/11/private/Draft_Standards/11i/802.11i-D6.0.pdf Userid: p8021 password: go_wildcats
o IEEE 802.1X-REV-D7.1 http://www.ieee802.org/1/files/private/x-REV-drafts/d7/802-1X-REV-d7-1.pdf
PRELIMINARIES =============
o Agenda Bashing
No comments.
o Bluesheets
Participants:
o Minutes
Taken by Joe Salowey and John Vollbrecth (thanks!), merged by Jari Arkko.
o Document Status
Jari went through the document status, as described in http://www.drizzle.com/~aboba/EAP/int-03/eap_oct03interim_agenda.ppt
- 2284bis has passed WG last call in AD evaluation Queue.
- State machine is now a Working Group document. Two open issues
to resolve with .1X (modifications will be made to the .1aa to
fix this). A WG Last Call will be issued soon. There is still
time to get changes into .1aa Call for implementers to verify
state machine. Testing organizations are developing conformance
tests based on this draft. Not clear who is or will review this. Probably need
implementations to check it -- maybe Yoshihiro will implement
it. Has been released to 1.X and 11i for review, but not much
feedback yet. - EAP Keying framework. This is also now Working Group document.
More work is needed on it, though. This isn't a dependency of 2284bis. All requirements have been
moved to 2284bis. Keying framework being copied by 11i, not pointed to -- mainly a
timing issue. Diameter EAP depends on Keying Framework (RADIUS can also use it,
probably based on Diameter work).- EAP RADIUS, RFC 3579, has been approved and published.
- EAP Diameter, draft-ietf-aaa-eap-02.txt is being worked on in
AAA WG. - Methods: There are several Internet Drafts on methods. As 2284
progresses it should be possible to move these forward, however
it is not exactly clear yet -- discussions
ongoing with the IESG. Not in charter to work on Methods. Individual methods may be
individual/informational or may become working group items.
Presumably charter would have to change to support this. Additional mandatory to implement mechanisms: Different
requirements for different applications, no one method meets
everyone's needs. Develop methods first and then see if agreement
can be reached. Tunnelled methods have different requirement from 2284;
requirements will likely be defined in methods. discussion of
what interface is required and how methods using tunneled methods
interface. Some discussion that timeframe for definining
anything in ietf will be too late to impact implementation.Methods can be coordinated as has been done with SIM and AKA.
Public Key methods not widely discussed. Comments on Archie and
IKEV2.
EAP KEY FRAMEWORK I ===================
o Open Issues - Bernard Aboba
http://www.drizzle.com/~aboba/EAP/eapissues.html
Issue 179: EAP-PRF issue raised by Uri Blumenthal. PRFs are required for derivation of keys from the EMSK. Some of the described PRFs associated with this issue may have IPR associated with them. Question is do we need a single PRF? Many PRFs are described/implemented and ok. It would be good to pick one for interoperability. But people felt uncomfortable with a new PRF, and the proposal is to reject this issue.
Issue 180: SA description. New text under discussion this meeting
Issue 182: Authorization issues. New text incorporated into latest draft.
Jari: Some additional issues have been opened since these slides. Minor things, however.
o Conversation Overview - Pasi Eronen
Pasi presented EAP Keying phases as in http://www.drizzle.com/~aboba/EAP/int-03/eap_interim_slides.ppt
There are three main phases, only one of which is EAP. Note that the discussion and implementation is only partly EAP.
(0) Discovery
This is out of the scope of EAP, discovery handled by PPPoE or
802.1x for example.(1a) EAP-authentication
Authenticate EAP Peer and EAP Server.
(1b) Access-Authorization
Provide keying material and EAP authorizations to
authenticator. Note that 1a and 1b typically overlap.(2) Service Authentication
For instance, 802.11i four-way exchange.
Setup protection and negotiate parameters for services.
Authentication may not be the best name for this process since
no real authentication takes place. Key material from EAP is
used in this phase. Not all of the parameter negotiation may
be protected.Discussion in comparison of the proposed model with Kerberos. The trust model is very similar. All parties trust the AAA server which acts similar to a KDC. The AAA access accept contains information that would be contained in a kerberos ticket. It could be possible for EAP methods to work like kerberos. Instead of sending keys through AAA, credentials could be returned in EAP to the client. The client could use these credentials to establish phase 2. Perhaps this should be explored more.
o Malicious AP problem, Pasi Eronen
Continuing with the same slides as above.
An AP can represent one set of information to the client and a different set of information to the AAA. In particular it can do this with the SSID. The SSID could be authenticated by one of the following methods:
1. Incorporate it into key derivation
2. Exchange the SSID in the authentication mechanism as authorization
data.It would be best to have a generic means of authenticating arbitrary authorization data within the EAP channel. Existing mechanism such as EAP-TLS may be able to include authorization data (SSID) in a server certificate. It is not clear how useful this would be.
Is SSID spoofing a problem? It is not clear that SSID spoofing is a problem that needs to be solved. The consensus at the interim meeting is that no one required this problem to be solved.
o Security Associations - Pasi Eronen
Security association Discussion, continuing with the same slides as above. There are the following SAs:
- Long Term EAP-SA
This is a long term security relationship based on a password,
public key pair or shared secret. Security is probably not the
appropriate term for this, for public key Trust Anchor, for
secret key security relationship?- Short term EAP-SA
This was defined as an EAP method SA to support fast resume
functionality. It is not used external to the mechanism.- AAA SA
Security association between AAA and authenticator based on
shared secret, IPSEC or TLS.- Service SAs
Service SAs are between the EAP-Peer and authenticator. They
combine information from EAP, service negotiation and
discovery. They are based on keying material from EAP.Discussion about whether MSK and EMSK state (or keys derived from that state) may be maintained on AAA for various reasons (Fast Handoff for example). This state would then be like security association derived from EAP. Currently this is not well defined and AAA implementations usually destroy the state after keys are distributed to the authenticator.
Discussion of 802.11i specific service SAs:
- PTKSA
Created by 4 way handshake
Addresses, PTK, Ciphersuite, cipher data(new), lifetime(new),
reference to PMKSA (new not in document), authorization
information (SSID, L2 filters, accounting)- PMKSA
PMKID, PMK, SSID, sharing PMK between
The keying document should describe problems with Using the AAA-Key directly. Pre 802.11i WEP can be used as an example. Note that Pasi's document has generic info as well as examples. The slides show only the examples. Discussion of whether examples belong in document.
EAP KEY FRAMEWORK II ====================
o Key Scoping & Fast Handoff - Bernard Aboba 8o-09 Postponed due to lack of time.
o Authorization & Fast handoff - Jari Arkko
Postponed due to lack of time.
o Diameter EAP - Pasi Eronen & Jari Arkko
An "AAA-Token" should consist of: - authorization AVP - key
The key attribute only contains a key and is not a group attribute. Does a key name need to be included?
If keys are derived from the EMSK or MSK and are cached then there is a reason to name them. This name should be derived from the EAP mechanism so both EAP-Peer and Eap-Authenticator need to know the name. If keys are going to be cached on the authenticator then AAA may need to return a name.
Some discussion on naming techniques. 802.11i currently hashes the PMK with a known quantity to generate a name. There was some reservation expressed as to whether this was a good idea or not. It would be better if the EAP mechanism derived a key that was not a direct static function of the key.
Naming issues for SA's particularly the long term Key between the client and AAA server. There is some confusion about whether the key can be a Master Key and if it is different if a public key is used. We did not come to closure about this, but noted that Russ has requirement that there be a name. (Some discussion that name allows SA to be destroyed/tracked.)
AFTERNOON MEETING WITH IEEE ===========================
o Minutes will be provided separately
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.