RE: [AAA-WG]: Reconciling Radius/Diameter SIP application

[Avi Lior <avi@bridgewatersystems.com>]

Miguel, Wolfgang and Jari,

I am trying to get a deeper understanding here. But it seems to me that in
Scenario 1 where the RADIUS Client is generating the nonces, the client
really needs to be the one that determines the staleness of the nonces and
not the AAA.  Therefore, the client will not even invoke the AAA server when
the nonce is stale; and the AAA will just assume that all nonces are valid.


> > 8- In the Radius document, scenario 1, we have a question. 
> We suspect 
> > that this scenario does not work if the Radius client generates a 
> > nextnonce. The reason is that in the following authentication, when 
> > the nextnonce becomes a nonce, the Radius server will not recognize 
> > the nonce as locally generated (it was generated by the Radius 
> > client), and will reject the request with a "state=true". RFC 2617 
> > seems to describe the case:
> > 
> >    If the
> >    nextnonce field is present the client SHOULD use it when 
> constructing
> >    the Authorization header for its next request. Failure 
> of the client
> >    to do so may result in a request to re-authenticate from 
> the server
> >    with the "stale=TRUE".
> > 
> > Does anyone have any comment? Can anyone confirm that the 
> operation in
> > Digest is as we indicate? We will add some text indicating the 
> > limitations of Scenario 1.
> 
> In looking at this, I have the same question as you. So no
> help from me, sorry.
> 
> > 9- The Radius draft, in section 2.15, indicates:
> > 
> >          RADIUS
> >          servers that do not implement a parameter contained in a
> >          Digest-Auth-Param attribute MUST respond with an 
> Access-Reject
> >          message.  RADIUS clients that do not implement a parameter
> >          contained in a Digest-Auth-Param attribute MUST reject the
> >          original HTTP-style request.
> > 
> > The problem is that the text seems to go against RFC 2617 that says:
> > 
> >    auth-param
> >      This directive allows for future extensions. Any unrecognized
> >      directive MUST be ignored.
> > 
> > The proposal is to remove the above text from the RADIUS draft.
> 
> Yes, this is correct.
> 
> > 10- Similar contradictory text was found in Section 2.16 of 
> the RADIUS
> > draft, that says:
> > 
> >   RADIUS servers that do
> >   not implement AKA Digest MUST response with an Access Reject
> >   message.
> > 
> > We propose to remove the above text. The motivation is that the
> > algorithm already conveys the AKA (AKA extends the algorithm to be 
> > AKAv1-MD5 and AKAv1-MD5-sess). The server chooses the 
> algorithm, so the 
> > situation currently described, where the client may include an auts 
> > attribute, is just an error case, where the client made a 
> mistake and 
> > included AUTS when not doing AKA. In case the Radius server 
> does not 
> > implement AKA authentication, it will safely ignore this AVP.
> 
> Right.
> 
> > 11- We noticed that most of the HTTP Digest directives 
> contain just a
> > single token. However, the "qop" directive may contain a 
> comma-separated 
> > collection of tokens. For instance, qop="auth,auth-int". 
> The question is 
> > how do encode these tokens in the Digest-Qop attribute. The 
> options are:
> > 
> > a) Treat the whole thing as one token and put it into the attribute 
> > value.
> > b) Each token is an attribute, thus, there might be 
> multiple Digest-Qop 
> > attributes in a particular Radius/Diameter message.
> > 
> > We think that option b) is cleaner. Particularly it will be 
> easier for
> > the Diameter/Radius client to encode different values in different 
> > attributes.
> 
> I think option a) is cleaner, although I don't care enough to 
> think it should be a showstopper. But here's my reasoning: 
> avoid unnecessary mapping work that the client needs to do; 
> handle everything as much as possible by taking all text from 
> the SIP syntax and putting it blindly into an AVP...
> 
> --Jari
> 
> 
> --
> 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/>
> 

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