Subject: [Simple] Identity in Presence Authorization

From: Miguel Garcia <[email-masked]>
Date: Wed, 05 May 2004 16:05:37 +0300

Jonathan:

I have a point on disagreement on the treatment of Identity (Section 
3.1.1) in the presence authorization document.

That section maps the Identity in the geopriv common policy with the 
identities available in SIP. When the SIP request is authenticated with 
HTTP Digest, the username and realm values are relevant.

The realm value is not a domain name. Actually, RFC 2617 recommends to 
include the hostname as part of the realm. And even gives examples of 
realms that contains, let's say, username parts, e.g., 
"[email-masked]".

If we follow the procedures that you describe in the presence 
Authorization draft "the domain part of the URI is matched against the 
realm attribute in the Authorization request header field". If the URI 
in the common policy contains something like <uri>[email-masked]</uri>, 
the username in the Authorization is "joe", and the realm is 
"[email-masked]", the PS will compare 
"joe@[email-masked]" with "[email-masked]", failing to 
match.

I guess that one solution is to make the identity condition in a very 
weird way, e.g. <uri>joe@[email-masked]</uri>. But I 
believe this is not the path that we should be following.

The evident solution is to remove any possible username part from the 
realm attribute, before doing the comparison. But this makes the 
condition look like <uri>[email-masked]</uri>. Obviously this 
requires to insert a <uri> per realm (read, hostname) defined in the domain.

A similar issue: the username in HTTP Digest could potentially contain a 
domain name by itself, e.g., username="[email-masked]". See for 
instance RFC 3310 Section 4.

I guess what I am missing is a clearly defined algorithm that avoids 
these sort of conflicts between username and realm in Digest, before 
doing the comparison with the <uri> rule.

- Miguel

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

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 May 2004 00:26:35 -0400

Thanks for the comments, Miguel.

I think there is an easier solution than trying to define any meaning or 
rules on realm usage. Rather, in real systems, there are actual users 
provisioned into it that are identified by a SIP URI that is their 
proper AOR. There will also be a username and password associated with 
those users. What I think we should say is that, when digest is used, 
the identity is the AOR associated with the username and password 
provided in the digest authentication.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 May 2004 00:26:35 -0400

Thanks,
Jonathan R.

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 10 May 2004 08:09:53 +0300

Hi Jonathan:

It sounds excellent.

- Miguel

ext Jonathan Rosenberg wrote:

>> identities available in SIP. When the SIP request is authenticated 
>> with HTTP Digest, the username and realm values are relevant.
>>
>> A similar issue: the username in HTTP Digest could potentially contain 
>> a domain name by itself, e.g., username="[email-masked]". See 
>> for instance RFC 3310 Section 4.
>>

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 10 May 2004 08:09:53 +0300

Hi Jonathan:

It sounds excellent.

- Miguel