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

[Charles Clancy <[e-mail]>]

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 <[e-mail]> -----
> 
> X-VirusChecked: Checked
> X-Env-Sender: [e-mail]
> 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: [e-mail]
> Cc: [e-mail]
> From: IETF I-D Submission Tool <[e-mail]>
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/hokey
_______________________________________________
HOKEY mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/hokey