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

From: Charles Clancy <[email-masked]>
Date: Mon, 18 Feb 2008 22:58:43 -0500

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).

---------
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).

 >      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.

 >      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.

 >      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.

 >   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 distrubtion" 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.

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.

-----------
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.

-- 
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

Yoshihiro Ohba wrote:
> Changes from 01:
> 
> [1] Added Section 3.4 to address AKM (automated key management) issue
> to establish pre-shared keys between third-party and server.  Use of
> Kerberos is recommended to establish KIts and KCts for the purpose of
> AKM.  This means that HOKEY KDE is based on end-to-end security
> between third-party and server.  This change should address Issue 28:
> "KM: encryption optional".
> 
> [2] Removed several key distribution use cases other than those for
> distributing DSRK and rRK.  Also, the number of Key Types in Section 5
> is reduced accordingly.
> 
> [3] Added integrity protection to Message 3.
> 
> Next step: Define message format before IETF March meeting, to address
> Issue 27.
> 
> Best Regards,
> Yoshihiro Ohba
> 
> 
> ----- Forwarded message from IETF I-D Submission Tool <[email-masked]> -----
> 
> X-VirusChecked: Checked
> X-Env-Sender: [email-masked]
> X-Msg-Ref: server-15.tower-76.messagelabs.com!1201786903!18565298!1
> X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
> X-Originating-IP: [156.154.24.139]
> X-SpamWhitelisted: domain whitelist
> To: [email-masked]
> Cc: [email-masked]
> From: IETF I-D Submission Tool <[email-masked]>
> Subject: New Version Notification for draft-ietf-hokey-key-mgm-02 
> X-UIDL: d?4"!8VS"!M7L!!$~6!!
> 
> 
> A new version of I-D, draft-ietf-hokey-key-mgm-02.txt has been successfuly submitted by Yoshihiro Ohba and posted to the IETF repository.
> 
> Filename:	 draft-ietf-hokey-key-mgm
> Revision:	 02
> Title:		 Derivation, delivery and management of EAP based keys for handover and re-authentication
> Creation_date:	 2008-01-31
> WG ID:		 hokey
> Number_of_pages: 17
> 
> Abstract:
> This document describes a delivery framework for usage and domain
> specific root keys (USRK and DSRK), derived as part of an EAP EMSK
> hierarchy, and delivered from an EAP server to an intended third
> party key holder.  The framework description includes different
> scenarios for key delivery, depending on the type of keys being
> delivered.  It also includes, specification of derivation of keys
> required for security protection of key requests and delivery
> signaling.
>                                                                                   
> 
> 
> The IETF Secretariat.
> 
> 
> 
> 
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey
_______________________________________________
HOKEY mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/hokey

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 19 Feb 2008 10:09:32 -0500

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:
> 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  

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.

> AAA servers in a specific key management domain (or DSR-KH in your  

OK.

> may be domain-specific, but they shouldn't be called DSUSRKs.

We can simply remove the sentence.

> consistent with how AAA keys are currently managed within a AAA server.

We can remove this sentence as well.

> out that these keys are DSUSRKs.

OK.

> key distribution" is not okay, because it implies certain requirements  

I agree with making KDE0 optional.

> SAT: this message looks okay

OK.

> 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.
>

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

---

From: Charles Clancy <[email-masked]>
Date: Sat, 23 Feb 2008 20:14:24 -0500

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.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 24 Feb 2008 00:09:09 -0500

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:
>> be useful to many working groups and many protocols that operate over 
>> AAA: http://www.ietf.org/mail-archive/web/hokey/current/msg01043.html
>>
>>> 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
>>> ---------
>>>
>>> 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).
>>
>>> 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
>>> 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.
>>
>>> More than "possibly responsible".  It's "responsible".  You should 
>>> point  out that these keys are DSUSRKs.
>>
>> OK.
>>
>>> 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.
>>
>>> 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.
>>>
>>> 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:
>>>
>>> ... rather than providing the exact PRF.  The EMSK doc is normative 
>>> on  the PRF.
>>
>> OK.
>>
>>> -----------
>>> Section 3.4
>>> -----------
>>>
>>> Talk about scenarios independently from HOKEY.  Feel free to use ERX 
>>> as  an example protocol that could use the keys.
>>>
>>> --------------
>>> Needed Section
>>> --------------
>>>
>>> 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.
>>>