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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf