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

[Avi Lior <[e-mail]>]

Hi,

Wrt to UTF8String in diameter and lack of support in RADIUS. Well would the
RADIUS type TEXT work for you?

Text is defined in 2865 as  "Text contains UTF-8 encoded 10646
      [7] characters"

> -----Original Message-----
> From: Miguel Garcia [mailto:[e-mail]] 
> Sent: Thursday, November 11, 2004 8:55 AM
> To: Beck01, Wolfgang; Mari Carmen belinchon; Miguel-Angel 
> Pallares; ext Carolina Canales (ML/EEM); Pete McCann; 
> Rajaniemi Jaakko Matti; Tammi Kalle Tapani
> Cc: AAA mailing list; [e-mail]
> Subject: [AAA-WG]: Reconciling Radius/Diameter SIP application
> 
> 
> Hi:
> 
> I am deliberately cross posting to AAA and Radius-ext because 
> I believe 
> this topic is of interest for both lists.
> 
> Yesterday Wolfgang and me met for a few hours and set the goal of 
> reconcile the Diameter SIP application and the RADIUS HTTP/SIP Digest 
> drafts. These are the drafts:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-si
> p-app-04.txt
> 
> http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt
> 
> These are the main points we discuss. If you have any 
> comments, speak up 
> now, otherwise we will do the proposed changes in the relevant drafts:
> 
> 1- We agreed to modify the Diameter SIP application so that 
> it imports 
> the Digest-* AVP from the corresponding RADIUS attributes 
> address space. This came out of a comment from Jari Arkko, 
> and I think it is important 
> to avoid duplication of AVP/attributes.
> 
> As a side effect of the above, the SIP-Authentication-Context will 
> disappear in Diameter SIP app. This was a grouped AVP that only 
> contained a Digest-Entity-Body-Hash AVP. The latter will 
> remain (in the 
> RADIUS draft).
> 
> 2- We noticed a divergence in the Digest-Expected-Response AVP in 
> Diameter, which does not exist in RADIUS. RADIUS defines a Digest-HA1 
> attribute. The difference: Digest-HA1 contains H(A1), which 
> is computed 
> at the Radius server and sent to the Radius client, and it is used to 
> compute the expected response. In Diameter, the expected response is 
> computed at the Diameter server and sent to the client. This 
> assumes a 
> secure connection to avoid eavesdropping, which is not a problem for 
> Diameter that mandates IPsec or TLS. I think Diameter can go for the 
> Radius approach for compatibility reasons.
> 
> Proposal: Diameter will remove Digest-Expected-Response AVP and will 
> import Digest-HA1 from Radius.
> 
> 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).
> 
> 4- Currently here is a divergence on the definition of Digest-Stale 
> attribute: Diameter uses "true" and "false" (as per RFC2617), Radius 
> uses 1 and 0. We agreed to use "true" and "false" to avoid stupid 
> transcodings.
> 
> 5- Diameter indicates that the Digest-* AVPs contain the 
> quotes from/to 
> the Digest directive, Radius assumes (although does not indicate) no 
> quotes. We agreed that the Digest-* attributes do not need to include 
> the quotes from HTTP Digest parameters. So, there will be an explicit 
> indication that quotes are not part of the attribute value.
> 
> 6- We run into a problem when multiple SIP proxies are 
> authenticating the user, because at some point in time the 
> SIP request may contain several Proxy-Authorization headers. 
> The key here is the realm, it will be always different. If 
> different Diameter/Radius servers are 
> serving different realms, there is not problem. But, if a common 
> Diameter/Radius server is serving different realms, then the 
> server is 
> not able to determine which credentials should be evaluated.
> 
> We propose that the Diameter/Radius client MUST send only one set of 
> credentials at a time, those belonging to the served realm. This 
> requires to configure the Diameter/Radius client with the realm it is 
> serving. We will include some text indicating this case.
> 
> 7- Some of the attributes (e.g, Digest-Response and
> Digest-Response-Auth) had an artificial limit of 32 octets in 
> the value. While this value is correct for MD5 hashes, if in 
> the future other hashes are added to HTTP Digest, will run 
> into trouble. Proposal: don't restrict the length of a value.
> 
> 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.
> 
> 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.
> 
> 
> 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.
> 
> 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.
> 
> Any comments to any of the above?
> 
> Regards,
> 
>            Miguel
> 
> 
> 
> 
> -- 
> Miguel A. Garcia           tel:[phone]
> Nokia Research Center      Helsinki, Finland
>