[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Review of draft-zorn-radius-keywrap-07.txt
Having looked at draft-zorn-radius-keywrap-07.txt, in general I think
that the proposal is quite ingenious.
If it I understand it correctly, the proposal addresses many of the
weaknesses of MD5 usage in RADIUS while still enabling support for
backward compatibility. It can therefore be introduced on a NAS and
RADIUS server without requiring changes to RADIUS proxies, or
on a RADIUS server but not all NAS devices. Of course, to address all the
MD5 vulnerabilities all RADIUS clients and servers need to be upgraded
eventually, but the transition can be graceful.
However, since I may not fully grasp the proposal, I thought I'd summarize
the main aspects as I understand it:
a. If I read the document correctly, it is possible for an implementation
to compute all the Request and Response authenticators based on a RADIUS
shared secret, *exactly* as it is done today. As a result, the proposal
is compatible with legacy RADIUS proxies and servers.
In addition to a legacy shared secret, the proposal also creates
additional shared secrets, namely the Key Encryption Key (KEK) and the MAC
Key. These additional shared secrets are presumably independent of the
RADIUS shared secret so that if the RADIUS shared secret is compromised,
an attacker will still be unable to forge messages or decrypt the wrapped
key.
Just like existing RADIUS shared secrets, the KEK and MAC Key are
hop-by-hop secrets.
b. The document also includes definition of a new
Message-Authentication-Code attribute, which is a MAC calculated over the
RADIUS packet in a manner similar to the existing
Message-Authenticator attribute, albeit using the new MAC key and more
secure MAC algorithms, such as HMAC-SHA-1 and HMAC-SHA-256.
To maintain backward compatibility, this attribute can be added to a
RADIUS packet in addition to the existing Message-Authenticator attribute,
which is required by RFC 3579 and the Digest Authentication document. A
RADIUS server can tell whether a RADIUS client supports this new
attribute by the presence of the attribute in an Access-Request, so that
a server need not send the attribute to a RADIUS client that does not
support it.
Since the RADIUS client can compute *both* the Message-Authenticator and
the new Message-Authentication-Code attribute, it need not worry about
whether the RADIUS server supports the new attribute or not; it can just
send both attributes.
c. The document includes definition of a Random-Nonce attribute, which
among other things can be used to address the replay protection problems
that exist in Accounting-Request, CoA-Request and Disconnect-Request messsages.
Since these messages do not include a Nonce in the Request Authenticator
field, in existing usage there is a danger of replay. While the issue is
handled for Accounting-Request messages by checking for duplication of
Acct-Session-ID values in the billing engine, RFC 3576 relies on
inclusion of the Event-Timestamp attribute in CoA-Request and
Disconnect-Request messages. This requires RADIUS clients and servers to
implement time synchronization, which may be inconvenient. As a result,
it seems to me that the Random-Nonce attribute has general utility.
However, on reading the proposal, I did have some questions:
d. If the KEK and MAC Key are hop-by-hop secrets, are they similar to the
existing RADIUS shared secret in that there can only be one secret between
a given (client IP address, server IP address) pair? If so, then I don't
understand the need for the MAC Key ID field in the Message-Authentication-Code
attribute, or the Key-ID, KEK-ID and App-ID fields in the Key attribute.
After all, the existing RADIUS shared secret does not need a key name
because this is implicit in the source and destination addresses within
the RADIUS packet.
e. As described in IEEE 802.11i and the EAP Key Framework document, the
lifetime of EAP keying material is determined by the Session-Time
attribute. As a result, what is the purpose of the Lifetime field within
the Key attribute?
f. Since it is possible to mount an offline dictionary attack on the KEK
and MAC Key just as with the existing RADIUS shared secret, presumably the
KEK and MAC Key are not derived from a passphrase and users need to take
care to maintain proper hygene (e.g. keys should be unique for each RADIUS
client/server pair, minimum entropy is required. etc.), right?
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>