[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HOKEY] WGLC: draft-ietf-hokey-key-mgm-06
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
> -----Original Message-----
> From: hokey-bounces at ietf.org [mailto:hokey-bounces at ietf.org] On Behalf
Of
> Qin Wu
> Sent: Thursday, June 18, 2009 12:59 AM
> To: Rafa Marin Lopez; hokey at ietf.org
> Subject: Re: [HOKEY] WGLC: draft-ietf-hokey-key-mgm-06
>
> 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)
> 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.
>
[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" <rafa at um.es>
> To: <hokey at ietf.org>
> Sent: Tuesday, June 16, 2009 5:21 PM
> 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.
> >
> > 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:
> >> 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
> >> HOKEY at ietf.org
> >> 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: rafa at um.es
> > ------------------------------------------------------
> >
> > _______________________________________________
> > HOKEY mailing list
> > HOKEY at ietf.org
> > https://www.ietf.org/mailman/listinfo/hokey
> _______________________________________________
> HOKEY mailing list
> HOKEY at ietf.org
> https://www.ietf.org/mailman/listinfo/hokey