Subject: [eap] minutes from EAP WG meeting at IETF-60

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Aug 2004 17:32:41 +0300

These are the preliminary set of minutes from IETF-60.
Many thanks to Yoshi and Pete for taking the minutes.
If you find something to be corrected in the minutes,
please let either me or Bernard know so we'll fix it
before submitting it to the proceedings. Thanks,

--Jari

Extensible Authentication Protocol WG (eap)

IETF-60 Minutes, Wednesday, August 4, 2004 at 0900-1130
=======================================================

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

SCRIBES: Pete McCann and Yoshihiro Ohba, merging by Jari Arkko

1. PRELIMINARIES, 10 MINUTES
----------------------------

o Minutes & Bluesheets

o Agenda Bashing

   Jari presents the agenda...

o Document Status

   - RFCs: 3579 (EAP over RADIUS) and 3748 (EAP aka RFC2284bis)
     published.

   - EAP state machine (draft-ietf-eap-statemachine-04.{txt,pdf} in RFC
     editor queue. some discussion on the list.

   - EAP keying framework (draft-ietf-eap-keying-03.txt). One open
     issue about key naming.

   - EAP over DIAMETER [AAA WG]. In second WGLC. Two issues resoved
     during the AAA WG.

   - Network selection problem definition
     (draft-ietf-eap-netsel-problem-01.txt).  Needs one more revision.

   - Netwowrk discovery
     (draft-adrangi-eap-network-discovery-01.txt). Needs another
     revision Targetting indivisual submission process due to tight
     3GPP schedule.

   - NAI update, RFC2486bis [RADEXT WG]
     (draft-arkko-roamops-rfc2486bis-02.txt). WGLC to the end of this
     month. Officially, there are no open issues, but one issue brought
     that needs discussing with international names, IKEv2, and EAP
     strings.

   - EAP Methods [individual]. A large number of methods. EAP FAST was
     reviewed by IESG, needs to be revised, due to TLS extension IANA
     rules.  TLS extension will be submitted separately. 3GPP has
     requiested EAP-level review for EAP-SIM and EAP-AKA I-Ds, which
     have been submitted to RFC Editor and need an AD sponsor review.
     RFC 3748 compliance review by EAP WG would be useful.  Please read
     and submit your comments in the near term to the list We are
     looking for descriptions of all the security properties required
     in 3748 Doesn't do anything broken with respect to base EAP RFC.

     [Joe]: didn't we already have WG/EAP review on these?  [Bernard]: ADs
     want a formal statement they can point to as a reviewer

     [Bernard]: if you want to volunteer to be the expert, come see us.

   - Binding problem definitions
     (draft-puthenkulam-eap-binding-04.txt). Not updated; abandoned.

2. EAP STATE MACHINE, PASI ERONEN, 10 MINUTES
------------------------------------------

o http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-04.pdf

o Status: 2nd WG last call ended in March, during Seoul
   Were some minor comments/clarifications in -03, then
   sent to IETF last call and approved by IESG.  In RFC Ed q, But
   then got a really thorough review by Florent Bersani.
   Issues:

   - 247 and 251: mostly editorial comments. Handled in -04, just before cutoff.

   - 250: technical comments and requests for clarification. Some things clarified in -04; mostly things that could be done one way
       or another. Comment #12 included in 251.

   - 251: "canned" messages. 1X-REV sends canned success/failure. These
     aren't really allowed by 2748, but aren't really part of EAP
     conversation. Perhaps using eapolLogoff would have been better,
     but too late to change now. Conclusion: no change?

     [John Vollbrecht]: Thinking about this, if I send a success/fail, nothing bad
     will happen.  Fail: nothing bad, success: client might attach when he
     wouldn't.

     [Pasi]: No, because when you send success, the port would have been disabled,
     so there is no conversation.

     [John Vollbrecht]: If he was in the middle of something, he might
     connect somebody: failure/success results might be ignored.

     [Pasi]: Right thing is to ignore them, not send anything.

     [Bernard]: If you are disabling the port, you want to kick the guy
     off probably lower layer message would be better.

     [John Vollbrecht]: Not an IETF issue, it is an 802.1x issue, they
     might or might not do something about it.

     [Pasi]: They are aware of it.  Nothing breaks in the real world
     because of this.

     [Jari]: Right, but there is a nother part that is when 3748 allows
     you to send canned success message.

     [Pasi]: Issue 251 in peer state machine: Reading 3748 carefully:
     sending success/failure immediately after identity
     request/response is allowed, not the same as canned it is even
     mentioned in an example. Of course, in many cases peer would have
     a policy that it must authenticate The state machine allow this,
     so no change required

     [John Vollbrecht]: Point on the list was that if you are going to
     allow this without requiring an identity, I don't understand.

     [Pasi]: But that is something in 3748, and this document is not
     going to change that.

     [John Vollbrecht]: If I have to wait for Identity for guest
     access, it's just weird.

     [Pasi]: No one is going to use it.

     Issue 251 in authenticator state machine: Auth state machine does
     not prohibit canned messages Proposal: add "Policy.getDecision
     MUST comply with RFC 3748 restrictions about canned Success and
     Failure messages.". This was intended, can we do this at AUTH48?

     Next steps: Publish this as RFC. Postscript/PDF version requires
     some work by the authors.

3. WLAN REQUIREMENTS, 5 MINUTES
-------------------------------

o http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-02.txt

o Individual submission being discussed on WG mailing list

o Status: been through IETF last call One action item left, issue 243,
   clarification of state synchronization Each time it is changed,
   dorothy has to go to 802.11 to approve the change.

   [Dorothy]: Right, but I think we're done now [laughter].

   [Bernard]: We sat down and tried to resolve Florence's 243: Using
   term "shared state equivalence" instead of "synchronization" Now
   says the state must be "equivalent" instead of "synchronized" Rest
   of language is more or less unchanged does not include state
   external to the method ...

   Is there any objection from the group to going forward?

   [Jari]: Pay attention to the words "terminates successfully ON BOTH SIDES".

   [Bernard]: Yes.  Florent came up with examples where they didn't
   complete successfully on both sides and they wouldn't know..
   Dorothy, you will have to decide whether this is editorial or not
   editorial We hope this is the last time

   [Hannes]: Might be editorial in this document, but whole discussion
   has implications to many EAP methods.  We had to add a new message.

   [Bernard]: We couldn't think of any EAP method that didn't do this already.

   [Jari]: There always seems to be a message that isn't called synchronization but
   which in practice does this.

   [Joe]: Original had "protected result indication" which might be the complaint.

   [Bernard]: Right, we think this can be done.  Don't want to
   disqualify all existing EAP methods. Hopefully this is the last
   we'll ever hear about this.

4. EAP KEY FRAMEWORK DRAFT, B. ABOBA, 30 MINUTES
------------------------------------------------

o http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-03.txt

o We've done 2 revs since IETF59 (02 and 03).  Hopefully most of the
   material is in there now.  We should make it readable and then have
   a disucssion on what it actually says Some of the key naming and
   lifetime issues are more important as people start to implement
   802.11i.

o The Participants diagram. Both peer and authenticator may have
   multiple ports In many dial-up situtation you can have multiple
   phone numbers true of other link layers as well. Conversation/keys
   are not bound to a particular port This has caused some confusion.

o Conversation Phases. Discovery is lower layers, authentication is
   EAP, AAA transport is AAA, SA establishment is lower layer.
   Discussion about what happens at each phase is important for key
   management/caching

o The Conversation. 3 party message flow diagram.

o Requirements were outlined by Russ Housley at IETF56
   All AAA WG documents need to meet these requirements
   EAP Key Management framework defined to help

   List of housley requirements on 2 slides

o A bit about naming: this is all about cache management, there seems to be
   no other use.  Allows peer and authenticator to have a conversation about
   what keys are in the cache.  There is no need for an authenticator to
   request a key from the server.

   [Joe]: Wrt naming session keys, requesting keys by name, in general context of
   network access that's true; but, there may be cases where there are keys
   derived from an EAP session that need to be named.

   [Bernard]: So when we discussed in AAA, we decided this isn't an EAP thing
   it is an application thing.

   [Joe]: But the name comes from EAP, even though at that point EAP is
   not running.

   [Bernard]: Requirement is uniquely name session keys, but we don't
   think of those as being cached.

   [Hannes]: "Naming of a key" is a bit confusing. In the literature,
   in MIKEY, for instance, it means you must attach the identity of
   every key in the key exchange.  Depending on the definition, some
   issues are fulfulled in EAP and others are not.  I came up with 3
   definitions for what it might mean.

   [Bernard]: Send it to the list, we will discuss each of those
   issues.

   [Hannes]: Helped to find some issues in PANA case.

   [John Vollbrecht]: Seems like there are cases where EAP might be
   given a key, then do an exchange to bind something to the key as
   opposed to create the key and give it to somebody.  E.g.,
   Diffe-hellman then bind key to authentication afterwards.  Not
   always EAP that's giving the name.

   [Bernard]: We have to distinguish long-term secrets from actual keys
   developed by EAP.  Key thing is that you don't name things you don't
   have to refer to.  I don't name my toenail.

   [John Vollbrecht]: agree, but if I were to try to bind an authentication of the user to
   an already established key, e.g., session key, might want to give name of
   key to EAP method...

   [Bernard]: Let's have in the discussion on the mailing list specific examples
   so that we can understand

   [Jari]: One example is the resume function in EAP-TLS

   [Bernard]: Right, method-specific stuff.  Examples will help understand

o Another Russ requirement: compromise of a single NAS does not
   compromise the system.  Note that a single NAS can have multiple
   ports.  Binding requirement relate to channel binding.

o EAP Invariants: Media, Method, Ciphersuite independence.

o Types of EAP Keys. Tried to be more explicit in the document.

   - Keys calculated locally by EAP method but not exported
   - Exported keys
   - ...
   - Transient Session Keys

   New key hierarchy diagram in the document.

o Key Naming:
   - MSK
   - EMSK
   - AMSK
   - AAA-Key

   - Key Name Characteristics
   - Key Name is NOT based on key itself, unlike in 802.11i
   - Key name used for cache negotiation between peer and authenticator
     we need to understand what else used for and why AAA server
     provides key name (and AAA-Key) to the authenticator, they
     are not kown prior to this
   - Key name sent to the authenticator as part of the EAP exchange

o Key Liftimes: One of the harder to understand issues.

   - Management: Negotiation vs. out-of-band.

   - Resource reclamation: NAS are quite tiny, key caches fill up.  How
     to synchronize the state?

   - Transient EAP Keys (TEKs):

    . Internal to the EAP method. Valid only for the duration of the EAP conversation.

       [Someone]: You can have cache strategies related to method...?

       [Bernard]: Have to clean up and distinguish between cacehd and not-cached

   - MSK, EMSK, IV: how long do they live? When the MSK ends up on the authenticator (or things derived from it)
     its life is defined by Session-Timeout, so can be controlled on a per-user
     basis by AAA server.

     [Jari]: In addition to not having re-key, you cannot delete
     because EAP is not running.

     [Bernard]: You could kill the session or cause re-auth.  When it's
     not in use, then life gets more complicated Distinction between
     re-key of MSK (only possible on re-auth) vs. re-key of TSKs which
     can happen without re-auth.

     [John Vollbrecht]: would help to distinguish between what EAP does
     (creates keys, exports keys, refresh TEK) but it doesn't do
     anything else.  So all other re-key is external to EAP.  A lot of
     the discussion is "how to use EAP in the context of keys" But we
     should distinguish between general key things vs. EAP things.

     [Bernard]: Need to understand what there is to manage (SNMP, AAA
     variables) e.g., there is no AAA attribute to tell NAS how ofter to
     re-key without re-auth.

     [John Vollbrecht]: that's an issue with AAA not having a way to do
     that, isn't EAP issue.

     [Bernard]: Right, but this doc has system-wide charter.

     [John Vollbrecht]: Right, but should be split.

     [Bernard]: Just got into this on -03, new section, but it's
     important that we get things right.  Re-key of TSKs is separate
     from the MSKs, not an attribute today (maybe it should be).  We
     don't have any way of, if keys are setup at pre-auth, how long
     they live or how long they stay after session ends (Session
     Timeout is only after session is connected).  We don't know how
     long the EMSK is kept on AAA server.  If we knew these lifetimes,
     then derived keys would be no longer than that.

     Thoughts: EAP methods don't negotiate lifetime of exported keys
     e.g., EAP in IKEv2, there's no notion of MSKs, EMSKs living inside
     IKE.  Having EAP negotiate some value wouldn't be helpful because
     it depends on whether lower layer lets them live or not.  EAP
     itself doesn't do it either.  SA protocols don't either.  Should
     they?  Well, there's a potential gap between EAP and SA.  802.11i,
     secure association protocol may run hours later.  Not that many
     choices.

     Do it inside lower layer encapsulating EAP? (then not secure)
     Discovery based solution (e.g., broadcast global key lifetime)?

     [John Vollbrecht]: Seems that if I'm creating a key, I would create the lifetime if there
     was going to be one.  Otherwise there is no control.

     [Bernard]: Can't do that because lifetime depends on lower layer
     and EAP methods are media independent.

     [John Vollbrecht]: Why?

     [Bernard]: media controls caching

     [Somebody]: not EAP methods responsibility, AAA protocol would
     tell you with Session Timeout.  For MSK & EMSK, AAA server may
     have its own policy.  For sub-keys you can just try them and they
     might fail.

     [Bernard]: Real difficulty is between authenticator and peer.  AAA
     server can always attach lifetimes to authenticator.

     What I think we can conclude:

     . On AAA server, this is a system parameter.
       How do you sync it up in the system?  Can at least send to authenticator.

     . If you don't have anything in lower layers (e.g., SAs) what do you do?

     . How does the STA know whether a particular key is in there or not?
       * should assume some default value
       * if it is a big mismatch, there would be problems

     . Maybe manage TSK re-key time as a distinct thing from session time

     . Not always clear that AAA management of exported keys is good,
       especially if server is unaware of NAS resource constraints.

       If NAS is in a resource reclamation situation, STA cannot find
       out what keys are there and what are not.  Per-user key
       lifetimes might actually make things worse.  Maybe a default
       lifetime would make it more likely to be in sync.

     This whole area is something we need more discussion on the list
     It is important as people develop key cache management for 802.11i

     [Paul Funk]: The question of key naming: you suggest independent, why?

     [Bernard]: Russ's original guidelines were about the idea of hierarchy, and
     that you are always able to name everything.  There may be some
     issues about revealing some information about a pre-shared key.
     It's clear that if it's based on the key, you can't know it until
     you have the key.  This would be a limitation.  Draft needs more
     work on key names and key lifetimes, we can contribute to better
     understanding.

5. EAP NETWORK SELECTION PROBLEM STATEMENT, J. ARKKO, 15 MINUTES
----------------------------------------------------------------

o  http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-01.txt

o History, basic problem, issues

o History and status -00 created based on EAP discussions based on
   Farid's contribution During last few months, we've had some additional
   work:

   - NAIbis in radext
   - Farid's EAP network discovery
   - Groeting draft and implementation
   - IEEE WIEN network selection
   - 3GPP network selection work

   Draft-01 updates problem definition based on discussion and external events

o Recent developments

   IEEE 802.11 WIEN study group formed.

   Liaison letter received from 802.11 chair, requesting review of
   network discovery docs Plan

o Way forward:

   Issue another version

   Request feedback on problem statement document from 802.11i

   Last call

o Technical stuff: There's actually multiple problems

   - Access network discovery: which network to attach to?
   - Identifier selection: which NAI?
   - Roaming intermediary problem: how to route the request to the home AAA?
   - Payload routing: if there is tunneling, how do we direct the traffic

   - Other decompositions: Discovery, Decision, Indicating decision to selected network (attaching)

   - Another decomposition: Type of information discovered: Access
     network identity, roaming agreement, QoS parameters, ...

   - Some earlier findings:
     . All the problems are relevant, and new solutions are needed
     . Yet, problems in the presence of large numbers of networks, fast handoffs,
       they are hard
     . Would be bad to have multiple competing mechanisms
     . Need to produce some early simple solutions and then maybe produce some
       full-blown schemes later

   - A few issues...

     . Scope of Information. Haven't considered how much information is
       necessary In future, ideal network selection scheme would
       include, e.g., whether there are middleboxes, service
       parameters, QoS, cost, etc.

       EAP is an unlikely carrier for this information because of the
       amount But is there a relationship between advertising/verifying
       this info and EAP?  There might be a security requirement to
       verify advertised parameters One potential way is to verify
       these things through channel bindings.

       Proposal: tell in the document that there are these different pieces of
       potentially useful information, point out security consideration, mention
       possible role for EAP.

     . Relationship between mediating network discovery and identifier selection

       Bernard's observation: both mediating networks and identifiers
       are represented in same data item (NAI).

       Maybe EAP network discovery advertisement would work as a hint
       for selecting identifier, not just for routing.

       Proposal: Document in farid's document.

     . Need to document better work going on in other SDOs (e.g., IEEE)

  o Anything else?

   [Blair Bullock]: Compelling models, proprietary ones, that we might want to look at.

   [Jari]: Would be good ot have references and short descriptions

   [Blair Bullock]: XML transport, etc... lot of good systems out there.

   [Blair Bullock]: on EAP validating parameters, how far do you intend
   to go?  There's the "asseration by this org" and then "truth".

   [Jari]: There is a limit to what we can do in EAP in terms of
   parameters; we don't want to start transfering XML documents with
   pricing information.  I don't think we can verify whether info is
   the truth.  What we can do is verify that whatever you tell to the
   client and what the home network and the access network believe is
   the same thing.

   [Bernard]: This is a synchronization problem not a verification
   problem.  As we discus in channel binding of 3748, it's possible for
   the authenticator to tell one thing to the peer and another thing to
   the AAA server (i.e., "I'm free" vs. "I'm $5/minute").

   [Somebody]: Should provide that framework of disclosure through the
   home system.

   [Jari]: Right, one possible transport.  Whatever real-life verification happens
   after that is not a protocol issue.  If you get a bill you can complain.

   [Somebody]: The channel should be there.

6. EAP NETWORK DISCOVERY, F. ADRANGI, 10 MINUTES
------------------------------------------------

o http://wwww.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-01.txt

o Draft to meet 3GPP requirements.  This focuses specifically on
   network discovery. Version -01.

o Main changes:

   - Describes a solution for mediating network discovery only,
     references 2486bis for network selection part

   - Draft was shortened and restructured for readability

   - There was an implementation of this draft, provides proof-of-concept

   - Recently got several comments from bernard. Some resolved in 01,
     but there remain some issues to be resolved

o Outstanding issues:

   - Problem should be referred to as "identity selection hint" instead
     of "mediating network discovery"

   - Coexistence of mediating network information with existing
     proprietary info in the IdentityRequest.  We already have
     addressed that, but haven't posted draft yet.

   - Error handling and recovery for cases where the access network
     cannot route the AAA traffic (e.g., supplicant did not provide
     decoration).

   - Bug in definition of "realmlist" ABNF

   Main problem is the first one: changing name is going to require
   rewording work throughout the draft.  That's something we can
   discuss and decide how to proceed.

   Need to meet release deadlines for 3GPP release 6 (december) We need
   to get this done by September Want to resolve all open issues by
   August 15 Submit for final review on the mailing list

   [Someone]: First bullet is right on, identity selection is part of
   the process of constructing an NAI.

   [Farid]: Yeah.  That's our plan to reword and make it more generic.

   [Bernard]: Logic is that 802.11 has gone over very carefully to make
   sure there is no conflict with what they are doing, want to make
   sure there is no impact on what they are specifying.

   [Farid]: Will not impact the underlying protocol this is more like
   presentation and positioning in the draft.

   [Bernard]: Only comment is that this draft should be sent to 802.11.

7. EAP METHODS PUBLICATION PROCESS, CHAIRS, 5 MINUTES
-----------------------------------------------------

o Goal: Review the current rules for EAP method publication.

o History: In 2284, there were no IANA considerations (oops).  It was
   free for everyone to define what they wanted.  In 3748 there were well
   define rules.  In discussing what is going on, many of these proposals
   have been around for years.  Some already have a type code allocation
   done prior to adoption of new rules.  Any new methods have to comply
   with the rules.

o Case 1: old methods. IANA acted on FCFS basis
   No spec required, no IETF approval
   A lot of vendor-specific methods
   A lot of them no longer in use.

o Case 2: leftovers from old times. EAP methods currently in process,
   they have a type number. If this is the situation, the regular IETF
   rules apply. In order to publish an IETF document you can do that
   Information, document your protocols as long as you are not trying
   to circumvent process in competition with a WG. If it is a
   standards-track item, you need to have an AD sponsor or WG draft.
   In any case, regardless of EAP methods, other IETF rules have to be
   obeyed e.g., TLS extension must be standards track.

o Case 3: New rules in 3748. You can do vendor-specific methods, or
   request Expert Review.

o Case 4: standards track methods.  WG items or AD sponsored. Some
   question as whether the EAP WG should do this Some interest, ADs
   somewhat positive. We need some high quality contributions to move
   forward We have some good-quality proposals in this space.  We need
   people willing to work on these documents to completion We need a WG
   and a world who cares about new methods and would actually use the
   results

   [Someone]: Document the requirements of standard EAP methods?

   [Bernard]: We've asked various SDOs for their requirements.
   Sometimes, they say, "WLAN works for us to".  3GPP said "we have our
   own requirements".  IESG says it's not one size fits all, so it's
   not just one Proposed Standard.  It's ok to let each group define
   their own requirements.  That's the reason we have the security
   claims in 3748.  We don't have any list of things that a PS must do,
   it must authenticate and derive a key in a reasonably defensible
   manner.

   [John Vollbrecht]: one issue was whether there would be a "MUST
   implement" method for e.g., testing

   [Jari]: We can have that disussion when we have reasonable methods.

   [Bernard]: What came up was that we were requested by 802.11 to
   change the mandatory to implement method in 3748.  We decided not to
   do that.  Other SDOs are free to set their own requirements.

   [Jari]: If you have a method you believe is worthy of standards
   track, it is your job to propose it and convince us.

8. AUTHENTICATE SERVICE IDENTITIES FOR EAP, PASI ERONEN, 10 MINUTES
-------------------------------------------------------------------

o http://www.ietf.org/internet-drafts/draft-akko-eap-service-identity-auth-00.txt

o Background: EAP does not have a concept of service (NAS) identity
   (identifier) Since there is no identity, it can't be authenticated.
   The "lying NAS" problem. When you look at the whole system, protocol has
   3 parties, but no identity for NAS End result is that client knows
   it is talking to one NAS, but doesn't know which one If you
   compromise one NAS you can impersonate any other.

o One approach: channel binding. Send an identifier inside some EAP-protected field;
   AAA server has to verify that node it is sending the MSK to actually owns this
   identifier.

   [Glenn Zorn]: Your trivial consequence I didn't understand.  It's
   true that the client doesn't know the identity of the NAS, but what
   difference does it make?  someone: if there's no underlying trust,
   the client only needs to know that it's getting service.

   [Pasi]: Right, the reason no one has tried to solve this yet is because the internal
   structure of the network is not visible to clients.

   [Glenn Zorn]: It's not possible for someone with no identity to impersonate someone with
   no identity.  Although you've compromised a NAS, you cannot impersonate it
   *to the server*.

   [Bernard]: Conversation is between peer and server, so the only bad consequence would
   be some server impersonating another server.  This is not an EAP vulnerability.

   [Someone]: Perhaps it's not the NAS identity but the network identity

   [Bernard]: No, server identity.  It's a conversation about a server that distributes
   some keys that may then make its way to your network.

   [Pasi]: The client is interested in service identifier, not necessarily NAS identity:
   - SSID
   - BSSID
   - AP IP address
   - AP DNS name
   - Human readable "network name"

   Depends on what you want to do.

   [Someone]: Also depends on when.  If it's subnet, you're already
   attached.

   [Bernard]: There's identity of NAS for purpose of deriving a key.
   When you go to another NAS you need to know what keys it might have.
   Then theres the service identity which is something else.  Some of
   the identities do or do not identify an authenticator (NAS)
   independent of ports, others are dependent on ports.

   [Someone]: Why not separate this into AAA group vs. EAP requirements for key
   mobility.

   [Pasi]: From client viewpoint, it is trying to authenticate some of
   these identifiers someone: all you have is a secure EAP transport.
   You are trusting the chain.

   [Bernard]: We are getting confused.  When you make a claim of identity, the subsequent
   exchange confirms the identity.  Service identifiers are different.  You can
   confirm them but not solve the lying NAS problem.

   [Hannes]: You find some of those things already in some EAP methods.
   That may be the solution we want to go to.

   [Pasi]: So identifiers may identify larger part of the network bigger than a NAS
   This draft defines some example identifiers, how to embed them in lower
   layers.

   Example: Identifiers for 802.11. This prevents IKEv2 gw from impersonating an AP.

   [Glenn Zorn]: Probably also the lack of an antenna.

   [Pasi]: We assume one NAS might be compromised, this prevents that.
   Idea is to do it the same way for all EAP methods.

   [Someone]: this provides the inner secure channel.

   [Jari]: This defines an extensible data model and some initial
   parameters.  It could be used for carrying any kind of information.

   [Somebody]: Same trouble that Glenn had understanding... if you have mutual auth
   with a server, and server vouches for device, isn't that good enough.  If I
   go to a payphone, do I want to authenticate model of payphone?  It's the carrier
   that I have the relationship, not the piece of hardware.  Providers can switch
   hardware on short notice, how would i judge that?

   [Pasi]: Example for 802.11i is that this AP is allowed to use this SSID.
   If you are not interested in the internal structure of the network, then
   this is not useful to you.  But, if you are using EAP for WLAN and also
   for some other credentials for VPN, you don't want APs to impersonate the
   IKE gw.

   [Someone]: in the payphone, there is inherent trust in the infrastructure. In
   wireless, that trust is no longer there.

   [Glenn Zorn]: So lemme see... in the model of the attack that you're trying to fight,
   the AP has been compromised.  You don't trust AP/NAS to tell you who he is.
   Who is vouching for this identity?  If this NAS is part of the network,
   he has impersonated himself or someone else to the AAA server.

   [Bernard]: authentication is not the issue, it is service parameters

   [Pasi]: You have a NAS that has been compromised but gone bad, the AAA server
   has no way to know that.

   [Someone]: In a larger network, if you have partitions, e.g., Europe and US
   where SSIDs are shared, you need to make a client decision.  Could this
   be used to help?

   [Pasi]: No, not easily.

   What next?  Comment welcome. Lying NAS problem has been discussed in
   a lot of EAP keying discussions.

   [Jari]: The consensus was that this problem was not important to solve in
   3748, but it is still important for some people and some situations.

   [Bernard]: with network selection where money is on the line, then
   this may become an issue.

   [Jari]: Two questions: 1. do you need the function? 2. if yes, then different
   ways of doing it.  Right now tunneling methods have their own attributes
   for carrying information like this.  That is problematic in the sense that
   different EAP methods look at information in different ways, more code,
   less interoperability.  If tied to specific link layers, then methods
   might start to become link-specific.  Should we have something general?

   [Glenn Zorn]: Pasi got interrupted... how do you trust the
   information that you get back in these AVPs, given that you only
   have a relationship with AAA server?  AAA server can tell you who
   the NAS is, as far as he knows.  NAS can tell you the same thing.
   Who is vouching for identity of NAS, and how does he know it?

   [Pasi]: AAA server is vouching and telling info to hte client.
   Client believes AAA server more than he trusts the NAS.

   [Bernard]: this is one of the key framework issues:

   [Someone]: NAS can have a different identity on client side vs. AAA
   server side

   [Bernard]: That is a part of key framework doc, should be discussed
   there.  Theres a distinction between the identity and the key scope.
   When you give the key, it's for the NAS that's identified.  There's
   a problem of key caching which is what the AAA server sees
   vs. client sees.  What this leads us to believe is that people have
   not read the key framework draft as closely as possible.

   [John Vollbrecht]: Seems like you want some sort of little extension
   to EAP that you can tag on or not tag on

   [Jari]: almost like that, just an attribute

   [Someone]: as opposed to overloading something to get the same result

   [John Vollbrecht]: could think of it as a hunk of a script.

   [Joe]: I don't want to have EAP methods evaluate these conditions.  Having an interface
   from an EAP method to the AAA server so someone else can do evaluation is better
   than put this in an EAP server.

   [Pasi]: That's the idea that the EAP method wouldn't use this, but because EAP server
   and AAA server are same box, that's implemetnation that IETF doesn't usually
   touch.

   [Joe]: There's separation of those two things in many of our documents

   [Glenn Zorn]: EAP documents says the EAP server and AAA server are not identical.

   [Pasi]: Right but interface is not specified in any IETF protocol.

   [Somone]: Assuming this is useful, it fits into general channel binding problem,
   shouldn't we have a generic solution for all channel binding solutions?

   [Pasi]: This is the generic channel binding problem.

   [Somone]: Then it's not just the identity.

   [Pasi]: In all the examples, parameters are identifiers, but you could use if
   for cost or whatever.

9. SHARED-KEY EAP METHODS, F. BERSANI, 10 MINS
----------------------------------------------

o  http://wwww.ietf.org/internet-drafts/draft-bersani-eap-synthesis-sharedkeymethods-00.txt
    http://wwww.ietf.org/internet-drafts/draft-bersani-eap-psk-02.txt

o Shared key methods and Updates on EAP PSK

   Overview of important EAP pre-shared key methods

   MD5 challenge is deprecated

   There have been many individual submissions, none given official WG status

   Point: we need to develop pre-shared key method We don't have any
   official WG doing EAP methods It's like a pizza without toppings

   Why special pepperoni preshared key topping?  It is the simplest
   one.  Before we do PKI, credentials, etc, we should have simple
   solution

   We want to make sure we have methods that work well and address some
   links out there Pre-shared keys seem to fit many deployments: My
   home network, Small businesses

   What do we want to do?

   Jaris' presentation is good news

   Want to help

o Trying to start the joint work.  Defining what EAP methods should do
   Do we want pre-shared key or password methods?  Password is a weak
   pre-shared key.  There are different techniques zero-knowledge
   password protocols are very IPR encumbered.  Conclusion: Pre-shared
   key would be a good start.  Passwords are a little more complicated.

   Lightweight: use only symmetric cryptography?  Conclusion: Yes,
   although some phones out there run TLS today

   [Someone]: Can you clarify your definition of the difference between
   password and pre-shared keys?

   [Florent Bersani]: Depends on resources of hacker.  A pre-shared key is not obtainable
   by brute-force attacks now or in a few years.

   [Someone]: You mean pre-shared key is used in some algorithm rather than just
   a raw password?

   [Bersani]: If you use PSK with some 128 bit key, then it is not attackable
   by dictionary attacks or other means.  If you use a password, then the
   PSK cryptography cannot protect you.  0-knowledge crypto can protect
   you (e.g., Bellovin and Merit) in the case of passwords.

   Standalone: why develop methods that accommodate various types of credentials:
   isn't it redundant with EAP?  Maybe add pre-shared key to TLS or other
   "monolithic" method?

   [Hannes]: Big in terms of large in code size.  If you use EAP-PSK vs. TLS bits
   on wire might not be a big difference.

   [Bersani]: True, if we develop EAP methods somewhere, will we develop a big method
   or separate method that can handle different situations.

   [Someone]: The two approaches are not exclusive.

   [Florent Bersani]: Available quickly: people don't want to wait anymore (it's been a long
   time).

   IPR free

   Secure

o EAP PSK Status:
   - proposed open solution
   - draft-03
   - free implemetnations at http://perso.rd.francetelecom.fr/bersani/

   Next steps
   - slightly re-work based on feedback from cryptographers
   - New version -04 in Sep

   Then, after security review
   - go informational?
   - Will there be a standardizaiton effort?

   Some more points...
   - EAP-PSK was designed to be quick
   - Some extensions are possible
   - Key management can be added (updating keys, etc)
   - EAP-PSK includes no options for its security
     when you claim security, you need to say which setting of options
   - EAP-PSK always perform mutual authentication
     some people argue about mutual auth vs. authenticated key exchange

10. EAP PAX, T. CLANCY, 10 MINS
-------------------------------

o http://www.ietf.org/internet-drafts/draft-clancy-eap-pax-00.txt

o Similar to PSK:
   - Bootstrap key authentication using simple credentials like 4-digit PIN
   - Keep it simple
   - Provide support for key management
   - Provable security

o PAX is 2 separate protocols
   - PAX auth
   - PAX update

o PAX auth is a 1 round HMAC-based client auth
   - Optional server-side cert for identity protection
   - Secure under standard model

o PAX update is a 2 round mutual auth diffie-hellman protocol
   - Only used when key update is required
   - Optional server-side certs provides identity protection and security
     against deictionary
   - Secure under the RO model

o PAX auth message flow
   - Server sends nonce + cert, client sends another nonce ahnd HMAC, can encrypt
     with server's public key
   - DH exponent echanges
   - Acks
   - Key derivation

   - Cryptographic primitives: Extensible. Currently supported: HMAC:
     HMCA-SHA1-128 DH: 3072-bit MODP Group 2048 bit public key

o Other work:
   - EKE, SPEKE, SRP: auth schemes secure against dictionary attacks; IPR issues
   - TTLS: slow; require public key operations for every authentication
   - PEAP: cumbersome; provisioning mode not secured against dictionary attacks
   - PSK: no support for passwords; no key management

o Conclusion: Looking for feedback

   [Glenn Zorn]: TTLS slow & requires public key...?  In order to
   protect against dictionary attacks, don't you need public key?

   [Clancy]: only on the first time.

   [Glenn Zorn]: but update is a D-H.

   [Clancy]: if you want to call D-H public key, then yes... but no
   certs.

   [Someone]: PEAP provisioning mode not secure...? PEAPv2 supports 2 modes,
   can use anonymous D-H.

   [Joe]: EAP-FAST has a provisioning mode defined very similar to this.

   [Hannes]: EAP-IKEv2 provides same capability but with different names

   [Joe]: Claim of mutual authentication, looking at the protocol, it didn't
   seem that you actually had.

   [Clancy]: only claimed mutual auth for the update protocol

   [Bersani]: Do you have an implementation?

   [Clancy]: Working on it, working on open RADIUS and 1x implementation

11. EAP TTLS, P. FUNK, 10 MINS
------------------------------

o http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-ttls-05.txt

o Version 1 of EAP-TTLS

   Version field defined in very first byte, similar to what other
   tunnel protocols do.  Version negotiated by client telling what he
   can support.

   New features of protocol are for precluding mitm attack described by
   key binding attack (draft abandoned, but attack still valid)

   Idea is that you have to bind session keys inside the tunnel with the
   keys that are generated outside the tunnel so that you can't inject
   an MS-CHAP inside a tunnel from an unsuspecting user who's not using
   a tunnel.

   Old version did not have a cryptographic confirmation that everything
   went ok.  Now it is so you can't have truncation attacks.

   Normally, the AVPs occur after the TLS handshake.  We want to create
   an extension of TLS to allow AVPs within the handshake.  So, you
   can use it there and then the data phase can be used for something else
   (e.g., HTTP)

   - TLS "InnerApplication" Extension (TLS/IA)
   - TLS handshake is multi-phase.
   - Two phases:
     Initial phase (handshake)
       ends in a "phase finish" message
     Application phase (carries AVPs)
       ends in ordinary finish message
   - Master key is permuted in every phase
     The one generated in the handshake is not the final one for generation
     of EAP MSKs
   - Data phase doesn't exist in EAP TTLS but would in HTTP

   [Someone]: What is the benefit?

   [Paul]: One advantage is that there is a more natural way to bind
   inner session keys in a TLS kind of way.  What we really want is an
   extension of TLS that can do EAP.  Now you can have many protocols
   that utilize it to do authentication.  Becomes more general than
   just an EAP method.

   Session Key binding:
   - Inner session keys are mixed into master key and:
     Confirmed by finished message
     mixed into outer session keys (e.g., MPPE keys)
   - TLS master secret permutation
     Initial master key is derived as usual during initial handshake phase
     Master key is permuted at the end of each applicati onphase
       PRF is applied to create 48-octet vector
       Any inner session keys developed during this phase are arithmetically added to vector
       Result is new master key
     Master key at end of final phase is actual master key for session

   Advantage comes when hacker has cracked the server private key. In
   that case, he would be able to decrypt master key and all the data

   - Success/Failure confirmation:
   - Handshake message confirmation
   - Each phase finished or finished message confirms
   - handshake messages in current and all previous handshake phases
   - Inner authentication confirmation
     . Success is signalled by exchange of Finished message
     . Failure is signalled by TLS failure alert

   Other uses of TLS/IA
   - AVPs can be used for all different purposes (key exchange, provisioning VPNs,
     etc)

o IETF Plans
   - Split into 3 drafts
     . EAP-TTLS v0, which is deployed and has several interoperable implementations
     . TLS/IA, the Inner Application extension to TLS
     . EAP TTLS v1, specified as an encapsulation of TLS/IA
   - Submit each draft for RFC proposed standard status (weather permitting)

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