Subject: Re: [Sip] Open Issue #134: Meaning of challenge when UAC is a gateway

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Dec 2001 16:29:02 -0500

My sense of consensus at IETF 52 was the following:

1. the device/user distinction is not useful
2. if the ua element has cached credentials for a realm it receives in a 
challenge (where caching may be through configuration), it applies those 
credentials in the re-invite, and that there is no need to prompt the 
user for credentials for that realm.
3. as a corollary to (2), if a provider wishes to challenge its gw's or 
phones, it needs to configure them with credentials for a realm, and 
then challenge requests against that realm, and also not use that realm 
for user challenges.
4. we need to add some text on proper construction of realms, as per 
Jon's note on the subject. I think its a separate issue.

-Jonathan R.

(ps - I goofed and this is issue #134, so I renamed the subject)

Henning G. Schulzrinne wrote:

> I think we should just treat the phone user as being at the end of
> rather long extension cord from the gateway. Thus, they are one and the
> same. It's up to the gateway to respect the wishes of the user, but I
> don't think we should get into prescribing UI behavior that is very
> specific to one technology.
> 
> On the realm name:
> 
> I agree with Jon that something close to a basic SIP URL (user@domain)
> would likely work best and be in keeping with 2617. It may also work
> reasonably well for challenges from intermediate proxy servers.
> 
> 
> "Peterson, Jon" wrote:
> 
>>I think that in order to evaluate this proposal we need to flush out how
>>'realm' is used in SIP. Even in rfc2617, the way that the realm string is
>>created for Basic as opposed to Digest auth is significantly different;
>>Basic realms are just arbitrary strings (like "business"), whereas Digest
>>recommends realms that contain a hostname and possibly the name of a user or
>>group. The interpretation of realms in SIP is further complicated by the
>>lack of some context (the canonical root URL) that is available in the HTTP
>>world; the value of providing context for the realm through Request-URI of
>>the SIP message instigating a challenge is unclear to me - especially since
>>that Request-URI might not be set by or even known to the challengee. I
>>think we need a story in rfc2543bis about how realm strings are constructed
>>in SIP, and what they're supposed to signify.
>>
>>I suspect that the realm-string for SIP should just explicitly designate
>>something like the administrative domain of the challenger (i.e.
>>"carrier.net") or the specific host that is issuing the challenge. Realms
>>should be globally unique (amongst domains, not necessarily hosts), and it
>>would probably be useful if they allowed hierarchical structures. Users,
>>when presented with a challenge dialog box by an application, would
>>understand how to navigate a challenge for a particular host or domain; this
>>could also potentially be meaningful to automatons.  I also believe this is
>>pretty close to the recommendations given for Digest auth realms in 2617.
>>
>>I definitely think the proposal below is on the right track - provided the
>>semantics of the realm string don't introduce any complications. One
>>possible snag would be the case in which both a gateway and its user possess
>>credentials that have varying levels of authorization within the same realm.
>>If a gateway automatically intercepts challenges for such a realm, then the
>>user may have no way to present their superior credentials. Perhaps we could
>>recommend some implementation behavior that would get around this. The text
>>in bis05 currently specifies that we always display the realm to the user
>>and prompt them for a username and password (if we haven't already cached
>>credentials from a previous exchange). Maybe as a general rule for SIP
>>devices, we could say that if the user is prompted for credentials for a
>>specific realm and they decline to provide them (presumably because they
>>cannot), that the device may supply any credentials of its own for that
>>realm. "If you have a password for this service, press * now."
>>
>>Jon Peterson
>>NeuStar, Inc.
>>
>>
>>>-----Original Message-----
>>>From: Jonathan Rosenberg [mailto:[email-masked]]
>>>Sent: Wednesday, December 05, 2001 7:01 PM
>>>To: [email-masked]'
>>>Subject: [Sip] Open Issue #131: Meaning of challenge when UAC is a
>>>gateway
>>>
>>>
>>>Issue:
>>>
>>>When a UAS or proxy challenges a UAC that is a PSTN gateway, is the
>>>challenge for the gateway, or the user calling through the
>>>gateway? In the
>>>latter case, for example, the gateway might prompt the user,
>>>with voice
>>>prompts, to enter a password or something.
>>>
>>>Discussion points:
>>>
>>>A similar issue can arise for a standalone sip phone; is the
>>>challenge for
>>>the device or the user on the device? As a general rule,
>>>realms are the way
>>>to identify for whom the challenge is requested. A device
>>>would need to be
>>>programmed with the realm for which it has credentials as a
>>>device. Should
>>>it receive a challenge for that realm, the device could
>>>supply credentials.
>>>Challenges for other realms would go to the user, since
>>>whether they are for
>>>the device or the user, the device can't answer them anyway,
>>>so may as well
>>>try the user.
>>>
>>>Proposal:
>>>
>>>Add wording that talks about this realms usage.
>>>
>>>
> 

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 19 Dec 2001 16:46:10 -0500

> 1. the device/user distinction is not useful

Agreed.

> user for credentials for that realm.

Ack - same as for any other device. That's a local policy and
implementation decision. If you want to build a user annoyance
maximization device, you can certainly prompt again and again.

> Jon's note on the subject. I think its a separate issue.

My interpretation is that this a useful convention, but things should
work even if I put random characters in the realm string.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Dec 2001 23:35:30 -0500

Henning G. Schulzrinne wrote:

>>2. if the ua element has cached credentials for a realm it receives in
>>a challenge (where caching may be through configuration), it applies
>>those credentials in the re-invite, and that there is no need to prompt the

Sure. However, this is something people have gotten wrong, and is easy 
to do wrong. The specification needs to help provide some guidance here.

-Jonathan R.