Subject: Re: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-sip-app-02

From: Miguel Garcia <[email-masked]>
Date: Mon, 03 May 2004 11:02:15 +0300

Hi Wolfgang:

Thanks for your review. See answers below:

ext Beck01, Wolfgang wrote:

> Hello,
> 
> p 12, section 5.3
> 
> step 12: "SIP server 2 will validate the credentials.."
> How can the SIP server do this? It has asked for authentication
> parameters in steps 5 and 6, but it doesn't have the user's password.

I think you have a point here, but let me investigate a bit more. I will 
reply in a separate e-mail laster.

> 
> p 32, section 7.7
> "The SIP-Method AVP MUST include the SIP method name of the SIP
> request that triggered this Diameter MAR message.
> 
> The Diameter MAR message MUST include a SIP-AOR AVP. The SIP-AOR AVP
> indicates the intended Address-of-Record of the SIP request. "
> 
> Why are SIP-Method and SIP-AOR mandatory? I would have expected a
> mandatory Contact: or From: URI, or some other information about
> the user requesting authentication.

Let me first start saying that these AVPs are here in support for the 
scenario decribed in Section 5.4, where a SIP Server (Diameter Client) 
is requesting authentication/authorization from the SIP Client.

The idea is: a user may be authorized to send certain SIP requests 
(e.g., INVITE) but not others (SUBSCRIBE) to a certain server (i.e., the 
SIP-AOR). Since the Diameter server is authorizing those SIP 
transactions, the Diameter server must get the SIP method and 
Address-of-Record included in the SIP message.

The Contact header merely indicates a hostname or IP address where the 
user is logged in, but typically this is a dynamic address (e.g., 
allocated by DHCP). So it does not have any value for the purpose of 
authentication/authorization.

The From header in SIP is even worse. Like in e-mail, From is an 
end-to-end header in SIP, meaning that the SIP client can insert any 
value. Actually, the SIP RFC recommends to insert a From header set to 
miningless URI (e.g., sip:[email-masked]) when the user 
request privacy. So we can't use the From header for authentication 
purposes, since it does not contain any meaningful information.

The action that we are looing for is to authenticate the user. 
Authentication of the user can be achieved by the HTTP Digest algorithm, 
but not by the From or Contact headers.

> 
> p 48, typo 'Digest-Relam'

Good. We will fix it.
> Regards,
> Wolfgang

Thanks a lot for your review.

- Miguel

> --
> Wolfgang Beck
> T-Systems
> Internet Netzplattformen
> Am Kavalleriesand 3
> 64295 Darmstadt 

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

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 03 May 2004 15:54:12 +0300

Wolfang:

After doing some research, here is the answer to your first concern. 
Sorry for the long e-mail, but the subject deserves our attention.

> parameters in steps 5 and 6, but it doesn't have the user's password.

Let's start from the beginning. The Diameter SIP application offers 
supports for two scenarios: one where the Diameter server authenticates 
and authorizes the user, the other where the Diameter server delegates 
the authentication and authorization to the SIP server.

The former is supported in Section 5.2, the latter in Section 5.3. Your 
concern is about Section 5.3.

You are right that the SIP server does not have the password at this 
stage, therefore, it cannot validate the credentials. Having said that, 
a possible solution consist of adding a new Digest-Password AVP to the 
SIP-Authenticate grouped AVP. THIS IS AWFUL because it breaks any 
security model. We don't want to send passwords over the wire. So I 
don't pursue this idea anymore.

One can thing of the Diameter server sending what RFC 2617 calls H(A1), 
which is a digest of the username/realm/password that does not change 
with time. This solution is also fragile, since once guessed, anyone can 
use it to build digest-requests even without really knowing the password.

A feasible solution is: the Diameter server, when creating the 
authentication challenge (SIP-Authenticate grouped AVP), calculates the 
expected response from the SIP client, and adds it into a new 
Digest-Expected-Response AVP.

This solution is nice, since it does not break any security. However, 
its applicability is very limited, since it will only work in the case 
there is not client information in the computation of the 
digest-request. For instance, if the client uses qop="auth" or 
qop="auth-int", then the computation fo the request-digest is based on, 
among others, the chosen value of qop, the cnonce, perhaps the body... 
So in this case there is no way the Diameter server can pre-calculate an 
expected response. Consequently, the only possibility is to fall back to 
authentication in the Diameter server, which is the scenario supported 
in Section 5.2 of the Diameter SIP application.

However, if there is not qop parameter used, then the Diameter server 
can pre-calculate an expected response, since it is not dependent on any 
client information, and send it to the SIP server. The SIP server 
challenges the SIP client, receives the credentials (request-digest), 
compares the response with the expected response, and authorizes the SIP 
  request.

Is this ok? Any other comments?

If not, I propose to modify the Diameter SIP application as follows:

a) we add a new Digest-Expected-Response AVP to the SIP-Authenticate 
grouped AVP. This will convey the expected response calculated at the 
Diameter server to the SIP server.

b) we indicate somewhere in the draft that if the qop parameter is not 
used (in the Authorization or Proxy-Authorization headers), the SIP 
proxy can verify the request by itself by comparing the response and the 
expected response. Otherwise, the SIP server has to fall back to the 
scenario supported in Section 5.2 (Diameter server authenticates the 
client).

How does that sound?

BR,

     Miguel