Subject: AW: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-sip-a pp-02

From: "Beck01, Wolfgang" <[email-masked]>
Date: Mon, 3 May 2004 10:23:03 +0200

Miguel,

>> 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.
Of course, this a realistic and useful scenario. But is it really a MUST?
Is this functionality really vital?

> 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.
That was a misunderstanding. I did not want to suggest an authentication
based on the Contact: or From: header. I was thinking of user-specific
nonces or challenges that might be required by future authentication methods.

Wolfgang

--
Wolfgang Beck
T-Systems
Internet Netzplattformen
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 03 May 2004 13:19:30 +0300

> Is this functionality really vital?

<miguel>
Yes, I think it is a MUST. All SIP requests contain a method name 
(INVITE, REGISTER, etc.) and a Request-URI (the intended destination). 
So there is no problem in the Diameter client inserting this 
information. Now it is a matter of the Diameter server using that 
information for authorization or not. Some Diameter servers will be 
configured to use this information, others will simply provide 
authorization based on "the user has to be a customer of our network".

In short: the Diameter client always send them, the Diameter server 
decides whether use them or not.
</miguel>

> nonces or challenges that might be required by future authentication methods.

<miguel>
I wouldn't dare to think too much in "future authentication methods", 
when we don't even provide support for all the *current authentication 
methods". Bear in mind that we are providing support for HTTP Digest 
authentication applied to SIP. We don't provide support for other 
authentication mechanisms (e.g., TLS, S/MIME, etc.). We have a 
two-folded reason:
a) SIP only mandates HTTP Digest authentication. Other methods are optional
b) We found very clear requirements to support HTTP Digest 
authentication, we didn't find any interest (nore requirements) in 
supporting other current authentication mechanisms.

Consequently, I wouldn't dare to start thinking of furutre 
authentication mechanisms when we don't even have full support for 
current mechanisms.

But if you have some clear requirement or scenario in your mind, please 
let us know it.

  - Miguel

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