Subject: [eap] draft EAP WG minutes from IETF-62

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Mar 2005 18:09:16 +0300

Here are the draft minutes, thanks to Subir and Dave for
taking notes! Comments, if any, to Bernard and me in the next
couple of days, please.

----

EAP WG meeting Notes, IETF-62, Minneapolis

Extensible Authentication Protocol WG (eap)

Thursday, March 10 at 0900 - 1130
=================================

CHAIRS: Jari Arkko <[email-masked]>
        Bernard Aboba <[email-masked]>

SCRIBES: Subir Das and Dave Nelson, merging by Jari Arkko

POINTERS: The presentations are on the web at 
http://www.drizzle.com/~aboba/IETF62/eap
          And issues are at http://www.drizzle.com/~aboba/EAP/eapissues.html

1. Preliminaries (chairs), 10 min
   - Blue Sheets
   - Minute Takers
   - Agenda Bashing
     Agenda bashing by Jari Arkko. Farid's draft will be presented by Pasi.
     EAP-TTLS draft presentation will not be done, due to Paul Funk not 
making
     it to the meeting.

2. Document Status
   RFCs
   - 3579, 3748
   Recently approved RFCs, in RFC Editor's queue:
   - EAP State machine document
   - EAP SIM
   - EAP AKA
   - EAP over Diameter
   Progressing work on:
   - EAP Keying framework has some open issues and will be discussed today
   - Network Selection will also be discussed today
   - Methods... EAP PAX, EAP PSK, EAP Smartcard, to be discussed
   - Authenticated service identity will also be discussed today
   Other documents, please review:
   - EAP usage in PANA
   - EAP usage in MIP6
   - EAP usage in DHC
   - EAP usage is NSIS
   - EAP usage in ISMS
   - Also ICOS boF discussion at IETF-62 on EAP usage

3. Keying framework discussion (Bernard Aboba), 50 min
   http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-05.txt

   - Drsft 05 is presented by Bernard
   - Russ Housley's requirements were reminded once again
   - Binding key to appropriate context has been the most
     difficult/contentious/discussed issue

   - 7 issues filed in IETF 61
   - closed 4, 3 are open

   - Issue 277: Organization of the document

     Caused by conceptual issues.

     Mixed framework with extensions.

     May not accurately discuss potential discussions, possibly misleading.

     Suggested Resolution: Split the document in two parts

     First one will analyze the existing applications and 2nd one will
     focus on documenting and analyzing the keying framework

     Suggested breakdown is described in details: Key management
     framework (today) and key management extensions (future).

     This will allow us to finish the framework document. Presented
     proposed section breakdown in slides.

     Seek to move speculative discussions out of the framework
     document into the extensions document.

   - Issue 279: Requirements

     Requirements need to be integrated with section 7, which is not
     a trivial task. Ferret out high level criteria
     expansion of the Housley Criteria.

     Need volunteer to review the document. It's a big task Joe
     Salowey and Donald Eastlake volunteered

   - Issue 291: Key cache Synchronization

     Change submitted by Jari Arkko: EAP does not negotiate the
     lifetime of keys, nor do the methods Note disadvantages of
     method-specific key lifetime negotiation.  Breaks method
     independence properties. Proposed to accept, ask for review and
     discussion of other alternatives.

     Proposal: Accept; If people have any any objections

     John Volbretch: Is the intent of the requirement of EAP
     method? In general with the whole keying document, are we
     making suggestions on what methods should do?

     Jari: Methods are expected to provide the key. You should not
     start doing key lifetime in methods.

     John: Is the point to judge EAP methods?

     Bernard: Looking at the Housely criteria, then the following
     requirements come out of this.  Expands to detailed criteria for
     specific modes of EAP usages. RFC 3748 mandates truth in
     advertising, not any minimum level of security. RFC 3748 OK for
     creating keys.  This document helps use keys in a system. 802.11
     requirements document explains the security properties of the
     system. A roadmap for the future, or a cookbook. Does have some
     normative impact for EAP methods.

     Question: Are there advantages to non-method specific
     requirements?

     Comment:  If we knew how to do it...

     Comment: We can do it at the link-layer below EAP.
     There are implications of individual link layers doing key lifetime 
negotiation.

     Question: Don't establish requirements for link layers we don't
     control?

     Comment:  Method specific lifetime probably not desirable.
     Layers that are using the leys are caching them and negotiating the 
lifetime

     Question: Is there a multiple layer conflict?

     Comment: Methods could have different lifetime than the AAA
     server sets.  Because of entropy of the key.  Look at both the
     method and the AAA dictated lifetimes.

     AD Comment: Security problem with the protocol.  We don't have
     the right information to trade-off between not working and not
     secure.  Random hangs because of key expiration are annoying.

     Comment: Limit AAA capability to specific lifetime information.
     APIs?

   - Architectural issue, key cache management.

     Bernard: How is the EAP key cache is managed on the peer and on
     authenticator?  To date, this has been link specific.

     Question:  What happens when a host is multi-homed?

     Answer:  Separate EAP keys for each media type.

     Comment:  Use distinct names for the same key on each media/interface.

     Comment: Creates inter-media handoff issues.  There seem to be a
     number of problems.

     Question:  Is the same key used on different media?

     Answer: The key is not bound to a media, its passed up to the
     server, based on the client and not bound to an interface.

     Comment:  Don't use same key on different interfaces.
 
     Comment:  Not structured as an interface specific cache today.

     Question: Are keys managed by the link layer?

     Question:  Where is the cache, in the EAP layer or in the interface 
layer?

     Pasi: The whole issue depends how you look the EAP layer. If you
     see EAP is above link layer, then it's different. But if you
     think EAP below link layer then the issue came. If you consider
     EAP is a building block then it is link independent

     Comment: Agree with that comment.  Sharing of keys across media
     would need to be addressed in the extensions document.

     Sam: If sharing keys is a problem, look at key derivation
     within the layers using the keys, otherwise security analysis
     becomes media dependent, and gives rise to potential attacks.

     Question: If we have multiple interfaces on the same media, is
     caching for the host or for interface?  Is it for a particular
     media type, regardless of interface?

     Sam: Using the same key with different protocols (media) is risky.

     Bernard: With 802.11 and 802.16 both on the same box, does the
     key apply box-wide?

     Sam: There is a need for cross application security analysis.
     Future media types can compromise existing media types.

     Sam: The context of the Housley Criteria is not specific to media
     types, causing the need for added analysis.

     Comment: Media types need key separation.  Different media on
     different interfaces needs case by case analysis.

     Comment: This is only an issue if you have a key cache.

     Comment: In practice, a key is used in a particular context.

     Comment: The EAP state machine is media independent.

     Sam:  The key is linked to an application.

     Comment:  EAP methods do not pass information as to the application 
that calls them.

     Comment: The AAA server might know the application.

     Question:  But where is the cache?

     Comment: We have security across protocols outside EAP.  Does
     that not create the key association and media dependent keys?
     The client is not responsible for EAP keys.

     Comment: EAP methods create an AAA key.  The AAA key goes to the
     NAS for use in the security association protocol.

     Comment: Operation cannot depend on the media type.

     Comment: The key cache is at the NAS today.  Keys are given out
     for specific purposes. Are some bindings implicit and some
     explicit?

     Comment: That's an authorization issue.

     Comment: Yes.  There is no explicit authorization in the key.
     Attacks likely exist with implicit expansion of key scope.

     Comment: EAP can operate without an AAA sever.  May clarify the
     discussion.  Multiple applications invoke AMSK considerations.
     Make this issue a futures work item?

     Comment:  We need to understand what we have now.

     Comment: We have key caching in the NAS, but at what layer?  We
     don't have key caching at the AAA server.

     Comment: The most difficulty is if EAP is a layer rather than a
     building block.

     Comment: It's still an issue.  We need to explicitly state if an
     application even has caching.

     Comment: Distinct key names for the same keys or different keys?
     The logic of key names is media independence.  If managed at the
     link layer there is little need to name at the EAP level.  What
     good are the EAP key names?

     Comment: What are the key names good for if we don't understand
     that?  Let's remove the names from the spec.

     Question: Is there a true cross-media need?  When do you need a
     media independent key name?

     Mani: Has the PMK caching issue been raised in CAPWAP?

     Bernard: What is a NAS - the thing to which an AAA server gives a
     key, a unique NAS ID - does not matter how many ports it has.

     Comment: Keys owned by the AC for use by any attached devices.
     Not bound to the WTC.  Not bound to an interface on the peer.

     Comment: What about the key names?  If using PSK, then consistent
     naming is not possible because there are separate name spaces.
     Use ASCII format?  Is that too large?

     Bernard: Continue the discussion on the EAP WG list.

   - Roadmap

     . Produce split strawman based on -05
     . File additional issues
     . Resolve issues

     The idea is to bring this document to WG last call by IETf-63

4. Network selection update (Pasi Eronen), 10 min
   
http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-10.txt

   Pasi presented the draft. The draft went to IETF last call. There
   were number of revisions. Not all were resolved. Hope to resolve
   the issues quickly.

   Issue       Status     Type         Description      proposed Resolution
   286       IDSEL-08     Technical    Security Issue   Accept
   287            -10
   290            -10     same         Roaming model
   293            -10 

   - Issue 293: The document does not define the required client behavior

     Additional text is proposed

    Jari: I would like to give some background. Initially 2/3 year ago
    when these drafts were presented all these things were there but
    removed and it is coming again. We are going around in circles.

    Issue raised by Glenn Zorn

    Document is fuzzy about the role of AAA server

    Proper text will be provided and will be discussed in the mailing list

    Some other issues related to grammer and sysntax will be edited 
according to some comments.

    Jari: Please sit with Glenn and make sure that he is happy with the 
changes.
 
5. EAP methods and Methods extensions

   Jari: First some history. Original methods unsuitable for WLAN
   usage Large number of vendor specific, often undocumented methods
   exist. Recently, RFC3748 requires expert review for allocation, unless
   vendor specific. Multiple expert reviews are pending.

   Jari: Is there any interest in standards track methods?  Or leave
   it to the market and other SDOs to decide?  Should the WG undertake
   to standardize a limited number of methods? Chairs think that there
   is a need for few initial interesting methods but the question
   remains how do we select those. Let's discuss after these set of
   presentations.

   Need high quality contributions and folks to work on this and
   agreement on a few methods to work on.  Need for a market demand
   for this work. Recommend a limited number of methods to consider as
   standards.  This would require a charter change. But the decision
   to be made where?  Input form other WGs or other SDOs?

6. EAP PAX (Charles Clancy), 10 min
   http://www.ietf.org/internet-drafts/draft-clancy-eap-pax-01.txt

   Charles Clancy, UMD presented the draft. Described the PAX
   overview. Simple shared secret -key mutual authentication. Extended
   mode of support. Described the changes since -01 and -02
   versions. Complete implementation for -02 version. Free RADIUS
   1.0.2 XSupplicant 1.0.1. tested APs: Cisco AP 1200, HostAPD 0.3.7
   Different timings are also mentioned. Author wants to see this a as
   Stds document

   Glenn: Is the timing measured on the client or server side?

   Charles: It includes both and I am running in the same box. If you
   run in different this can be minimized.

   Jari: Do you have specific application in mind where this could be
   applicable?

   Charles: we have two appendix: This is in particular WLAN
   environment. Shared key bootstrapping

7. Service Identity Authentication (Pasi Eronen)
   
http://www.ietf.org/internet-drafts/draft-arkko-eap-service-identity-auth-01.txt

   Pasi gave the update. He described the background and problem
   again. He also described a one way to fix this.

   Hannes: This is really useful document and this should be accepted
   as WG documents as well. I will strongly vote for this.

   Glenn: So what are we exactly proving here? Why cann't we prove it
   in the first place. How does it know which NAS I am talking to.

   Pasi: What it does is that one NAs get compromised, it can't do
   damage to others.

   Bernard: As I recall there are number of problems here. IEEE
   902.11u announcing the cost, lets assume there is a cost? If NAS
   tells its free, we have an attack.

   Glenn: How do you fix that?

   Pasi: This draft is most useful when you are using EAP for both
   WLAN and other purposes, then this is useful.

   Jari: You are asking how are we doing this? What it does is: you
   are delivering the same information from AAA server both NAS and
   Client. Without additional configuration you can not do more, but
   at least you are making sure that everyone has the same
   information.

   Bernard: there is a way you can go beyond this; via RADIUS server
   authorizing specific usage.

   Joe: One thing I am wondering here: does this introduce any other
   dependencies?

   Pasi: Our draft does not assume that AAA server can be trusted and
   NAS is dishonest. I don't think this introduce any other
   dependencies.

   Jari: What are the next steps? Interest in adopting this as a WG
   item?

   Bernard: There seems to be some interest, please discuss in the
   list and what people think; whether any modification is required.

8. EAP-PSK (Hannes Tschofenig)

   Lightweight method.
   Based on EAP Archie work.
   EAP-MD5 replacement.
   Pre-shared secrets only .
   EAP-AES.
   Only well known security methods, which have security proofs.
   Symmetric crypto.
   Extensible in that it establishes a protected channel that allows 
exchange of information between peer and authenticator.
   No known IPR encumbrance.

9. EAP-IKEv2 (Hannes Tschofenig)

   Powerful method
   Adds support for PKI based authentication
   Design based on IKE v2
   Cipher suite negotiation
   Variable key strength
   Fast reconnect
   Active user identity for initiator, passive for the responder
   No known IPR encumbrance

10. General methods discussion

   John: It might be a good think to standardize the methods because
   if there is a method people and implement and prove that EAP
   works. One of the things is not entirely clear to me is that key
   generation. I am in the favor of a EAP method that is easy to
   implement and has check for certain things.

   Jari: Default assumption is that IETF requirements document (RFC
   3748) needs to be followed but we can go much beyond that if we
   want. Say, we could target IEEE requirements for WLAN. We are not
   talking the mandatory implementation of a method. If we define the
   methods

   Comment: Some other WG could specify a mandatory method.

   John: Not sure what standards track means if it's not required to
   implement?  EAP-PSK seems like a good candidate.  EAP-PAX has extra
   features not required externally.

   Dave: My understanding is that standards track gives you the
   mandatory interoperabity tests bit Information RFC does not.

   Nicole Williams: There are instances where STds track documents are
   not interoperable.

   Mark: It's a nice thing to have multiple interoperability but it is
   not a mandatory for standards track PS RFC. INT area treats it as
   optional.

   Bob: If we gpo down the path we need to identify the
   requirements. There are too many methods and we can go some nasty
   political situation.

   Jari: That's a good point. We may go to a dangerous area. We can take
   two paths: one is to define some IETF requirements and other one is
   to see how these methods develop on their own, by the markets. But we
   have already tried the latter, I think we need some guidance from the
   IETF to converge EAP method usage at least a bit from the current
   situation.

   Sam: It would be good to have some Stds method but I agree 100%
   with Bob. However, I would like to add one thing: I don't know
   whether this is the right place to do this. There are other places
   we can do this, would need a tighter tie to the Security Area if we
   want to do it.

   Pasi: We certainly we have one method that is an RFC, EAP TLS. Might 
not be
   a bad idea to recycle that to a PS RFC from Experimental.

   Jari: Good idea.

   Pasi: I also see some value in defining simple share secret method.

   Majid: What is the relationship with other SDOs? I see .11, .16 are
   also using different methods

   Bernard: If you look at Liaison statements from 802.11, you will
   see they have requested help in the definition of methods. Some are
   done, others are not.

   Jari: Look at these things from top level perspective. There's lots
   of variety in methods including vendor specific and experimental.
   It appears that method quality is tied to the level of
   standardization.  Where does that work happen? Many methods in use
   have not been documented in RFCs.  Looking for convergence going
   forward.

   AD Question: How do we get EAP to Draft Standard without any
   approved methods?

   Answer: We probably don't.

   Joe: Probably we can do this in a different group where there are
   some alignments with other authentication methods.

   Pasi: On the other hand people in this group are working on EAP
   methods.  We can change our specifications.

   Sam: We need more alignment with other security frameworks.  The
   matrix doesn't look real good right now. The approach going forward
   is to unify...  Clearly, coming up with another framework is not
   the right thing.  Elements of technology that can be reused in the
   existing framework would be good.

   Joe: Sam's idea is to unify things and not to create another framework.

   Jari: I am glad to hear that we don't need another framework.

   Sam: We have several frameworks, and perhaps there is a reason for
   that. While evaluating these proposals, there must need minimal
   code changes and useful to the people.

   Hannes: I am little bit worried about this. We have been discussing
   this quite long and that's why I think people are coming with new
   vendor specific methods. Will we make progress on EAP methods?  The
   discussion has been going on too long, and we always postpone it to
   the next meeting.

   Bernard: We have an existing process for publishing methods.

   Question: Do methods need to conform to something other than
   RFC3748?

   Answer:  No.

   Pasi: It is not only the question of whether we can stop or
   not. Some vendors are proposing their methods as proprietary.

   Jari: We have to continue this discussions with AD . At least part
   of the room things that EAP methods are required.

   Bernard: This is interesting discussion.

   Sam: I guess I am not sure who proposes the procedure and type code 
change.

   Jari: We will discuss this more in the mailing list.

11. EAP and the Trusted Computing Group (John Vollbrecht)

   John presented this document. TNC is the sub-group of TCG. It is
   subscription oriented group. TNC is trying to define and promote an
   open network architecture that enables network operator to enforce
   polices. He presented the overview of TNC. It operates in client
   and server mode. Integrity checking is the first step and most
   important thing to start the dialogue. TNC version 1 contains 3
   specs. The interest here is the transport. TNC as part of EAP
   dialog. It may be a method or something else. If the assumption is
   correct, EAP methods can be used within a protected mode. He also
   described how one can do this with the help of EAP by some inner
   methods. Can we take this as WG document/work?

   Jari: Are you suggesting to standardize some inner methods. But we
   have not yet standardize the tunnel methods.

   Answer: No, this is just about the tunnel methods.

   Jari: You also mentioned that TNC is coming to IETF to standardize
   the methods. Do we have a request from TCG to IETF requesting this
   work?

   Answer: We could arrange for that request.  The work in TCG is just
   getting to that point.

12. EAP POTP (Magnus Nystrom), 10 min
    http://www.ietf.org/internet-drafts/draft-nystrom-eap-potp-00.txt

   Dave presented this draft. Part of One-time-Password Spec.  He
   described the state of affairs and goals; End-to-end protection,
   mutual authentication, sports key derivation for 802.1x, minimal
   initial configuration. IPR statement also mentioned.  Trying to
   make it royalty free. He described RSA EAP 32 method and
   computational details

   Russ:  What the heck is pepper?

   Dave:  Pepper is a symmetric shared secret.

   Question:  Why is it needed?

   Dave: Pepper is a randomly generated number.  A server has to
   "grind the pepper" i.e. iterate over the permissible range of
   values to find what matches.  The salt is in the clear.  The range
   of the peeper is communicated across the wire, but the actual value
   is not. An option would be to assign a pepper value and send it via
   AES protection.

   Question:  Does that still leave a key distribution problem?

   Comment: Where do we go from here?  Conduct an RFC3748 review of
   the method?

   Answer: an RFC3748 review would be nice.  Will be advocating this
   method to other token vendors.  Will be using an existing IANA code
   point.

13. EAP Smart Card (Pascal Urien)

   Pascal described the EAP Smart card framework without slides due to
   the time limitations. He emphasized that this is a framework and can
   use many methods. We need a type for smart card.

   Jari: I think you are requesting the review of your document. At
   this moment we need volunteer to review the documents.  If you are
   interested pl. contact either me or Bernard.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 29 Mar 2005 17:14:20 +0200

hi jari,

could you add a link to the eap-psk and the eap-ikev2 slides?

http://www.tschofenig.com/eap/IETF62/eap_ietf62.ppt
covers both: eap-psk + eap-ikev2

ciao
hannes

>From: Jari Arkko <[email-masked]>
>To: [email-masked]
>CC: Bernard Aboba <[email-masked]>,"Nelson, David" 
><[email-masked]>, [email-masked]
>Subject: [eap] draft EAP WG minutes from IETF-62
>Date: Tue, 29 Mar 2005 18:09:16 +0300
>
>          And issues are at 
>http://www.drizzle.com/~aboba/EAP/eapissues.html
>
>   Pasi: We certainly we have one method that is an RFC, EAP TLS. Might not 
>be

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 29 Mar 2005 17:29:49 +0200

hi jari,

ciao
hannes