Re: Review of draft-zorn-radius-keywrap

[Joe Salowey <[e-mail]>]

Hi Bernard,

Thank for the review. Comments in line below:


On Dec 15, 2010, at 12:14 PM, Bernard Aboba wrote:

> There are two major issues remaining in this document.
> 
> One issue is that in a number of places, the document appears to 
> contradict IETF standards track documents. 
> 
> Examples:
> 
> Section 3.1
> 
>       If the client requires the use of the Keying-Material Attribute
>       for keying material delivery and it is not present in the Access-
>       Accept or Access-Challenge message, the client MAY ignore the
>       message in question and end the user session.
> 
> [BA] Presumbly the MAY is included here for security reasons, such as preventing
> the client from accepting a downlevel key from a server from which it has
> previously received keying material described in this document, thus preventing
> spoofing in the event that the RADIUS shared secret (or MD5) is compromised.
> However, in such a situation the key material itself would be compromised,
> so that some sort of warning should probably be raised. 
> 

[Joe]  How about the following:

"In environments where the the Keying-Material attribute is known to be supported or in cases where the client wants to avoid roll-back attacks the client MAY be configured to require the use of the Keying-Material Attribute.  If the client requires the use of the Keying-Material Attribute for keying material delivery and it is not present in the Access-Accept or Access-Challenge message, the client MAY ignore the message in question and end the user session."

> My recommendation is that this be rewritten to state the considerations 
> underlying the MAY, as well as recommended behavior in line with RFC 2865
> Section 5.26, which states:
> 
>       Clients which do not receive desired vendor-specific information
>       SHOULD make an attempt to operate without it, although they may do
>       so (and report they are doing so) in a degraded mode.
> 
> RFC 2865 is written this way to prevent the creation of proprietary RADIUS
> implementations that require the presence of vendor-specific information. 
> 
> Section 3.3
> 
>       Any packet that contains an instance of the Message-
>       Authentication-Code Attribute SHOULD NOT contain an instance of
>       the Message-Authenticator Attribute [RFC3579].
> 
> [BA] Since the Message-Authenticator Attribute is mandated by RFC 3579,
> this represents a contradiction.  My recommendation would be to remove
> this sentence, and require that the key used in computing the 
> Message-Authentication-Code be cryptographically independent of the
> RADIUS shared secret.  That way both attributes can be included without
> damage.
> 

[Joe] I think we can remove the sentence.  The section states that if both are present the Message-Authenticaiton-Code attribute is computed first, but there may be ambiguity as to whether the message-authenticator attribute is included in the calculation or not.    I would think it would be, I'd like to try to get some verification from implementers on this.  

> Section 5
> 
>    It is RECOMMENDED in this memo that two new keys, a key encrypting
>    key and a message authentication key, be shared by the RADIUS client
>    and server.  If implemented, these two keys MUST be different from
>    each other and SHOULD NOT be based on a password.  These two keys
>    SHOULD be cryptographically independent of the RADIUS shared secret
>    used in calculating the Response Authenticator [RFC2865], Request
>    Authenticator [RFC2866] [RFC5176] and Message-Authenticator Attribute
>    [RFC3579]; otherwise if the shared secret is broken, all is lost.
> 
> [BA] I believe that cryptgraphic independence of the RADIUS shared secret
> needs to be a MUST, since the goal of this document is to provide security
> even in a situation where the RADIUS shared secret could be compromised. 
> 

[Joe] I think we can make the cryptographic separation from the RADIUS shared secret a MUST. 

> Another issue is that there are a number of fields for which "the content 
> of this field is outside the scope of this document." The document
> needs to provide enough information on these fields to enable
> interoperability.  Currently it is not clear if this is the case. 
> 
> Fields which are not adequately explained include the following:
> 
> Section 3.1 Keying-Material
> 
>       KEK ID
> 
>          The KEK ID field is 16 octets in length and contains an
>          identifier for the KEK.  The KEK ID MUST refer to an encryption
>          key of a type and length appropriate for use with the algorithm
>          specified by the Enc Type field (see above).  This key is used
>          to protect the contents of the Data field (below).  Further
>          specification of the content of this field is outside the scope
>          of this document.
> 

[Joe]  Replace first sentence with:

"The KEK ID field is 16 octets in length.  The combination of the KEK ID and the client and server IP addresses together uniquely identify a key shared between the RADIUS client and server.  As a result, the KEK ID need not be globally unique."

Replace last sentence with:

"The KEK ID is a constant that is configured through an out-of-band mechanism.  The same value is configured on both the RADIUS client and server.  If no KEK ID is configured then the field is set to 0.  If  only a single KEK is configured for use between a given RADIUS client and server, then 0 can be used as the default value. 

>       KM ID
> 
>          The KM ID field is 16 octets in length and contains an
>          identifier for the contents of the Data field.  The KM ID MAY
>          be used by communicating parties to identify the material being
>          transmitted.  The combination of App ID and KM ID MUST uniquely
>          identify the keying material between the parties utilizing it.
>          The KM ID is assumed to be known to the parties that derived
>          the keying material.  If the KM ID is not used it is set to 0.
>          Further specification of the content of this field is outside
>          the scope of this document.
> 

[Joe] Remove "further specification... " and replace with:

"The KM ID for the EAP-MSK application is set to 0.   Another application can be defined in the future which uses the KM ID field. "


> Section 3.3  Message-Authentication-Code
> 
>       MAC Key ID
> 
>          The MAC Key ID field is 16 octets in length and contains an
>          identifier for the key.  The MAC Key ID MUST refer to a key of
>          a type and length appropriate for use with the algorithm
>          specified by the MAC Type field (see above).  Further
>          specification of the content of this field is outside the scope
>          of this document.
> 

[Joe]  Replace first sentence with:

"The MAC Key ID field is 16 octets in length.  The combination of the MAC Key ID and the client and server IP addresses together uniquely identify a key shared between the RADIUS client and server.  As a result, the MAC Key ID need not be globally unique."

Replace last sentence with:

"The MAC Key ID is a constant that is configured through an out-of-band mechanism.  The same value is configured on both the RADIUS client and server.  If no MAC Key ID is configured, then the field is set to 0.  If  only a single MAC Key ID is configured for use between a given RADIUS client and server, then 0 can be used as the default value. 

> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf