Subject: RE: [Sip] Open Issue #131: Meaning of challenge when UAC is a gat eway

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 6 Dec 2001 11:05:28 -0600

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 R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (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
> 

_______________________________________________
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: Thu, 06 Dec 2001 13:59:55 -0500

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.

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