[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  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.
There are two somewhat distinct issues. One is the authenticity of the Access-Request; that is addressed by adding Message-Authenticator. The other is whether the NAS is authorized to obtain the user's authorizations. That requires the NAS to demonstrate that it is acting on behalf of a live user via the inclusion of either an authentication attribute or State. 


RFC 3576 is silent on this issue, because it defines Authorize Only in
the context of CoA / Disconnect messages, and not for Access-Requests.


Right.


  Maybe something like this:

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


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.
I don't know that the RADIUS server can necessarily determine what attributes constitute "confidential information". 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)? 



  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. 


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


  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. 


  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.


Yes.


  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?)
In a CoA-Request with "Authorize Only" the DAC expects that an Access-Request will result. Now this presumes that the DAC can obtain a State Attribute that the RADIUS server will understand. Otherwise, the RADIUS server won't be able to make sense of the State Attribute provided by the DAC.
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 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? 



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