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

From: Miguel Garcia <[email-masked]>
Date: Thu, 11 Nov 2004 15:55:24 +0200

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Nov 2004 15:34:47 +0200

> contained a Digest-Entity-Body-Hash AVP. The latter will remain (in the 

Great!

> import Digest-HA1 from Radius.

Ok.

> UTF8String verbally (this is required by HTTP and SIP).

Hm, I guess this is OK.

> uses 1 and 0. We agreed to use "true" and "false" to avoid stupid 

This is much better. Good.

> indication that quotes are not part of the attribute value.

This is better too.

> serving. We will include some text indicating this case.

I fail to see the problem, most likely due to the insufficient
understanding of the protocol details on my part. But will
your solution lead to some problem if there's roaming
involved?

> trouble. Proposal: don't restrict the length of a value.

Right.

> limitations of Scenario 1.

In looking at this, I have the same question as you. So no
help from me, sorry.

> The proposal is to remove the above text from the RADIUS draft.

Yes, this is correct.

> implement AKA authentication, it will safely ignore this AVP.

Right.

> the Diameter/Radius client to encode different values in different 

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

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 24 Nov 2004 16:22:23 +0200

Hi Jari:

Thanks for your comments. There are two points I want to discuss a bit 
further. See blow:

> your solution lead to some problem if there's roaming

Let me try to describe the problem.

In HTTP there is typically a single Proxy-Aut* header, due to that 
typically there is a single proxy sitting between the client and the server.

In SIP things get a bit more complicated, since it is common that a SIP 
request traverses several proxies, where theoretically each proxy could 
demand credentials. It is also valid that each SIP proxy requests 
credentials for the same or different realms than other SIP proxies.

In other words, a SIP proxy can receive a SIP request that contain 
several Proxy-Authorization header fieldss. Each header field will 
contain the credentials for a particular realm.

So let's assume that one of this proxies receives a request that 
contains several Proxy-Authorization headers. Which one should the SIP 
proxy put into the Radius/Diameter message and send it to the 
Radius/Diameter server?

a) Put blindly everything, I mean, all the Proxy-Authorization headers. 
Repeat attributes (Radius will give us a problem since attributes are 
not grouped).

b) Extract the credentials that are of interested (according to the 
realm) of the SIP server and RADIUS/Diameter server. This requires to 
configure the SIP server with the realm it is serving, but it has some 
benefits: first the Radius/Diameter message contains one set of 
credentials (no poblems with Radius); second, it allows the 
Radius/Diameter server to be authenticating several realms, so there is 
no uncertainity because there is only one set of credentials in the message.

Therefore, we proposed to clarify all this issue and describe the need 
to configure the SIP server with the realm it is serving. This allows 
the server to select the appropriate credentials.

>> 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:
>>
>> b) Each token is an attribute, thus, there might be multiple 
>> Digest-Qop attributes in a particular Radius/Diameter message.
>>

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Nov 2004 20:58:21 +0200

> proxy put into the Radius/Diameter message and send it to the 

Thanks for the explanation. The situation is clearer to me
now.

> Repeat attributes (Radius will give us a problem since attributes are 

I see the problem.

> the server to select the appropriate credentials.

This sounds reasonable, and my original worry turned out
to be a non-issue. (I worried that this might somehow
limit what the user's realm might be. But the client's
header includes both the username, which might of the
form jari@domain, and the challenging proxy's realm.
Only the latter is used in matching what gets sent to
the AAA server. In conclusion I could be jari@domain1
when traversing through three proxies that challenge
me using realms domain2, domain3, and domain4, and
a single AAA server could handle all of this.)

--Jari

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 25 Nov 2004 15:33:16 +0200

> a single AAA server could handle all of this.)

Exactly, that is the scenario that we want to enable.

- Miguel