Subject: [HOKEY] WGLC: draft-ietf-hokey-key-mgm-06

From: "Glen Zorn" <[email-masked]>
Date: Thu, 4 Jun 2009 21:22:33 +0700

This messages announces the beginning of Working Group Last Call on
draft-ietf-hokey-key-mgm-06 
(http://www.ietf.org/internet-drafts/draft-ietf-hokey-key-mgm-06.txt).  The
last call period will end on Thursday, 18 June 2009 at 1500 GMT.  
When submitting comments please reply to this message, leaving the subject
line intact.  Thank you.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 15 Jun 2009 18:56:51 +0700

The last call period will end on Thursday, 18 June 2009 at 1500 GMT.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 16 Jun 2009 11:21:08 +0200

Dear all,

here it's my review of this I-D.

In general, the I-D is in good shape but I don't understand very well 
why it has to be linked to RADIUS. For example, in the abstract we have:

"The document defines a key distribution exchange (KDE)
   protocol using Remote Authentication Dial In User Service (RADIUS)
   that can distribute these different types of root keys and discusses
   its security requirements."

As far as I can understand KDE (the defined tokens) could be transported 
by either RADIUS or Diameter. So, I was wondering why do we need to 
specify RADIUS here in this I-D?. I think the I-D could specify the 
security requirements that an AAA protocol (that could be RADIUS or 
Diameter) should provide to transport KDE.

For example section 8.1 could be more general:

"8.1.  Requirements on AAA Key Transport Protocol"

And sections 5 and 7 could be removed.

What do you think?.

Here you can find a couple of additional comments:

In section 4.1

"The key scope of each distributed key is determined by the sequence
   of (PID, KT, KL)-tuples in the key hierarchy".

The delivered key RK should be associated to a particular PID and a 
particular KRS as far as I understand. To me, that would be the context 
(apart from KT, and KL). Am I missing something?

In section 6

"In implicit bootstrapping the local EAP Re-authentication (ER) server
   requests the DSRK from the home AAA server during the initial EAP
   exchange.  Here, the local ER server acts as the KRS and the home AAA
   server as the KDS.  In this case, the local ER server requesting the
   DSRK MUST include a KDE attribute with the K-flag cleared in the
   RADIUS Access-Request message that carries the first EAP-Response 
message
   from the peer.  A value of the RADIUS User-Name attribute is
   used as the PID.  Upon receiving a valid KDE-Request, the home AAA
   server includes a KDE attribute with K-flag set in the RADIUS Access-
   Accept message that carries the EAP-Success message."

Note that in this case (implicit bootstrapping), between the KDE-Request 
and the KDE-Response there will be several roundtrips to complete the 
EAP authentication. Thus let's say that the KDE key distribution will 
need to wait for more than one single roundtrip before finishing (in 
fact, RK is delivered in the same message as MSK no?).

Best Regards.

Glen Zorn wrote:
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey
>
>   

-- 
------------------------------------------------------
Rafael Marin Lopez
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 17 Jun 2009 17:01:15 +0700

Rafa Marin Lopez [mailto://[email-masked]] writes:

...

> Diameter) should provide to transport KDE.

Sounds like a good idea to me.

...

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 17 Jun 2009 20:11:45 +0700

I don't really understand why this document should be RADIUS-specific; I
think that it would be much more useful if it simply laid out the security
requirements of the KDE & let other documents define protocol-specific
solutions satisfying those requirements.

I'm also puzzled by the fact that the rRK is not mentioned, since (oddly,
IMHO) it may be derived directly from the EMSK.

Throughout the document there appears to be evidence that the authors are
confusing AAA servers with EAP servers.  For example, Figure 1 shows lines
between various "key holders" and an EAP server.  How are these connections
made?  Presumably with AAA, but EAP servers don't speak AAA, they speak EAP
(this is true regardless of implementation details).

MSK and EMSK are used both with and without a preceding article, often in
successive sentences.  For example: 
   MSK and EMSK may be used to derive further keying material for a
   variety of security mechanisms [RFC5247].  For example, the MSK has
   been widely used for bootstrapping the wireless link security
   associations between the peer and the network attachment points.
The above should read
   The MSK and EMSK may be used to derive further keying material for a
   variety of security mechanisms [RFC5247].  For example, the MSK has
   been widely used for bootstrapping the wireless link security
   associations between the peer and the network attachment points.
This occurs too many times to cite and correct each instance.

In section 1, paragraph 1, s/derives an Master Session Key (MSK)/derives a
Master Session Key (MSK)/

Section 2 is poorly formatted, with text scattered all over the page.

In Section 2, under "KDS": since EAP has no key delivery mechanisms
whatsoever, I can't see how the EAP server can be a KDS.

In section 3, first paragraph, sentence one: I really have no idea what this
sentence means.  Leaving aside the fact that it's called "Extensible
_Authentication_ Protocol" (which, by itself, strongly suggests that an EAP
server has no business in service authorization) if one takes a working
definition of the term "authorization" as "the instantiation of a policy WRT
a set of conditions, possibly including time", what are 'potentially future
service authorization decisions'?  

Next sentence, s/the service provisioning/service provisioning/

Fourth sentence of the same paragraph says "Whenever EAP-based keying
material is used to protect a requested service, a network server needs to
request the root key associated with the offered service from the respective
KDS", but this is pretty clearly not true: the root key need only be
requested on the first usage of the service, after which the appropriate
transient keys may be derived (up until the expiration of the root key, at
least).  In addition, this sentence could be interpreted as saying that a
NAS, for example, must request a root key in order to support
reauthentication, a dangerous interpretation.

Next sentence s/This kind of key requests/These kinds of key requests/

The next sentence says "Hence, any root key that is directly derived from an
EMSK must be derived and delivered by the EAP server itself".  However, I'm
unaware of any key delivery mechanism existing in EAP.  Suggest changing to:
"Hence, any root key that is directly derived from an EMSK must be derived
and exported by the EAP server itself"

Next sentence, same comment.  

Section 4, first sentence, s/(KDE)over/(KDE) over/

Section 4.1, second paragraph, second sentence says "When a DSRK is being
delivered and the DSRK applies to only a specific set of services, the
service types may need to be carried as part of context for the key."  Isn't
this actually a description of a set of DSUSRKs?  Since there is already a
mechanism for doing this, why complicate it with some vague, unspecified
stuff.

I really don't understand the construction of the KDF RADIUS Attribute.  Is
more than one instance of this attribute expected to be present in a given
RADIUS message?  If not, the attribute should be split into 5.  

I don't understand what "A value of the RADIUS User-Name attribute is used
as the PID." means in section 6, second paragraph; same comment for the
recurrence of the sentence in paragraph 3.

In section 7, I'm not sure what "Access-Reject/Keying-Material" is.

Section 8.1 says "RADIUS messages that carry a KDE attribute MUST be
encrypted,   integrity-protected and replay-protected with a security
association created by a RADIUS transport protocol such as
TLS[I-D.ietf-radext-radsec]." but no rationale is given for the encryption
of the entire message (as opposed to just the KDE attribute); in fact, it's
hard to see the reason why such things as the key label would need to be
encrypted at all.

Later the same section says "the use of hop-by-hop security SHOULD be
limited to an environment where an intermediary is trusted not to abuse the
distributed key material" but no option is given for environments where that
is not the case.

Section 8.2, second paragraph, says:
   When a KDE-Request message is sent as a result of implicit ERP
   bootstrapping [RFC5296], cryptographic verification of peer consent
   on distributing a RK is not provided.  As a result, it is possible
   for a KRS to request a RK from the home server and obtain the RK even
   if the peer does not support ERP, which can lead to an unintended use
   of a RK and failed authentication attempts.
I would appreciate some explanation of how failed authentication attempts
could result here, since I don't find it to be a really obvious effect.

Please remove the email addresses from section 11: email addresses are
ephemeral & change all the time, but RFCs are permanent.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 18 Jun 2009 12:09:55 +0700

The last call period ends in less than 12 hours; no further comments will be
accepted after the last call period ends & silence will be interpreted as
approval.

---

From: Qin Wu <[email-masked]>
Date: Thu, 18 Jun 2009 13:58:47 +0800

Hi, All:
I agree with Rafa in his opinion as regarding Radius support for key distribution.
Besides this, I have some general comments below which request some editorial changes.

Regards!
-Qin

[snip]
Abstract
   This document describes a mechanism for delivering root keys from an
   Extensible Authentication Protocol (EAP) server to another network
   server that requires the keys for offering security protected
   services, such as re-authentication, to an EAP peer.  The distributed
   root key can be either a usage-specific root key (USRK), a domain-
   specific root key (DSRK) or a domain-specific usage-specific root key
   (DSUSRK) that has been derived from an Extended Master Session Key
   (EMSK) hierarchy previously established between the EAP server and an
   EAP peer.  The document defines a key distribution exchange (KDE)
   protocol using Remote Authentication Dial In User Service (RADIUS)
   that can distribute these different types of root keys and discusses
   its security requirements.

 [Qin]: I wonder Whether we need to consider to use Diameter for key distribution exchange in this draft?
or just generalize the RADIUS into AAA protocol. As regarding how to use Diameter for key distribution exchange, 
you can  refer to the [I-D.wu-dime-local-keytran] in the DIME WG.

1.  Introduction

   The Extensible Authentication Protocol (EAP) [RFC3748] is an
   authentication framework supporting authentication methods that are
   specified in EAP methods.  By definition, any key-generating EAP
   method derives an Master Session Key (MSK) and an Extended Master
   Session Key (EMSK).  
   
 [Qin]: what I am difficult to understand is which EAP method will be used to derive an MSK or EMSK?
Whether we really need EAP method to derive MSK or EMSK?
 If we have additional text to clarify this, it will be helpful.

3.  Key Delivery Architecture

   An EAP server carries out the EAP authentications with EAP peers but
   is typically not making any, potentially future, service
   authorization decisions involving peers.  

 [Qin]: I am a little dificult to understand the purpose of EAP authentication? 
 Can you clarify the difference between EAP authentication and service
authorization? Here the service is network access service? Isn't it? Whether
EAP authentication can be used to authorize any mobility service or derive some 
child key for mobility service?

4.  Key Distribution Exchange (KDE)

   In this section, a generic mechanism for a key distribution exchange
   (KDE)over RADIUS is described in which a root key (RK) is distributed
   from a KDS to a KRS.  It is required that the communication path
   between the KDS and the KRS is protected by the use of an appropriate
   RADIUS transport security mechanism (see Section 8).  Here, it is

[Qin]: Whether Radius transport security mechanism is the only choice? 
 Is there any Diameter transport security mechanism?

6.  KDE used in the EAP Re-authentication Protocol (ERP)

   This section describes how the presented KDE should be used to
   request and deliver the root keys used for re-authentication in the
   EAP Re-authentication Protocol (ERP) defined in [RFC5296].

 [Qin]: Here, in my understanding, the presented KRE is used to request the root key
  while the KDE is used to deliver the root keys.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 18 Jun 2009 22:41:02 +0700

This messages announces the end of Working Group Last Call on
draft-ietf-hokey-key-mgm-06.  No further comments will be accepted.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 19 Jun 2009 15:57:04 +0700

Qin Wu [mailto:[email-masked]] writes:

...

> used to derive an MSK or EMSK?

It doesn't matter; hokey is EAP-method agnostic.

> Whether we really need EAP method to derive MSK or EMSK?

There's no other way to do it, AFAIK.

> child key for mobility service?

EAP is an authentication protocol; it has no facilities for authorization.

>   while the KDE is used to deliver the root keys.

The acronym "KRE" doesn't appear in the document.

...