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

[Yoshihiro Ohba <[e-mail]>]

Charles,

Although I agree that there are multiple approaches to realize both
hop-by-hop and end-to-end security, it is better for a key
distribution protocol not to assume that transport is sufficiently
secure.  It appears that RADIUS keywrap exactly follows this
philosophy.  RADIUS keywrap is designed so as not to rely on RADIUS
security or RADIUS transport security.  Therefore, it has its own
protection mechanism.  For the same reason, it perfectly makes sense
to me that KDE has its own protection mechanism.  This justification
seems even more stronger than RADIUS keywrap since HOKEY KDE is
designed to be transport agnostic and not just for RADIUS.

Yoshihiro Ohba


On Sat, Feb 23, 2008 at 08:14:24PM -0500, Charles Clancy wrote:
> Yoshi,
>
> I think there are multiple approaches for supporting both hop-by-hop and  
> end-to-end security.  I'd rather them be expressed as requirements on  
> the transport protocol, rather than implemented directly within this  
> document.
>
> For example, RADIUS keywrap allows you to securely encrypt information  
> to transport over a AAA infrastructure.  The keys used can either be  
> end-to-end keys, or hop-by-hop keys.  If end-to-end keys are used, then  
> you get end-to-end security.  If hop-by-hop keys are used, you don't.  
> But, it's then up to the deployment to decide what type of keying they  
> can support.  It's up to us to document the ramifications of that  
> decision in the security considerations section.
>
> My email that you cite below reflects the ability to easily provision  
> end-to-end keys for use with keywrap, among other protocols.  It would  
> make it easier to support end-to-end security.
>
>
>
> --
> t. charles clancy, ph.d.                 eng.umd.edu/~tcc
> electrical & computer engineering, university of maryland
>
>
> Yoshihiro Ohba wrote:
>> 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