[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed Resolution to RFC 3576bis Issue 55: Message-Authenticator Attribute
The text of Issue 55 is enclosed below. The basic problem is that the lack
of a nonce in the Request Authenticator of the CoA or Disconnect-Request
presents a chicken-egg issue. The Message-Authenticator attribute depends
on the RA and the RA depends on the Message-Authenticator.
The issue could be solved either by prohibiting inclusion of the
Message-Authenticator in CoA or Disconnect-Request or Response messages.
It can also be fixed by having the Message-Authenticator be calculated based
on assuming that the RA and Message-Authenticator attribute consisted of all
zeroes. The RA could then be calculated based on the actual
Message-Authenticator attribute.
Given the potential weakness of the keyed MD5 construction used to calculate
the Request and Response Authenticator field, enabling use of the
Message-Authenticator Attribute seems like the better choice for now.
The proposed resolution is as follows:
Leave the entries in the attribute table for Message-Authenticator as "0-1".
Add Section 3.2:
"3.2. Message-Authenticator
The Message-Authenticator Attribute MAY be used to authenticate and
integrity-protect Disconnect/CoA-Request, ACK and NAK packets in
order to prevent spoofing.
A RADIUS client receiving a CoA or Disconnect-Request with a Message-
Authenticator Attribute present MUST calculate the correct value of
the Message-Authenticator and silently discard the packet if it does
not match the value sent. A RADIUS server receiving a
CoA/Disconnect-ACK or CoA/Disconnect-NAK with a Message-Authenticator
Attribute present MUST calculate the correct value of the Message-
Authenticator and silently discard the packet if it does not match
the value sent.
When a Message-Authenticator Attribute is included within a CoA or
Disconnect-Request, it is calculated as follows:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
When the HMAC-MD5 message integrity check is calculated the
Request Authenticator field and Message-Authenticator Attribute
should be considered to be sixteen octets of zero. The Message-
Authenticator Attribute is calculated and inserted in the packet
before the Request Authenticator is calculated.
When a Message-Authenticator Attribute is included within a CoA or
Disconnect-ACK/NAK, it is calculated as follows:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
When the HMAC-MD5 message integrity check is calculated the
Message-Authenticator Attribute should be considered to be sixteen
octets of zero. The Request Authenticator is taken from the
corresponding CoA/Disconnect-Request. The Message-Authenticator
is calculated and inserted in the packet before the Response
Authenticator is calculated."
-------------------------------------------------------------------------------------------------------------------------
Issue 55: Message-Authenticator Attribute
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: January 28, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00082.html
Document: RFC 3576bis
Comment type: T
Priority: S
Section: 3.2
Rationale/Explanation of issue:
RFC 3576 calculation of the Request and Response Authenticator is modeled
after RFC 2866 (RADIUS Accounting). However, the Message-Authenticator
attribute is not allowed in Accounting-Request and Accounting-Response
messages, because these messages do not contain a random Request
Authenticator, as specified in RFC 3579:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
It therefore would appear that a Message-Authenticator attribute is not
allowed in CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request,
Disconnect-ACK or Disconnect-NAK messages.
This is contrary to the table in Section 3.2, which has the following
entry for both CoA and Disconnect messages:
Request ACK NAK # Attribute
0-1 0-1 0-1 80 Message-Authenticator
Proposed Resolution:
My proposal is that we submit an errata to RFC 3576, changing the "0-1"
entries to "0" entries.
[John Loughney]
I agree with your proposal.
[Murtaza Chiba]
Sounds good. Somewhat related, there are Vendor attributes that are
encrypted,
although we want to discourage per attribute encryption, the fact of the
matter
is that Customers are using it. So I would like to request a new attribute
Initialization-Vector that can be used for all encrypted attributes in CoA
and Disconnect Messages.
[Bernard Aboba]
In looking through the Attribute table in RFC 3576, Section 3.2, there
appears to be two attributes that depend on the Request Authenticator:
Message-Authenticator (80), and Tunnel-Password (69).
If the desire were to change the value of the Tunnel-Password attribute or
any other attribute depending on the Request Authenticator, one way to
get around the chicken-egg problem would be to send a CoA-Request
with Service-Type="Authorize Only". The encrypted attribute would not need
to
be present in the CoA-Request, but could then be present in a subsequent
Access-Accept, using the existing attribute definitions.
It would therefore appear to me that the Tunnel-Password attribute should
probably also have a "0" for its entries in the table in Section 3.2,
instead of "0-1".
Defining a new Nonce attribute, and then re-defining existing
IETF standard attributes to use it when present in a CoA-Request seems
somewhat problematic to me.
[Glen Zorn]
The word "random" is not present in RFC 3579; therefore it's hard to
see how one can claim that a random Request Authenticator is
"specified" thereby. Maybe a better phrase would be "tacitly
assumed by the authors"? In any case, however, I agree that the use
of the accounting-style Request Authenticator in the generation of
the Message-Authenticator Attribute is probably inappropriate.
Given the existence of the above-mentioned and undocumented
assumption in RFC 3579 and the effect that the absence of the
Message-Authenticator Attribute on the already less-than-stellar
security properties of RFC 3576, I think that more than just a
change in a table is required. For example, the usage of the
Event-Timestamp for replay detection in 3576 would seem to be
weakened. I really think that the assumption in RFC 3579 needs to
be laid bare; I'm not sure whether an erratum is sufficient for this
or if an applicability statement needs to be published.
[Bernard Aboba]
The term is used in RFC 2865, though. For example, in Section 5.2:
Call the shared secret S and the pseudo-random 128-bit Request
Authenticator RA.
In this particular case, I think the issue was not so much whether the
Request Authenticator from RFC 2866 is pseudo-random but rather the
circular dependency: Message-Authenticator, Tunnel-Password, etc. depend
on the RA, but the RA depends on the attributes.
If the issue were merely pseudo-randomness, then perhaps it might be
solved by including a pseudo-random attribute (e.g. a Nonce) in the
Request, in order to introduce entropy into the calculated RA.
For example, the usage of the
Event-Timestamp for replay detection in 3576 would seem to be
weakened.
Can you elaborate? Is this because the RA calculation involves MD5,
rather than HMAC-MD5? From RFC 2866:
The NAS and RADIUS accounting server share a secret. The Request
Authenticator field in Accounting-Request packets contains a one-
way MD5 hash calculated over a stream of octets consisting of the
Code + Identifier + Length + 16 zero octets + request attributes +
shared secret (where + indicates concatenation). The 16 octet MD5
hash value is stored in the Authenticator field of the
Accounting-Request packet.
I really think that the assumption in RFC 3579 needs to
be laid bare; I'm not sure whether an erratum is sufficient for this
or if an applicability statement needs to be published.
I'm not sure how RFC 3579 comes into play here, since it only
defines usage of Message-Authenticator in
Access-Request, Challenge, Accept and Reject packets, not in
Accounting-Request/Response or CoA/Disconnect messages.
Here is the text from Section 3.2:
When present in an Access-Request packet, Message-Authenticator is
an HMAC-MD5 [RFC2104] hash of the entire Access-Request packet,
including Type, ID, Length and Authenticator, using the shared
secret as the key, as follows.
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
When the message integrity check is calculated the signature
string should be considered to be sixteen octets of zero.
For Access-Challenge, Access-Accept, and Access-Reject packets,
the Message-Authenticator is calculated as follows, using the
Request-Authenticator from the Access-Request this packet is in
reply to:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
When the message integrity check is calculated the signature
string should be considered to be sixteen octets of zero. The
shared secret is used as the key for the HMAC-MD5 message
integrity check. The Message-Authenticator is calculated and
inserted in the packet before the Response Authenticator is
calculated.
--
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/>