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

[Charles Clancy <[e-mail]>]

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