Re: [AAA-WG]: Reconciling Radius/Diameter SIP application
Miguel Garcia <Miguel.An.Garcia@nokia.com> Thu, 11 November 2004 21:08 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 QAA28229 for <aaa-archive@lists.ietf.org>; Thu, 11 Nov 2004 16:08:10 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2477E91311; Thu, 11 Nov 2004 16:08:04 -0500 (EST)
Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E18AF91313; Thu, 11 Nov 2004 16:08:03 -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 5C67B91311 for <aaa-wg@trapdoor.merit.edu>; Thu, 11 Nov 2004 16:08:02 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 439AB585B4; Thu, 11 Nov 2004 16:08:02 -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 636AB585B1 for <aaa-wg@merit.edu>; Thu, 11 Nov 2004 16:08:01 -0500 (EST)
Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABL7fF21309; Thu, 11 Nov 2004 23:07:42 +0200 (EET)
X-Scanned: Thu, 11 Nov 2004 23:05:19 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iABL5JmW008019; Thu, 11 Nov 2004 23:05:19 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Ibx183; Thu, 11 Nov 2004 23:05:16 EET
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABL5Ga10087; Thu, 11 Nov 2004 23:05:16 +0200 (EET)
Received: from [10.162.14.168] ([10.162.14.168]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 23:05:11 +0200
Message-ID: <4193D404.7020505@nokia.com>
Date: Thu, 11 Nov 2004 23:05:08 +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: Avi Lior <avi@bridgewatersystems.com>
Cc: "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>, AAA mailing list <aaa-wg@merit.edu>, radiusext@ops.ietf.org
Subject: Re: [AAA-WG]: Reconciling Radius/Diameter SIP application
References: <F17FB067A86B2D488382C923C532EAA7024A4DA0@exch01.bridgewatersys.com>
In-Reply-To: <F17FB067A86B2D488382C923C532EAA7024A4DA0@exch01.bridgewatersys.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Nov 2004 21:05:12.0036 (UTC) FILETIME=[222AB240:01C4C832]
Sender: owner-aaa-wg@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
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:Miguel.An.Garcia@nokia.com] >>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; radiusext@ops.ietf.org >>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
- [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