[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HOKEY] WGLC: draft-ietf-hokey-key-mgm-06
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
> -----Original Message-----
> From: hokey-bounces at ietf.org [mailto:hokey-bounces at ietf.org] On Behalf Of
> Glen Zorn
> Sent: Wednesday, June 17, 2009 8:12 AM
> To: hokey at ietf.org
> Cc: 'Katrin Höper'; Yoshihiro Ohba
> Subject: Re: [HOKEY] WGLC: draft-ietf-hokey-key-mgm-06
>
> 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
> _______________________________________________
> HOKEY mailing list
> HOKEY at ietf.org
> https://www.ietf.org/mailman/listinfo/hokey