Subject: [HOKEY] Interim Meeting Minutes

From: Charles Clancy <[email-masked]>
Date: Wed, 24 Jan 2007 19:30:50 -0500

Attached are the interim meeting minutes.

The group came to a variety of conclusions during the interim meeting.
I'm going to post them as separate threads in order to facilitate
conversation.

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy

IETF HOKEY adhoc Meeting January 23, 2007 at Cisco, San Jose 

Attendees:

	Charles Clancy (co-chair, DoD)
	Glen Zorn (co-chair, Cisco)
	Dan Harkins (Tropos)
	Vidya Narayanan (Qualcomm)
	Lakshminath Dondeti (Qualcomm)
	Yoshihiro Ohba (Toshiba)
	Subir Das (Telcordia)
	Madjid Nakhjiri (Huawei)
	Russ Housley (Sec Area Director)
	Kapil Sood (Intel)
	Meiyuan Zhao (Intel)
	Rajneesh Kumar (Cisco)
	Gabor Bajko (Nokia)
	Ran-Fun Chiu (HP)
	David Perkins
	Michaela Vanderveen (Qualcomm)

Morning Session (9:00am – 12:30pm)

a. Agenda bashing

b. Draft-clancy-hokey-reauth-ps -> draft-ietf-hokey-reauth-ps

   i.   It is a fusion of draft-vidya-eap-reauth-ps and 
        draft-nikhjiri-aaa-req
   ii.  Use no new terminology other than RFC 3748/EAP Keying draft 
        terminology
   iii. Authenticator is a logical entity, but can be multiple physical 
        devices.
   iv.  Use of NAS has been removed from the problem statement.
   v.   Lower layers have differentiated the different functions within 
        the Authenticator.  Multiple physical entities create a problem 
        of channel binding, as the identity of the WTP and AC can be 
        different.  EAP Peer talks with WTP and EAP Server talks with 
        AC.  EAPOL terminates at the AC, so AC is the Authenticator.  
        Dan: Won’t channel binding fail if not all entities are bound.  
        Madjid: Channel bind to all intermediate entities.  
        Vidya: Reauth server should bind the keys to the new local (EAP) 
               server.   
        Madjid: All entities need to be tied in and gets rid of lying 
                NAS problem.
   vi.	Vidya: Suggestion to keep authenticator as one entity.
   vii.	Yoshi: OK with the single authenticator
   viii.Vidya: Reauth needs to run with the MSK which is at the first 
        EAP Authenticator.  With which entity does reauth happen?  Will 
        be discussed in PM session.
   ix.  Roaming idea – a Client goes to the new authenticator.  Not a 
        new EAP Server.  Will be discussed more in PM session.
   x.   Vidya:  Focus on key hierarchy, and not on different EAP 
        servers.  Baggage with the term “Roaming” within the same 
        Administrative domain.  EAP Peer can do reauth with a local 
        (EAP) server.  This is new entity which will be defined.
   xi.  Latency: Defined as fewer roundtrips than original full EAP 
        auth.  No time or minimum roundtrip requirements.
   xii. EAP Method Independence:  
        Kapil: There are some dependencies on the original method.  
        Glen: So, it is not completely independent.
   xiii.Backward compatibility – must be maintained with existing EAP 
        deployments.  There are non-standard implementations, so how to 
        deal with that.  Mention that “implementations compliant with 
        RFC 3748”.
   xiv. Compatibility:  
        Vidya: What 11r did could have been done in IETF, if IETF had 
               beat the market timing.  For Access technologies which 
               have not defined fast reauth, then no reason why these 
               cannot use HOKEY.  
   xv.  What does term “interference” means in the compatibility 
        statement.  
        Subir: No need to mention 11r and CAPWAP.  
        Charles: Bifurcate the HOKEY charter to be on outside of 
                 Authenticator, and CAPWAP/11r on inside.  HOKEY should 
                 not interfere with 11r/CAPWAP.
   xvi. Difference between Key Scope and Key Context – 
        Kapil: Key scope is tied to authorization; context defines the 
               components that are input into the key derivation.
   xvii.Intermediate entities: 
        Kapil: I do not see local (EAP) servers in the ps draft.  Vidya’s 
               model has those components.   
        Dan: Diagram explain of the different entities. 11r is punting 
             a problem that HOKEY is going to solve.  
        Kapil: HOKEY will not replace 11r, but complement it.  Add Dan’s 
               diagram into the ps draft.  
        Charles: Do not want to add a new diagram as that is problem 
                 statement.  
        Dan: Where is the Authenticator in the diagram that EAP Peer 
             does reauth to?  
        Subir: Where is local server? 
        Charles: It is not in diagram and should be between EAP Server 
                 and Passthrough Authenticator.
   xviii.Glen: EAP is 2-party, but Passthrough Auth is a 3rd entity, 
               which is an essential entity that must exist.  
        Vidya:  We are not solving EAP multiplexing model. 
        Glen: Yes, we are not.
   xix.	Section 7.1 Discussion:  
        Yoshi: Why are we criticizing 11r in the section 7.1.  
        Madjit: Yeah! Especially, since Kapil is here!  
        Charles: Change this section. 
        Charles: Compromising R0KH can lead to entire key hierarchies 
                 to be compromised.  
        Kapil: R0KH has security assumptions around the R0KH and if 
               compromised, then compromise argument can apply to any 
               other entity also.  
        Rajneesh: HOKEY can support 11r making R0KH within the network.  
        Madjid: R0KH can manage a larger domain.  
        Charles: If people recommend different text, then feel free to 
                 post on the reflector.  
        Rajneesh: Remove physical security statement.  
        Dan/Russ:  11r does not believe that R0KH and R1KH distribution 
                   is within their scope.  It is outside scope of HOKEY 
                   also.  
        Subir: Not specified in 11r, but should be specified here.  
        Dan/Vidya: R0KH and R1KH can be HOKEY entities for purpose of 
                   key distribution.

c. EMSK Key Hierarchy
   i.   Draft-saloway-eap-emsk-deriv -> draft-ietf-hokey-emsk-hierarchy
   ii.  Glen: Simplify the key hierarchy.  How do we simplify the key 
        hierarchy?  
        Laxminath: Make key hierarchy similar between home and visited 
                   networks.  For each purpose, the key derivation must 
                   happen at the home EAP.  
        Madjid: EMSK is not transported per EAP drafts, and we need USRK 
                for specific applications, and USRK will be handled with 
                different servers.  
        Madjid draws diagram where EMSK is at EAP Server and EAP Peer, 
        and how are specific parameters for each application is bound in? 
        Laxminath: Draws an EMSK key hierarchy on board with each key 
                   for different usages, and further keys below for each 
                   servers; and, another key hierarchy for each 
                   domain/service.  Based on Joe’s draft, different 
                   servers are application specific and can be handled 
                   specific application keys.  
        Madjid:  This proposal gives an asymmetric key hierarchy.  
        Laxminath: Not asymmetric.  
        Vidya: draft says we need IANA defined labels for each derivation 
               key name.  
   iii. There is a divergence between the current document draft and the 
        proposal from Laxminath/Vidya.  Goal is that the reauth root key 
        comes from same source.  
        Madjid:  Setup different USRKs for different applications. 
        Vidya: EAP Server does not know if the Local Servers may derive 
               multiple sub-keys for different applications.  
        Subir: Does home need to know the application?  
        Vidya:  Bind the usage into the key derivation.  
        Madjid: Not every usecase that needs a key should be conveyed to 
                the home Server.  EAP is done for a purpose, and keys 
                should be bound to that.  It may be visited domain 
                services.  
   iv.  Madjid: Discussion on what the ability of the Local server should 
                be w.r.t to the key that it gets from the home Server.  
                You get the key at bootup.  
        Michaela: The key derivation should be bound.  But, not clear 
                  if EAP server needs to know this.  
   v.	Proposal is to deliver a key to the Local Server and let the 
        local server decide on deriving multiple keys, as it sees fit.  
        Vidya: Operators need the flexibility to use the key for the 
               services that they may provide.  
        Kapil: This approach violates the HOKEY requirement for key 
               context binding, as the delivered root key can be used 
               for which-ever way the Local server likes.  
        Russ:  The key context is broad and can be “Local Services”. 
        Vidya: Moves between multiple visited domains.  
        Yoshi: Don’t need separation.  
        Kapil: Isn’t the discussion/scope of HOKEY within the same 
               administrative domain?  
        Glen: Use HOKEY to solve the multi-domain problem, if we can.  
        Russ:  Wiling to change the charter of HOKEY if they solve the 
               multi-domain problem.  
   vi.  The draft does not dramatically change.  Additions can be made 
        into same document. 
   vii.	Russ: What names the next level of key hierarchy?  It is the 
              Local Server (local scope EMSK) serving that portion of 
              the network.
   viii.Madjid: One auth gets the EMSK and Peer goes to another Auth.  
                Is there a problem with signaling?  
   ix.	Russ:  MSK and EMSK differences of scope.  Pick the one depending 
               on whether the Authenticator needs to know that key.  
               Peer needs to know both keys.  Local Server must not know 
               both keys.  
        Madjid:  AAA Server sends key to Auth and Auth does not send to 
                 any other entity.  
   x.	Vidya: Authenticator distributing keys is outside scope of HOKEY 
               charter.  
        Russ: Yes.
   xi.  Russ and Charles re-affirmed that the key distribution problem 
        from the “Local Server” to “Authenticators” is within scope of 
        HOKEY.  Change “Local Server” to “MDC” and we have the key 
        distribution for 11r.
   xii. AAA Server is root of all roaming keys, and that should be EMSK.  
        Charles asks for rough consensus on using EMSK as root of HOKEY.  
   xiii.Michala: Today, does EAP server know how the MSK is being used? 
        Usage of key is currently not sent to the EAP Server.
   xiv.	Vidya:  Do we need to have L2 signaling?  
        Charles: Need a L2 signaling to indicate HOKEY.  
        Madjid:  Should not necessarily be L2 signaling.  
        Michaela:  Need 2 phases.  
   xv.	Board design:  4 parties are: EAP Peer, Authenticator, “HOKEY” 
        Server, EAP Server.  Discussion on how to do the capability 
        exchange.

Afternoon Session (1:00pm – 5:00pm)

d. EAP-ER draft – presented by Vidya. 
   i.   Kapil: how does the Peer know how many hops away the AS/EAP 
               Server is?
   ii.  Vidya: Peer only knows the server name with whom it shares a key 
               with.  Potentially a choice can be made as to whether to 
               go back to the EAP server or ask for a re-auth key.
   iii. For EAP-AKA, an EAP authenticator can construct an EAP 
        Response/Identity message and send it to the EAP Server to 
        trigger EAP-AKA, either based on EAP/Req/Rsp Identity with the 
        Peer or based on other link layer signaling.
   iv.  Clarification: for 1.5 roundtrips, the 0.5 comes from the 
        EAP-Success.
   v.   Server-initiated Re-auth with legacy authenticators sounds like a 
        new EAP method. Server initiated must be kicked off from the 
        Authenticator. The Server can know from the identity what kind of 
        EAP method to start (re-auth or original).  Server-initiated, we 
        all seem to agree, is going to cost 1 (extra) roundtrip (one msg. 
        is the EAP Response/Identity, the other is the EAP Success).
   vi.  Peer-initiated re-auth with upgraded authenticators. 
        Authenticators must understand new EAP codes. Key usage is the 
        same. For legacy authenticators, we are introducing some empty 
        messages – as discussed on the list; though the core re-auth 
        protocol remains the same. 
   vii. Key hierarchy: as depicted is within a single server. Root key is 
        the local MSK or the EMSK. 
   viii.Protocol transport: what changes to 3748 would a code-based 
        re-auth introduce? V: none, as the new doc would not be a 3748bis  
        but another doc that updates 3748 and has 3748 as a normative 
        reference. State machine has to be updated as well. This re-auth 
        proto is going to impact port control at the lower layer. The 
        interactions between port control and protocol would be the same 
        for EAP and another (non-EAP) re-auth proto. Lakshminath asserts 
        that a non-EAP protocol doesn’t buy us anything.
   ix.  Subir makes the case of UMTS-AKA: this protocol allows for both 
        authentication and mobility. If a method like AKA does support 
        the mobility too, then why would we need to add new messaging? – 
        so why shoot for “better than AKA”, since it is fine as is and 
        so would not be replaced even if there is a new protocol out 
        there that has less latency. 
   x.   Vidya continues with EAP based transport benefits. 
   xi.  EAP-ER exchange message flow: Kapil asks about liveness and 
        replay.
   xii. Liveness done by sequence numbers.  These messages even if they 
        get replayed, the Authenticator still gets the same rMSK, so it 
        doesn’t impact it. No replay attacks – asserts Lakshminath. 
        Kapil still states that liveness is missing and that there are 
        potential replay attacks.
   xiii.Because of the fact that the AAA-H sends a key and all its 
        corresponding state to a AAA-L, re-auth works with AAA-L in one 
        roundtrip, even though the key that re-auth is based on was 
        derived between the Peer and AAA-H, not between the Peer and the 
        AAA-L – no disagreement, only clarification.
   xiv. Bootstrap exchange. Peer needs a full domain name before 
        completion of EAP-reauth. If you do bootstrap with the home 
        domain, you can get away with the next roundtrip only to the 
        AAA-L. The bootstrap gives the Peer the local server address.

e. EAP method extending: presented by Yoshi. 
   i.   How to deal with lack of EMSK implementation/derivation. A new 
        EAP method can be used for extending EAP. This way we ensure 
        backward compatibility with existing implementations via NAK. 
   ii.  Question on how to produce an EMSK for a method that doesn’t 
        produce one by itself: from previous tunneled method’s MSK. 
        Madjid points out that there is no provision for EAP failures. 
        Charles suggests taking all previous MSKs and hashing them to 
        achieve channel binding. There must be way to combine the keys 
        produced by these methods, such that not much entropy is lost. 
        Vidya concerned about the loss of entropy. 
   iii. Russ: what happens when you want to re-auth? 
        Yoshi: Re-auth should happen separately. So this draft helps get 
        you an EMSK when you don’t have one (and don’t want to update 
        your method), and does some nice channel binding stuff.

f. Handover Key Mgmt Architecture: A High level view : presented by Yoshi.
   i.   Re-key is not the same as re-auth: Re-auth follows re-key but 
        re-key does not require re-auth. For 802.11r, re-key is enough 
        as scope of authorization is R0KH, so no re-auth needed for 
        transitions within the same R0KH. Not the same case in 802.11i, 
        where the scope of authorization is one single AP. 
   ii.  A heated discussion about scope of authorization as raised by 
        Glen: Peer authorized to use the entire network *through* the 
              control port opened to that R1 KH.  As you move around, 
              you have to open a new port. 802.11r should authorized 
              peers within the mobility domain (which can include more 
              than one R0 KH). 
        Charles: we accept that there is some ambiguity surrounding the 
                 issue of scope of authorization.
   iii. Yoshi concludes not all existing architecture clearly separate 
        re-key from re-auth. We should examine proposed architectures 
        in this light.
   iv.  Vidya mentions that Steve Kent says that unless you are 
        checking credentials (long term key or cert.), it is not 
        authentication. Just showing proof of possession is not 
        authentication. Vidya disagrees.

g. Draft-nakhjiri-hokey-hierarchy-03 – Madjid Nakhjiri
   i.   The backend messaging is not EAP – It can be carried over RADIUS 
        attributes or in DIAMETER.
   ii.  There would be new signaling between the EAP Peer and 
        Authenticator.
   iii. Presented multiple Signaling alternatives – no change to EAP, 
        using new EAP, using new EAP method, and EAP method 
        encapsulation.
   iv.  New lower layer messaging encapsulation (EAP Peer ? 
        Authenticator) will have to be defined, as this proposal does not 
        use EAP.
   v.   Will need Authenticator and supplicant upgrades.

h. Impact Analysis – Charles Clancy
   i.	Transport | Peer  |  Auth  | Server  |  L2   | Latency
         Non-EAP    Major    Major   Major     Major    Low
        EAP-Code    Minor+   Minor   Minor+    Minor    Low
        EAP-Type    Minor-   None    Minor-    None     High
   ii.  EAP-code (defining new EAP payload) and EAP-Type (new Types 
        within existing payloads) are new EAP extensions.
   iii. Discussion on whether 802.11 community will live with the HOKEY 
        solution, especially when they are biggest users of EAP.
   iv.  Vidya mentioned that .16 and 3G has still not deployed EAP? So, 
        such changes proposed by HOKEY are acceptable.
   v.   Humming:  
        Code Alone: Loud; 
        Type alone: Not so loud; 
        Code + Type: Not so loud.
   vi.  Take the EAP Code proposal to the list.
   vii. MSK versus EMSK matrix, as root of the key hierarchy
         Key   |  Pros                      |  Cons
         MSK      - Existing [broken] EAP    - Complexity to
                    Methods don’t need to be   decide which key to 
                              Fixed.           Use.
         EMSK     - Currently not used       - May not work with 
                  - Never exported             some deployments
   viii. Humming:  
         MSK ( low ) ; 
         EMSK ( loud ) ; 
         Both (Silence)

_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey