Re: Issue 7: Message Authenticator

[Bernard Aboba <aboba@internaut.com>]

Avi Lior said:

"Based on the comments received on this issue.
-It is important to have some sort of authenticator.
-Message Authenticator(80) is not busted - HMAC-MD5
-Digest Authentication is based on MD5 anyway.

I propose that we make Message-Authenticator(80) mandatory to protect the
Access-Requests."

I think you're making the case that improving the security beyond
MD5/Message-Authenticator is a bigger project than can be taken on in this
document, given the completion dates envisaged by 3GPP2 (e.g. yesterday).

Part of the issue is defining the goals of a more extended effort.  So
far, the goal that has been most mentioned is to enable RADIUS to achieve
FIPS compliance.  However, that is not a short-term goal since NIST has
not provided us with a list of required changes to RADIUS.  It is
conceivable that achieving FIPS certification for RADIUS might require
the removal of all MD5 usage from the RADIUS protocol (including zero'ing
out of the Response Authenticator field), and definition
of new authentication mechanisms and attributes for not involving MD5.

Those changes would in turn bring up backward compatibility issues which
would take some time to resolve.  So it's hard to get a handle on the
work required to achieve FIPS compliance at this time, although it
could be quite substantial.

In the meantime, are you saying that the Message-Authenticator attribute
MUST be included in any message (Request, Challenge, Accept/Reject) containing
attributes defined in this document, and that a RADIUS client or server
receiving a message with the attribute MUST check it and MUST silently discard
a packet that fails the check?

I'm ok with this, assuming that the appropriate text can be developed and
posted.  It might help to cite RFC 3579 text relating to
Message-Authentocator.   For example, in Section 3.1:

"     Therefore the Message-Authenticator attribute MUST be used to
      protect all Access-Request, Access-Challenge, Access-Accept, and
      Access-Reject packets containing an EAP-Message attribute.

      Access-Request packets including EAP-Message attribute(s) without
      a Message-Authenticator attribute SHOULD be silently discarded by
      the RADIUS server.  A RADIUS server supporting the EAP-Message
      attribute MUST calculate the correct value of the
      Message-Authenticator and MUST silently discard the packet if it
      does not match the value sent.  A RADIUS server not supporting the
      EAP-Message attribute MUST return an Access-Reject if it receives
      an Access-Request containing an EAP-Message attribute.

      Access-Challenge, Access-Accept, or Access-Reject packets
      including EAP-Message attribute(s) without a Message-Authenticator
      attribute SHOULD be silently discarded by the NAS.  A NAS
      supporting the EAP-Message attribute MUST calculate the correct
      value of the Message-Authenticator and MUST silently discard the
      packet if it does not match the value sent."

Section 3.2:

"3.2.  Message-Authenticator

      This attribute MAY be used to authenticate and integrity-protect
      Access-Requests in order to prevent spoofing.  It MAY be used in
      any Access-Request.  It MUST be used in any Access-Request,
      Access-Accept, Access-Reject or Access-Challenge that includes an
      EAP-Message attribute.

      A RADIUS server receiving an Access-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 client receiving an Access-Accept, Access-Reject or
      Access-Challenge 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.

      This attribute is not required in Access-Requests which include
      the User-Password attribute, but is useful for preventing attacks
      on other types of authentication.  This attribute is intended to
      thwart attempts by an attacker to setup a "rogue" NAS, and perform
      online dictionary attacks against the RADIUS server.  It does not
      afford protection against "offline" attacks where the attacker
      intercepts packets containing (for example) CHAP challenge and
      response, and performs a dictionary attack against those packets
      offline."

BTW, I should also mention that the document is missing the traditional
"Table of Attributes" which states what packets various attributes can be
included in.



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