Re: : Reconciling Radius/Diameter SIP application

Absolutely right.

Wolfgang, will you please change the type of the Digest-* attributes to 
"text" ?

- Miguel

Avi Lior wrote:

> 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:[email protected]] 
>>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; [email protected]
>>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:+358-50-4804586
>>Nokia Research Center      Helsinki, Finland
>>

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland