Re: [HOKEY] [FW: New Version Notification for draft-ietf-hokey-key-mgm-02]

[Yoshihiro Ohba <[e-mail]>]

Charles,

I don't agree with entirely removing end-to-end security feature by
entirely removing KIts and KCts and eliminating encryption and
integrity protection between third party and server within this
protocol.

I stated my position relating to this in January:
http://www.ietf.org/mail-archive/web/hokey/current/msg00923.html

Also, let me note your comment stating that end-to-end security would
be useful to many working groups and many protocols that operate over AAA: 
http://www.ietf.org/mail-archive/web/hokey/current/msg01043.html

Please see below for my other comments that are not relating to my
above disagreement.


On Mon, Feb 18, 2008 at 10:58:43PM -0500, Charles Clancy wrote:
> Yoshi,
>
> Thanks for putting together this update.  We still have significant  
> problems with this document.  It's very much a 3-party key distribution  
> document, and the WG consensus is to not do 3-party key distribution. If 
> we can't get this document to match WG consensus, we'll need to toss it 
> out and start with something else.  Below are my specific comments on  
> what I think needs to be done to get this document going in the right  
> direction.  Additionally, there are also significant grammatical  
> problems with the document.
>
> I'd be happy to help with the editing, to possibly have a document that  
> matches WG consensus by IETF 71.  Let me know if you're interested.
>
> ---------
> Section 1
> ---------
>
> >   The purpose of this document is not to provide exact syntax for the
> >   signaling, only the general semantics for the parameters involved are
> >   defined.  The exact syntax for these parameters when carried by
> >   specific protocols, such as AAA protocols [RFC3579] [RFC4072] or EAP
> >   protocols are out of scope of this document.
>
> I'm not sure this is correct.  The goal of this document is to define a  
> generic protocol and then describe exactly how to use specific protocols  
> to transport keying material (e.g. ERX and AAA).

I am working on the next revision which will include exact syntax as a
generic protocol.  If we consider distribution of DSRK, I believe UDP
transport is sufficient, since the DSRK distribution can happen after
the peer completes a full EAP authentication and establishes
connectivity to the network in a visited domain.  Therefore, the
peer can directly communicate with DSR-KH over UDP.  Extending ERX to
carry this protocol may not be a good idea.  Note also that DSRK is
not specific to ERX.

>
> ---------
> Section 3
> ---------
>
> >   However, since EMSK cannot be
> >   exported from EAP server, such third parties need to request the EAP
> >   server to generate the relevant root key (USRK, DSRK, or DSUSRK) from
> >   the EMSK and deliver the requested key to them.
>
> The EAP server only generates USRKs and DSRKs.  DSUSRKs are generated by  
> AAA servers in a specific key management domain (or DSR-KH in your  
> terminology).

OK.

>
> >      The USR-KH by
> >      definition is domain independent, which means the USR-KH can use
> >      USRK to generate DSUSRK for each domain deploying that service.
>
> According to the current EMSK hierarchy, DSUSRKs cannot be derived from  
> USRKs.  A USR-KH can derive any keys it wants from the USRK, and they  
> may be domain-specific, but they shouldn't be called DSUSRKs.

We can simply remove the sentence.

>
> >      Security Requirements for
> >      delivery of USRK from EAP server to a collocated USR-KH is
> >      currently TBD.
>
> I don't think this is something we need to worry about.  It should be  
> consistent with how AAA keys are currently managed within a AAA server.

We can remove this sentence as well.

>
> >      The DSR-KH is
> >      possibly responsible for derivation and distribution of any child
> >      keys derived from DSRK for that specific domain.
>
> More than "possibly responsible".  It's "responsible".  You should point  
> out that these keys are DSUSRKs.

OK.

>
> >   Regardless of the type of key being delivered, the model for EAP
> >   based key derivation and delivery interface can be generalized as a 3
> >   party key distribution model
>
> I'd like to see a different terminology used.  The WG consensus is to  
> NOT use 3-party key distribution.  References to "distribution to a  
> third party" seem reasonable, but I'd prefer some other name. "3-party  
> key distribution" is not okay, because it implies certain requirements  
> that the WG has decided not to pursue.
>
> -----------
> Section 3.1
> -----------
>
> KDE message 0 should be removed or at least made optional.  It should be  
> assumed that the peer already knows these identities.

I agree with making KDE0 optional.

>
> PRT: this message looks okay
>
> TRT: We don't assume the existence of KIts.  The TRT should not have an  
> integrity check on it.  It should be assumed that the transport protocol  
> will provide integrity protection and/or confidentiality of this  
> message.  In the transport section we'll deal more with how AAA can  
> provide this necessary integrity protection.
>
> TOK: Again, we don't assume the existence of KIts or KCts.  We need to  
> place requirements on the transport to provide this confidentiality and  
> integrity protection.
>
> SAT: this message looks okay
>
> -----------
> Section 3.2
> -----------
>
> The KDRK can only be the EMSK (to deliver USRKs and DSRKs) or DSRK (to  
> deliver DSUSRKs).  Describe the CK and IK as USRKS and DSUSRKs.  That  
> is, if the KDRK is the EMSK, then:
>
>   CK = USRK(usage="distribution cipher key")
>   IK = USRK(usage="distribution integrity key")
>
> ... and if the KDRK is the DSRK for domain="example.net", then:
>
>   CK = DSUSRK(usage="key distribution cipher key", domain="example.net")
>   IK = DSUSRK(usage="key distribution integrity key", domain="example.net")
>
> ... rather than providing the exact PRF.  The EMSK doc is normative on  
> the PRF.

OK.

>
> -----------
> Section 3.4
> -----------
>
> This section should be removed, since the KIts and KCts shouldn't exist.
>
> All references to Kerberos MUST be removed from this document.
>
> Talk about scenarios independently from HOKEY.  Feel free to use ERX as  
> an example protocol that could use the keys.
>
> --------------
> Needed Section
> --------------
>
> We need a section that provides the fundamental signaling. Specifically, 
> how to map this to AAA, how to deal with proxies, and how to use AAA to 
> provide some level of confidentiality and integrity for the PRT and TRT.
>
> We also need to define how ERX can carry PRK and SAT using their  
> existing, extensible framework.
>
> I think draft-gaonkar-radext-erp-attrs-02 is a good start on how this  
> can be accomplished.

As I commented above, extending ERX to carry this protocol may not be
a good idea.  The peer can directly communicate with DSR-KH over UDP.
Maybe what we can do is to identify several alternatives for the
signaling and discuss them in IETF71.

Yoshihiro Ohba


_______________________________________________
HOKEY mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/hokey