RE: [Issue] RFC 3576 Usage of Message-Authenticator

[Bernard Aboba <aboba@internaut.com>]

> > 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)
>
> 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.

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/>