[AAA-WG]: Reconciling Radius/Diameter SIP application
Miguel Garcia <Miguel.An.Garcia@nokia.com> Thu, 11 November 2004 14:16 UTC
Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13199 for <aaa-archive@lists.ietf.org>; Thu, 11 Nov 2004 09:16:19 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8D171912F0; Thu, 11 Nov 2004 09:16:13 -0500 (EST)
Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 521FA912F1; Thu, 11 Nov 2004 09:16:13 -0500 (EST)
Delivered-To: aaa-wg@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACA57912F0 for <aaa-wg@trapdoor.merit.edu>; Thu, 11 Nov 2004 09:16:11 -0500 (EST)
Received: by segue.merit.edu (Postfix) id BED1F5854E; Thu, 11 Nov 2004 09:16:09 -0500 (EST)
Delivered-To: aaa-wg@merit.edu
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 06BBF584AD for <aaa-wg@merit.edu>; Thu, 11 Nov 2004 09:16:03 -0500 (EST)
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABEFtF04921; Thu, 11 Nov 2004 16:15:56 +0200 (EET)
X-Scanned: Thu, 11 Nov 2004 16:11:57 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iABEBv7S024888; Thu, 11 Nov 2004 16:11:57 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00HM6HZv; Thu, 11 Nov 2004 16:10:14 EET
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABDtda11873; Thu, 11 Nov 2004 15:55:39 +0200 (EET)
Received: from [10.162.14.168] ([10.162.14.168]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 15:55:26 +0200
Message-ID: <41936F4C.5080201@nokia.com>
Date: Thu, 11 Nov 2004 15:55:24 +0200
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: "Beck01, Wolfgang" <BeckW@t-systems.com>, Mari Carmen belinchon <maria.carmen.belinchon@ericsson.com>, Miguel-Angel Pallares <miguel-angel.pallares@ericsson.com>, "ext Carolina Canales (ML/EEM)" <carolina.canales@ericsson.com>, Pete McCann <mccap@lucent.com>, Rajaniemi Jaakko Matti <jaakko.rajaniemi@nokia.com>, Tammi Kalle Tapani <kalle.tammi@nokia.com>
Cc: AAA mailing list <aaa-wg@merit.edu>, radiusext@ops.ietf.org
Subject: [AAA-WG]: Reconciling Radius/Diameter SIP application
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Nov 2004 13:55:26.0314 (UTC) FILETIME=[18ADC4A0:01C4C7F6]
Sender: owner-aaa-wg@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
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-sip-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
- [AAA-WG]: Reconciling Radius/Diameter SIP applica… Miguel Garcia
- RE: [AAA-WG]: Reconciling Radius/Diameter SIP app… Avi Lior
- Re: [AAA-WG]: Reconciling Radius/Diameter SIP app… Miguel Garcia
- Re: [AAA-WG]: Reconciling Radius/Diameter SIP app… Jari Arkko
- Re: [AAA-WG]: Reconciling Radius/Diameter SIP app… Miguel Garcia
- RE: [AAA-WG]: Reconciling Radius/Diameter SIP app… Avi Lior
- RE: [AAA-WG]: Reconciling Radius/Diameter SIP app… Avi Lior
- RE: [AAA-WG]: Reconciling Radius/Diameter SIP app… Avi Lior
- Re: [AAA-WG]: Reconciling Radius/Diameter SIP app… Jari Arkko
- RE: [AAA-WG]: Reconciling Radius/Diameter SIP app… Avi Lior
- Re: [AAA-WG]: Reconciling Radius/Diameter SIP app… Miguel Garcia
- Re: [AAA-WG]: Reconciling Radius/Diameter SIP app… Miguel Garcia