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

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Wed, 1 Jul 2009 14:25:37 -0400

Rafa,

Thank you for your comments.
Please find my replies in line.

I have addressed all your comments in the new 07 draft version that I
just posted. Please have a look at the new version to see whether you
agree with the changes.

Best regards,
Katrin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Rafa Marin Lopez
> Sent: Tuesday, June 16, 2009 4:21 AM
> To: [email-masked]
> Subject: Re: [HOKEY] WGLC: draft-ietf-hokey-key-mgm-06
> 
> 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.
> 
[KH] I agree. The new I-D considers general AAA protocols, i.e. RADIUS
and Diameter could both be used to provide transportation for the KDE
messages.

> For example section 8.1 could be more general:
> 
> "8.1.  Requirements on AAA Key Transport Protocol"
[KH] Done.
> 
> And sections 5 and 7 could be removed.
[KH] Done.
> 
> 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?
> 
[KH] I agree, I added a KRS identifier to the key scope. "The key scope
of each distributed key is determined by the sequence of (PID, KT,
KL)-tuples in the key hierarchy and the identifier of the KRS."

> 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?).
[KH] Text has been changed to "If the EAP exchange is successful, the
home AAA server includes a KDE-Response message in the AAA message that
carries the EAP-Success message."
> 
> Best Regards.
> 
> 
> Glen Zorn wrote:
> > 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.
> >
> >
> > _______________________________________________
> > 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]
> ------------------------------------------------------
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Wed, 1 Jul 2009 14:43:00 -0400

Hi Glen,

Thanks for your review. Please find my replies in line.

Please have a look at the new draft version that I just posted and let me know whether you agree with the changes and if there are still open issues.

Best regards,
Katrin

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Glen Zorn
> Sent: Wednesday, June 17, 2009 8:12 AM
> To: [email-masked]
> Cc: 'Katrin Höper'; Yoshihiro Ohba
> 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.
[KH] Agree. Changed it to general AAA protocols for carrying the KDE messages throughout the document.
> 
> I'm also puzzled by the fact that the rRK is not mentioned, since (oddly,
> IMHO) it may be derived directly from the EMSK.
[KH] This is mainly because RFC 5295 does not mention rRK. I have added a sentence explaining the connection between rRKs and the other keys in the introduction: "[RFC5296] defines a re-authentication root key (rRK) that is a USRK designated for re-authentication."
> 
> 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).
[KH] Agree. I defined a KDS consisting of the EAP server and an AAA server to address your comment. The EAP server derives the roots keys and exports them to the AAA server, who in turn distributes the keys. Both capabilities combined are referred to EAP/AAA server in the document.
> 
> 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.
[KH] Done, hope I caught all instances.
> 
> In section 1, paragraph 1, s/derives an Master Session Key (MSK)/derives a
> Master Session Key (MSK)/
> 
[KH] Done
> Section 2 is poorly formatted, with text scattered all over the page.
[KH] Done
> 
> 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.
[KH] Done. See previous comment on EAP/AAA server serving as 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'?
[KH] Fixed the sentence and removed references to authorizations: "An EAP server carries out normal EAP authentications with EAP peers but is typically not involved in potential handovers and re-authentication attempts by the same EAP peer."
> 
> Next sentence, s/the service provisioning/service provisioning/
[KH] Done
> 
> 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.
[KH] Changed the paragraph to: 
Whenever EAP-based keying material is used to protect a requested service, the respective keying material has to be available to the server providing the requested service.  For example, the first time a peer requests a service from a network server, this server acts as a KRS. The KRS requests the root keys needed to derive the keys for protecting the requested service from the respective KDS.  In subsequent requests from the same peer and as long as the root key has not expired, the KRS can use the same root keys to derive fresh keying material to protect the requested service.
> 
> 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"
[KH] Has been addressed as part of the EAP vs AAA server clarifications.
> 
> Next sentence, same comment.
> 
> Section 4, first sentence, s/(KDE)over/(KDE) over/
[KH] Done
> 
> 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.
> 
[KH] Agree, removed.
> 
> 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.
[KH] This section has been removed. 
> 
> 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.
[KH] Changed to " Here, an AAA User-Name attribute is used as the PID."
> 
> In section 7, I'm not sure what "Access-Reject/Keying-Material" is.
[KH] Me neither :) fixed!
> 
> 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.
> 
[KH] Agree, changed paragraph to reflect that only the attributes of a KDE message need to be protected not the entire AAA message. Furthermore distinguish between which attributed require integrity protection and which one additionally encryption. New text:

" Any KDE attribute that is exchanged as part of a KDE-Request or KDE-
   Response message MUST be integrity-protected and replay-protected by
   the underlying AAA protocol that is used to encapsulate the
   attributes.  Additionally, a secure key wrap algorithm MUST be used
   by the AAA protocol to protect the RK in a KDE-Response message.
   Other confidential information as part of the KDE messages (e.g.
   identifiers if privacy is a requirement) SHOULD be encrypted by the
   underlying AAA protocol."

> 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.
> 
[KH] I do not really know any other option than using a protocol at another protocol layer that provides end-to-end security. If you have a concrete examples please let me know.

Added text: " If such a trusted AAA
   infrastructure does not exist, other means must be applied at a
   different layer to ensure the end-to-end security (i.e. between KRS
   and KDS) of the exchanged KDE messages.  The security requirements
   for such a protocol are the same as previously outlined for AAA
   protocols and MUST hold when encapsulated in AAA messages."

> 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.
> 
[KH] Corrected failed attempts to silently dropped request and added some explanatory text.

New text: " On the other hand, 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.  A peer is not   involved in the process and, thus, not aware of a key delivery requests for root keys derived from its established EAP keying material.  Hence, a peer has no control where keys derived from its established EAP keying material are distributed to.  A possible consequence of this is that a KRS may request and obtain a RK from the home server even if the peer does not support ERP.  EAP-Initiate/Re-auth-Start messages send to the peer will be silently dropped by the peer causing further waste of resources."

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

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Wed, 1 Jul 2009 14:47:30 -0400

Hi Qin,

Thank you for your review.
Please find my comments in line and also check the new version I just
posted.

Best regards,
Katrin

Of
> Qin Wu
> Sent: Thursday, June 18, 2009 12:59 AM
> To: Rafa Marin Lopez; [email-masked]
> Hi, All:
> I agree with Rafa in his opinion as regarding Radius support for key
> distribution.
[KH] I addressed Rafa's comments in a separate email. The changes are
included in the new draft.
> 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)
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.
> 
[KH] I changed the scope to general AAA protocols and left it up to the
implementers how to use AAA for this. Requirements for the AAA protocol
are defined in Section 6.
> 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.
[KH] Glen already answered these questions in a previous email.
> 
> 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?
[KH] Done, authorization is removed and text revised.
> 
> 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?
[KH] Done.
> 
> 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.
[KH] I don't understand what KRE is. Have a look at your question still
applies to the new draft version.
> 
> ----- Original Message -----
> From: "Rafa Marin Lopez" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, June 16, 2009 5:21 PM
discusses
transported
context
AAA
the
Access-
KDE-Request