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

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> For example, if an Access-Request contains neither an authentication
> attribute or State attribute, there are security implications.

  Some of which can be dealt with by mandating Message-Authenticator.
Once the NAS is authenticated, there are fewer security issues with
allowing it to perform authorization checks.

  I would also add that since authorization checks do not include
authentication attributes, they MUST include a Message-Authenticator.
RFC 3576 is silent on this issue, because it defines Authorize Only in
the context of CoA / Disconnect messages, and not for Access-Requests.

  Maybe something like this:

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

> Some RADIUS attributes (such as Tunnel-Password) reveal confidential
> information about a user, and so they require some evidence of user
> authentication.  Therefore if there is no authentication attribute
> present, then the server needs some evidence that the request is linked
> to a previous user authentication, so that the server is authorized to
> answer the request.  That evidence is provided by the State Attribute.

  Yes.  See above.

> RFC 2865 has a MUST relating to inclusion of authentication attributes
> or State within an Access-Request.  It would seem that this ignored some
> cases (such as Call-Check) in which State either is optional or
> realistically can't be included at all.

  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.

  However, most systems implementing this kind of check (e.g. MAC
address checking) do so by setting the User-Name and User-Password to
the MAC address.  This is done because it's easier to just add a MAC
address as a user/password, rather than implementing a Call-Check
policy.  This practice should be discouraged, because it results in
giving an attacker both the clear-text and cipher-text for User-Password.

>  Given this situation, I don't
> believe that a SHOULD would provide the required clarification. Instead,
> it would be better to clarify the cases in which State is a MUST  and
> the cases in which it is optional.

  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.

  The most common use of State seems to be in *addition* to the
authentication attributes.  e.g. EAP, or challenge-response methods that
leverage User-Password.

  A less common use of State is for authorization checks, in order to
tie the authorization checks to a previous authentication session.  (And
how does the server know that the NAS will need State for use in a later
authorization check?  Should the server ALWAYS send State back?)

  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.
 Everything else is a SHOULD.

  This is what the text says today.  Are there additional suggestions
for "... MUST use State" ?

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