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

From: Avi Lior <[email-masked]>
Date: Wed, 24 Nov 2004 10:26:01 -0500

Hi Miquel, Jarri,

> > 3- Radius does not define UTF8String data types, so all these 
> > attributes
> > will remain as String, but the Radius draft will indicate 
> that contain a
> > UTF8String verbally (this is required by HTTP and SIP).

Just one point now.  RADIUS "Text" type attributes are UTF-8 compliant.  I
just want to make sure that the definition of Text and UTF8String are the
same. And they appear to be.

From RFC 2865:

text      1-253 octets containing UTF-8 encoded 10646 [7]
                characters.  Text of length zero (0) MUST NOT be sent;
                omit the entire attribute instead.

[7]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
         2279, January 1998.

From RFC 3588:

This is a human readable string represented using the
      ISO/IEC IS 10646-1 character set, encoded as an OctetString using
      the UTF-8 [UFT8] transformation format described in RFC 2279.

So where applicable the attributes in Sterman should be set to Text.

---

From: Avi Lior <[email-masked]>
Date: Wed, 24 Nov 2004 11:15:15 -0500

Option b) is cleaner because it requires less parsing work by AAA server.

Regarding the following comment:

> handle everything 
> as much as 
> > possible by taking all text from the SIP syntax and putting 
> it blindly 
> > into an AVP...

Wolfgang's original document did that for all the attributes (using
subtypes) which could have been handled by both RADIUS and Diameter. Lets
not go there again.

> > 
> >> 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...
> > 
> 
> I don't care either. I just thought we shouldn't put too much work to 
> the Diameter/Radius server about how to encode Digest directives. 
> Approach a requires the Diameter/Radius server to be able to encode 
> "auth", "aut-int", "auth,auth-int", and use it appropriately. If the 
> number of tokens is just two, then any approach is feasible.
> 
> - Miguel
> 
> 
> > --Jari
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
>

---

From: Avi Lior <[email-masked]>
Date: Wed, 24 Nov 2004 11:23:32 -0500

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.
> 
> 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:
> > 
> > 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
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>