More comments on draft-ietf-radext-fixes-06.txt

["Bernard Aboba" <bernard_aboba@hotmail.com>]

Expires:  February 27, 2007

Shouldn't this be 2008?

Section 2.1.1

  In contrast, Access-Requests which are intended to perform
  authorization checks MUST contain a State attribute in order to tie
  the authorization check to a previous authentication session.  This
  last requirement often means that an Access-Accept needs to contain a
  State attribute, which is then used in a later Access-Request that
  performs authorization checks.

[BA] The MUST here seems to be contradicted by text below relating to
Call Check.  My advice is to i ntegrate the last sentence into one of the
paragraphs below and delete the first sentence.

  Access-Request packets that contain a Service-Type attribute with
  value Authorize Only (17) MUST contain a State attribute.  Access-
  Request packets that contain a Service-Type attribute with value Call
  Check (10) SHOULD NOT contain a State attribute.  Any other Access-
  Request packet that performs authorization checks MUST contain a
  State attribute.

[BA] This paragraph seems to state the requirement more clearly.

  The standard use case for Call-Check is pre-screening authentication
  based solely on the end-point identifier information, such as phone
  number or MAC address in Calling-Station-ID and optionally Called-
  Station-ID.  In that use case there is no source of the State
  attribute in the NAS.

[BA] Suggest changing to "In this use case, the NAS has no way to obtain
a State Attribute suitable for inclusion in an Access-Request."

  Other, non-standard, uses of Call-Check may
  require or permit the use of a State Attribute, but are beyond the
  scope of this document.

  Implementing Call Check functionality via requests where the User-
  Name and User-Password contain the same information (e.g. MAC
  address) is NOT RECOMMENDED.

[BA] Suggest rewriting to:  "In an Access-Request with a Service-Type
Attribute with value "Call Check", it is NOT RECOMMENDED for the User-Name
and User-Password attributes to contain the same values (e.g. a MAC
address)."

  This practice gives an attacker both
  the clear-text and cipher-text of the User-Password field, which
  permits many additional attacks on the security of the RADIUS
  protocol.  For example, if the Request Authenticator does not satisfy
  the [RFC2865] requirements on global and temporal uniqueness, the
  practice described above may lead to the compromise of the User-
  Password attribute in other Access-Requests for unrelated users.
  Access to the cipher-text also greatly simplifies offline dictionary
  attacks, potentially exposing the shared secret, and compromising the
  entire RADIUS protocol.

[BA] I think you mean "Access to the cleartext", no?  BTW, how does this
simplify offline dictionary attacks?  Seems like an attack on the Response
Authenticator or Message-Authenticator attributes remains the weak link.

  Any Access-Request packet that performs authorization checks,
  including Call Check, MUST contain a Message-Authenticator attribute.
  Any response to an Access-Request performing an authorization check
  MUST NOT contain confidential information about any user (such as
  Tunnel-Password), unless that Access-Request contains a State
  attribute.  The use of State here permits the authorization check to
  be tied to an earlier user authentication.  In that case, the server
  MAY respond to the NAS with confidential information about that user.
  The server MUST NOT respond to that authorization check with
  confidential information about any other user.

[BA] Given that Call Check is defined in RFC 2865, which does not require
Message-Authenticator this appears to be imposing requirements on legacy
implementations.  Today Call Check can return any attribute that is
configured; I am not sure how this would modify that.

Rather than talking about "confidential information" (which is somewhat
vague), it probably makes more sense to recommend how a RADIUS server
should response to an Access-Request implementing an authorization check
that does not include a State attribute.  Since earlier it is stated
that an "Authorize Only" Access-Request MUST contain a State attribute,
it would seem that the RADIUS server should send an Access-Reject, no?



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