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