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

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> Expires:  February 27, 2007
> 
> Shouldn't this be 2008?

  Yes.  I saw that just after the draft went out.

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

  OK...

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

  OK.

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

  Except that the MAC address checks don't set Service-Type = Call-Check
in many cases.  The paragraph tries to talk about Call Check
functionality where requests *don't* claim to be call check...

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

  OK.  Maybe "greatly simplifies" is an overstatement.  The
User-Password ciphertext is over only (S + RA), so that's less data to
hash than the Response Authenticator (packet + S).  But, the Response
Authenticator calculation can be pre-calculated for the packet, and only
the "secret" hash space searched.

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

  OK.  The MUST can be changed to a SHOULD, to match the other
suggestions for Message-Authenticator.

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

  Yes.

  Alan DeKok.

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