| preliminary meeting minutes from IETF-63 | <– Date –> <– Thread –> |
From: Jari Arkko (jari.arkko piuha.net)
|
|
| Date: Wed, 17 Aug 2005 10:21:44 -0400 (EDT) | |
Please send additions, corrections, and comments to the list or to the chairs. Thank you Dirk and Jouni for taking notes!
-----
EAP WG Meeting at IETF #63
Location: Paris, France Date: August 2nd, 2005 Time: 14:00-16:20
Notes: Jouni korhonen and Dirk Kroeselberg (merging by Jari Arkko)
1. Preliminaries (5 min) -- Jari Arkko Agenda bashing Blue sheets and notes takers
Arkko: Doing agenda bashing and presenting the issue tracker. No changes to the agenda.
2. Document Status (5 min) -- Jari Arkko
o 2x RFCs out
o 2x in RFC queue
- EAP State Machine
- EAP SIM & AKAo Keying framework: still some open issues
o Netsel problem definition -> expired
- Volunteers needed for this draft to make
progress (several volunteers signed up later). o Adrangi Network discovery (draft-adrangi-eap-network-discovery-13.txt)
- Should be in back IESG review shortly
- Margaret Wasseman is in charge of this inividual
draft, some discussion ongoing. o IANA allocatios and Individual RFC publications requested
- EAP PAX, PSK, Smartcard Type, Double TLS, EAP IKEv2 o EAP method revies req:
- Double TLS, Smartcard Type, IKEv2 status currently DENIED
pending modifications per reviewer's requests
3. Keying Framework issues (30 min) -- Joe Salowey Goal: Discuss issues http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-08.txt
Joe Salowey gives the presentation:
- Whole thing has been split into three different documents
o Housley-aaa-key
- describes the general requirements for AAA key management,
intended as BCP.
o EAP-keying
- Describes the existing EAP key management usage
o EAP key management extensions
- Describes extensions to EAP key management model.
- www.drizzle.com/~aboba/EAP/draft-aboba-eap-keying-extns-00.txt
- This is an early version.
Jari: Are Russ' requirements binding? For
EAP, there are pretty precise definitions of the requirements,
what happens if there are conflicting requirements? Who gets
to discuss the content of Russ' document? (Russ not present)Closed issues: 300, 305
Issue 306: to be handled in Yoshi's presentation afterwards.
Issues discussed today (read the slides for the content):
294 - Analyzing existing EAP usage
- Analyzy what (802.1X, PPP, 802,11i)
- Analyze against (Housley criteria)
- No one present in the meeting indicated having looked into
this yet
- Bernard has a detailed analysis in his site -- please comment. Alper: what are objectives of this analysis?
Jari: understanding the security properties of the system
Alper: there are a lot of systems than those 3 listed earlier
Jari: Concentrate on known widely deployed cases.. however people
are free to submit more analysis on other cases.
Glen: widely deployed rules out PANA & IKEv2 etc
Jari: that is debatable of course
Someone: People willing to work on this is a good flow control..
So if people are willing to work on some analysis then
just do it. Action item: Hannes and Dirk will review Bernard's text and
post comments to the list. ** 299 - key caching, keys internal to EAP methods may be cached
fast re-auth etc) o Jari: Issue was started by confusing text mentioning key
caching. Hopefully we can scope how we can name and cache
these keys like EMSK etc. Should be explicitly stated what is
cached and whereDo we need to name the keys cached in the EAP layer?
EMSK and AMSK may be cached outside o EAP as possible
extension, but should be out-of-scope for the keying
framework. Other keys (MSK/AAA-Key) do not appear to
need caching. Also relates to naming: if they are not
cached in EAP, do they need a name?Action item: Joe volunteers to write the missing text.
** 302 - Domino effect clarifications
o Alper: should we use Housley as a normative reference or not?
o Jari: Housley is supposed to cover things beyond EAP
o Alper: What if the domino effect definition ends up in both docs?
Then they need to be synchronized beyond recognition...
o Jari: Agree. But in the keying framework we can state a
very specific requirement, and verify that its fulfilled.Action item: Alper to take this further.
** 307 - deletion of the security requirements section
o Mostly editorial.
o Jari: Bernard already sent a text proposal, which appears to solve the issue.
** 279 - Additional keying protocol requirements
#307 may already remove the need for this. But need to make
sure we cover these already. o Jari: Main thing is staying with the current system and not to look
into stuff like fast handoffs
o Jari: Any volunteer to go through Jesse's issue?
o Joe: lets assign this to him.. Action item: Jari to ask Jesse Walker to check whether the new
draft covers his requirements. ** Next steps
o More people are needed to review this draft.
Please review -08 version on Bernards web site. o 09 version in approx. 6 weeks. WGLC for this version,
revised final for IETF-64 o Review draft-housley (AAA keying requirements) and resolve
possible issueso Continue with extensions after IETF-64 and beyond.
4. Channel Bindings Goal: Discuss definitions, alternative schemes http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-08.txt http://www.ietf.org/internet-drafts/ draft-ohba-eap-aaakey-binding-01.txt and draft-arkko-eap-service-identity-auth-03.txt
Yoshihiro Obha gives the presentation on lower layer parameter & channel bindings (read the slides for then content):
Background for the discussion explained by Jari: Yoshi has a draft which suggests a channel binding mechanism which, if adopted, needs to go to the keying framework document so that the key calculation rules can be documented and standardized. Lets focus on the question if this is the way to go for the keying framework discussion or not.
Ohba: Yoshi's draft is based on the list discussion on alternatives for this.
The draft defines a key binding blob carrying lower layer information. The blob is sent by the authenticator to the server, and is an input to the key derivation. If the lower layer parameters of EAP peer and authenticator do not match, the lower-layer security cannot be successfully established (keys of supplicant and authenticator not matching).
The solution impacts the AAA protocol (e.g. new Radius attribute), but its advantage is that it works for all EAP methods without requiring an extension to them. Main drawback is impact to deployed APs, and possible also to lower layers protocols such as 802.11.
Pasi: Does not work with existing 802.11 access points. Yoshi: Yes, in this case AP can still use the legacy version, then EAP method support for channel binding would be required.
Pasi: There are code changes? Obha: Yes.
Joe: This should not be part of current keying framework, needs to many changes to existing stuff.
John: Naming (channel binding) should be changed, since exact problem is not clear.
Jari: Does not really belong into Housley document. Housley does not have much text HOW to implement these things.
Joe: We need to clearer what problem we are trying to solve. The channel binding name might be slightly misnomer.
Glen: EAP is so mixed up with AAA stuff, which causes lots of trouble. Probably belongs into the protocol, but it is not EAP.
Pasi: Some documents call this \u201cthe EAP system\u201d, which is EAP plus other things. This is really the scope of the keying framework.
Jari: Sounds like Yoshi's draft should not be part of keying framework. It may be worked on separately later, however.
5. Methods Discussion (40 min) Goal: Talk about the results of the reviews, make progress
EAP PSK Review (10 min) -- J. Walker http://www.ietf.org/internet-drafts/draft-bersani-eap-psk-08.txt
Independent submission to IESG. Requested EAP method type
number. Reviewed by Jesse Walker in June. Update integrating
some review points in -08 version. Still number of open
issues, e.g. for key derivation. Key naming is not planned,
since there is no application like fast reconnect. Discussion
will be continued on list. Hannes: On key control issue: it wouldn't add more complexity to
include it here.
Bersani: ok, moving on adding the key control Jari: The right process for this is to talk about the issues and
gather more expert reviews on the listHannes: I am one of the authors of PSK, Jesse actually criticized some things he originally proposed so we are a bit confused what he wants.
EAP IKEv2 Review (10 min) -- P. Eronen http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-07.txt
Pasi likes the approach, but document not considered ready. Inaccurate comparison to EAP-TLS mostly fixed in -07 version. Major issues e.g. with current fragmentation mechanism (since EAP is lock-step), fast reconnect does not clarify how the server picks the correct key, channel binding. Needs more work, but no major obstacles found.
Dirk: Channel binding was not updated since authors had to
wait for the outcome of Yoshi's proposal on channel binding.
Hannes: Thanks to Pasi for the review. One additional issue on
channel binding.. Could we come up with our own solution or
reference to something (and if so to what?)
Pasi: There are 2 ways how to do channel bindings (Obha and Pasi & Jari) no
selection which one has been made
Jari: I think we can do a decision on channel binding in the list
after the meeting, which one of the two to select. We will send
a question to the mailing list how to proceed with channel
bindings.
EAP Smartcard Type Review (5 min) -- G. Zorn http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-type-02.txt
There are already a number of EAP methods on token or smartcard
types. Expert review has been performed by Glen Zorn. Answers
to the review comments: see presentation slides. Pascal
disagrees with review comments in a few points, e.g. on the
IANA requirements compliance. Some discussion about security
claims. Glenn: Either take out security claims altogether, but
then it must be clear that the method itself has no security
properties.Jari: Running out of time, discuss this in the mailing list
EAP Double TLS Review (5 min) -- H. Tschofenig http://www.ietf.org/internet-drafts/draft-badra-double-tls-03.txt
Found some confusing text about "inner" method. Many optional parts
make analysis quite difficult. Some issues, e.g. key strength and
hierarchy not properly documented. Crypto-binding still needs
investigation. Relation to other TLS methods is important to be discussed, but has
not been subject of review. Pascal: Just motivate goal of the draft. This is to use
TLS-based shared key authentication.Jari: More discussion on the mailing list.
EAP PAX Update (5 min) -- T. Clancy http://www.cs.umd.edu/~clancy/eap-pax/draft-clancy-eap-pax-04.txt
- HostAP has an implementation of the EAP-PAX..
- IANA has allocated numbers
- Would like to move it to standards track document either in this
WG or in SECMECHMethods Work Situation Info (5 min) -- Jari Arkko
Jari thanks the reviewers.
Hopefully we will be able to work on few methods to get them
into standards track, either here or in SECMECH. Please
inform the list and the IESG on what needs to happen on
this front.6. Trusted Computing Group EAP Issues (20 min) -- John V.
See the slides for the main content. Note: Different naming for lower layer nodes and functions in TNC than in IETF.
General idea is to check client state before allowing network
access (quarantined). For EAP, TNC is considering a new EAP
method (protected method, inner method carried by outer
method). This method could map to IF-TNCCS (see slides). The
presentation is meant to seek feedback from the IETF EAP
community, maybe create a formal liaison later on. Possible
work could be a protected method, a generic "outer method", or
inner method keying requirements in the keying framework.
Jari: If you want more feedback on this.. Do you have anything else than these slides?? John: We have some but not all are publicly available. A participation to the consortium is generally required. May need a formal liaison, since TCG is a closed group. If such a method will be specified in IETF, this needs to be worked out. Jari: That has worked out earlier.. e.g. a certain consortium allows access to relevant documents for a certain WG. John: No standard "outer" method for protected EAP methods still exists. And is it possible to add "inner" capabilities to existing or planned methods?? Pasi: Sounds interesting and worth doing. Maybe without the help of EAP group. And we need those documents. Hannes: Also likes the idea.. Security Ads won't like this however.. Many of these things have already been discussed. But don't start with one specific tunnel method. The tunneled method might be inefficient as everything can be run inside the tunnel Jari: Tunnel methods can sometimes be used to avoid the IANA registration rules :) Glen: EAP specs currently do not define sequencing details, I thought that was clearly outlawed! Alper: Why? Glen: It was not allowed to run a sequence of EAP authentications. Alper: The latest 802.16e supports sequencing. Glenn: But this is not supported by the EAP spec Alper: These are two independent EAP sessions. However, discussion in IEEE is already closed. Jari: Volunteers to review for TCG..? Contact Jari.
7. EAP Enrollment (5 min) -- Rohan Mahy http://www.ietf.org/internet-drafts/draft-mahy-eap-enrollment-00.txt
Motivation is that small wireless devices (e.g. phones) are a pain to enrol onto WLANs. Basic proposal is to start with some weak credentials and then let the client fetch stronger credentials after that. Use existing methods. Presentation just seeks thoughts on this.
Hannes: Very good thoughts and has also been thought here in
this and other WGs earlier. Why we never managed to move this
forward earlier?
Alper: It goes back EAP applicability statement. Hannes: a number of methods provide the capability to
exchange config parameters. Want to see some guidance on how
to move things forward. Someone: Does not believe that a strong credential is better if
authentication is started with weak credentials before.
Rohan: but the server is authenticated. Jari: sorry, we are sort of pushed out of the room
now. Hannes, do you think there is a general solution?
Hannes: personal opinion that this could be a general
solution. Enrol would be a valid place to drive this. Jari: Further discuss this on the list, need to get this done
somehow.8. Meeting concluded 16:20
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.