Re: Request for Review: "Issues and Fixes" changes

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
>> ...
>> Any Access-Request packet that performs authorization checks,
>> including Call Check, MUST contain a Message-Authenticator attribute.
> 
> I'm not sure what it means to say "performs authorization checks".  Do
> you mean that the Access-Request doesn't contain an authentication
> attribute (and therefore that State is required)?  While we do require
> "Authorize Only" Access-Requests to include a Message-Authenticator
> attribute, I'm not sure this is the only case.

  Yes.  The suggested text discusses Authorize Only specifically, but
leaves open the issue of what other authorization checks could be.

  I'd prefer to avoid discussion of "authentication attributes".  I
think it just causes confusion.

> I don't know that the RADIUS server can necessarily determine what
> attributes constitute "confidential information".

  The local administrator configuring the policy can do that.

>   So I think we need
> to try to simplify things somewhat.   Was there an issue with the RFC
> 2865 prescription (either include an authentication attribute or State)?

  Yes.  RFC 2865 mentions only User-Password and CHAP-Password, and
refers to other "authentication information".  We could extend the list
to include currently known authentication attributes.  But I think it's
better to give directions for future efforts.  The alternative is to
issue a later document that patches the list of authentication attributes.

>>   The Call-Check situation is one where the authentication is being done
>> on the call, via the Called / Calling Station Id.  So in this situation,
>> the Called / Calling Station id attributes are the authentication
>> attributes.
> 
> That seems like a reasonable explanation of the RFC 2865 MUST.  I'd
> suggest that we include this explanation in the text to clarify the
> meaning of "authentication attribute" in RFC 2865.

  RFC 2865 uses "authentication information", which seems vague, but useful.

>> ...  This practice should be discouraged, because it results in
>> giving an attacker both the clear-text and cipher-text for User-Password.
> 
> Which in turn can lead to compromise of the User-Password attribute if
> the Request Authenticator is every repeated with the same shared secret
> (e.g. global and temporal uniqueness required as per RFC 2865).  This
> also would be something worth including in the text.

  OK.

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

>>   The server doesn't need to use State for EAP.  It doesn't need to use
>> State for *some* challenge-response systems using User-Password.  It
>> doesn't need to use State for Call-Check... which doesn't leave many
>> areas where it is needed.
> 
> Yup.  RFC 2865 only REQUIRES State where "authentication attributes" are
> not present at all.  So if we can clarify what "authentication
> attributes" mean, then we'll know when State is required.

  State is not required for authentication.  State is required for
authorization checks.  I'm open to suggestions for more detailed text.

> As for other cases, I think it may depend on the attributes included in
> the Access-Accept.  However, in the interest of simplicity, it is
> probably not reasonable for the RADIUS server to keep track of all the
> situations in which a State attribute might be needed.

  I don't think it needs to keep track.  I think that particular
authentication mechanisms may mandate the use of State.  For
authorization, if the Access-Request doesn't contain a State, the server
won't be able to tie it to a previous authentication, and therefore
won't be able to return Access-Accept.

>>   I can't recommend when State MUST be used elsewhere, because I can't
>> think of other situations where it's needed.  The text already makes it
>> a MUST for Authorization-Only, and MUST for other authorization checks.
> 
> Can we define what "authorization checks" means? Is this just
> Service-Type = Call Check or Authorize-Only?

  Service-Type = Call Check is really (pre)-authentication.

  Authorize-Only is an authorization check, and is described as such in
the document,  The additional vague wording on "authorization checks" is
there to catch future uses, and to avoid repeating past mistakes.

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