Re: [secdir] Secdir review of draft-ietf-softwire-6rd-radius-attrib-07

[Bernard Aboba <[e-mail]>]

> Joseph Salowey (jsalowey) wrote:

>Therefore RADIUS messages using the 6rd attribute MUST include a 
message-authenticator attribute or another attribute that is capable of 
authenticating the RADIUS packet.  
> 
>   I missed that.  I agree with the requirement for a Message-Authenticator.

[BA]
 Yes, as currently specified the Access-Request is not authenticated or 
integrity protected, and is therefore susceptible to forgery.  

> > 1.  A RADIUS message used for call-check does not contain any information that would authenticate the request.  

[BA] There isn't even any information with which to authorize the request.  The "Call Check" Service-Type was designed for situations where authorization can be determined via the Called-Station-Id or Calling-Station-Id attributes, which originally contained telephone numbers.  In RFC 3580, Called/Calling-Station-Id could also contain a MAC address, but the principle was similar -- an unique (non-authenticated) identifier which could be used to determine whether a call was authorized.  Here is what RFC 2865 Section 5.6 says about Call Check:

     Call Check          Used by the NAS in an Access-Request packet to
                          indicate that a call is being received and
                          that the RADIUS server should send back an
                          Access-Accept to answer the call, or an
                          Access-Reject to not accept the call,
                          typically based on the Called-Station-Id or
                          Calling-Station-Id attributes.  It is
                          recommended that such Access-Requests use the
                          value of Calling-Station-Id as the value of
                          the User-Name.
However, this document does not say anything about use of the Calling-Station-Id or Called-Station-Id attributes, or the value of the User-Name attribute.  Given that, the use of Service-Type = "Call Check" would not seem to apply.

> > 2.   I'm not so familiar with the deployment scenario here so I have a question.  Is it possible that the BNG was involved in a previous transaction with the AAA server to authenticate a user?   If this is the case then the BNG may have received a state attribute in the access-accept message.   Returning this state attribute to the AAA server allows the AAA server to link the 6rd request with the original authentication transaction.    If this is a possible scenario the document should specify this since state attributes are not typically used with the call-check service.  Also if its the case that there could have been a related previous authentication session it seems that it should be possible to include this attribute in an access-request as part of the authentication exchange.  
> 
>   I *think* that the answer here is "no".  The document previously used
> Service-Type = Authorize-Only and a State attribute.  After some
> discussion, it was decided to change that to Call-Check, because there
> was no way to obtain a State attribute.

[BA] As I understand it, at least one of the scenarios described in the document would involve the retrieval of DHCP information along with a user authentication.  In such a scenario, why would either Authorize-Only or Call Check be needed?

> 3.  It was not clear in the specification what is sent in the access-request message is the BNG is looking to get a IPv6-6rd-configuration attribute in the access accept.  It seems that you would need to send this attribute in the request if you expected it in the response or else the AAA server would not be able to un-ambiguously be able to service the request; there are other uses for the call-check service.   I think you should specify that the 6rd attribute must be in the request if you want to see it in the response.   
> 

[BA] Yes.  Otherwise the RADIUS server would not know that an IPv6-6rd-configuration attribute was needed.