Re: : Reconciling Radius/Diameter SIP application

Hi Jari:

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

Jari Arkko wrote:
> Miguel Garcia wrote:
> 

>> 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.
> 
> 
> 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?

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.



> 
>> 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.
> 
> 
> 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...
> 

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


> --Jari

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