Subject: RE: [Sip] 407s from different proxies on a SIP session

From: [email-masked]
Date: Wed, 17 Oct 2001 10:57:54 +0300

Hi,

Comment inline.

> > In the following scenario with multiple proxies, each of the 
> > proxies can challenge the request from the client and the 
> > client will probably have to respond to the challenges from 
> > different proxies using different Proxy-Authorization headers 
> > in the same request. How do the proxies differentiate between 
> > the different Proxy-Authorization headers and use the right 
> > header that was meant for the proxy. I was wondering if there 
> > was a standard way to do this.
> > 
> > C1 ---------> P1 ------------> P2 ---------------> C2
> > 
> 
> The realm can be used if the proxy is 
> certain that it is unique to the proxy.
> Otherwise, the nonce can be generated/parsed 
> in a way that uniquely identifies the 
> appropriate proxy.

The realm only works for Digest authentication. I suppose at least in Basic
authentication, the proxy could just pick the topmost Proxy-Authorization
and process that.

Cheers,
Aki

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Thu, 18 Oct 2001 14:04:09 -0400

> authentication, the proxy could just pick the topmost 

Topmost isn't good enough. You'll have to look at all of them
and see if one matches you.

You could generate a false positive in this case and there's
nothing in Basic that's going to get you past that.

You can avoid the problem quite cleanly by never issuing
a Basic challenge (do you _really_ want to share your
secret with everyone in-between you and the endpoint?).

RjS

---

From: "Ajay Chitturi" <[email-masked]>
Date: Thu, 18 Oct 2001 12:51:41 -0700

Using the realm / nonce to identify the auth header could be hacky.. The challenging proxies could use the same realm and I'm not sure if the nonces generated by different machines can be required to be unique.

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 11:04 AM
To: [email-masked]'; [email-masked]; Ajay Chitturi
Cc: [email-masked]
Subject: RE: [Sip] 407s from different proxies on a SIP session

RjS

---

From: [email-masked]
Date: Fri, 19 Oct 2001 10:24:07 +0300

Hi,

> and see if one matches you.

I agree, but I seem to remember a thread on this on one of the lists some
time ago, and using the topmost header seems to be the way at least some
people are doing it.

> secret with everyone in-between you and the endpoint?).

No no! I'm not suggesting Basic should ever be used. 

But maybe there is a need to clarify this issue in the bis security section
rather than rely on servers issuing unique nonces and realms? Also going
through all of the credentials seems a bit too much work for a lazy proxy
;-)

Cheers,
Aki

---

From: Robert Sparks <[email-masked]>
Date: Fri, 19 Oct 2001 09:38:02 -0400

When a forking proxy returns a 407, it has to combine
the challenges from _all_ of the 407's it received for
the request into that one response. This allows the endpoint
to provide credentials for everything in the path of the
next request (instead of just one arbitrary branch). 
Thus, only looking at the topmost header will not work.

RjS

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 19, 2001 2:24 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]

---

From: Robert Sparks <[email-masked]>
Date: Fri, 19 Oct 2001 09:29:40 -0400

Realm is defined in the DIGEST drafts to uniquely
identify a security domain. If more than one proxy
uses the same realm, they better accept the same 
credentials.

A good nonce is going to be globally unique (using
the "extremely low probability of collision" definition
of uniqueness).

RjS

> From: Ajay Chitturi [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 2:52 PM
> To: Robert Sparks; [email-masked]; [email-masked]
> Cc: [email-masked]
> Using the realm / nonce to identify the auth header could be 
> hacky.. The challenging proxies could use the same realm and 
> I'm not sure if the nonces generated by different machines 
> can be required to be unique.
>

---

From: [email-masked]
Date: Fri, 19 Oct 2001 16:58:14 +0300

> uses the same realm, they better accept the same 

Which draft is this? Referring to RFC 2617, the client can determine a
protection space by looking at the realm together with the Request-URI, but
the realm alone is not unique. 

> the "extremely low probability of collision" definition

I agree, if a nonce is carefully picked, there is little chance of
collision. 

Cheers,
Aki

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 21 Oct 2001 17:49:56 -0400

> Sent: Friday, October 19, 2001 9:30 AM
> To: 'Ajay Chitturi'; Robert Sparks; [email-masked];
> [email-masked]
> Cc: [email-masked]

The username and password probably will be the same, but I suspect each
proxy would generally choose separate nonces, so that two digest responses
in two different Proxy-Authorization headers for the same realm would not be
equally usable to both. 

> the "extremely low probability of collision" definition

I really think realm is the right thing, and we should specify one, and only
one way to determine which credentials are "your own" for a proxy. I would
rather mandate that realms be globally unique, probably using something like
"com.dynamicsoft.serviceA" or some other such kind of hierarchy, as needed.

-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

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 22 Oct 2001 01:17:20 +0200

If a stateless proxy is entirely stateless and does not remember challenges,
taking realm would work and taking realm+challenge would not.

  Why should an authentication server keep no challenge? Perhaps to avoid 
  synchronization overhead in a server farm where a re-sent request may
  hit a different server than the original server did. Which is, IMHO,
  doable with the same security level as servers that keep challenges
  longer than for one-way use.

-Jiri

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: "Ajay Chitturi" <[email-masked]>
Date: Sun, 21 Oct 2001 22:16:22 -0700

The consensus seems to be to use realm to identify the domain. Note that an example in the bis draft has realm="business".

If there are two proxies challenging on the same realm, (esp. in the digest example that Jonathan described below) should we use the nonce ? Or should each proxy in the same domain also have a unique realm ?

Thanks
Ajay.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Sunday, October 21, 2001 2:50 PM
To: Robert Sparks; Ajay Chitturi; [email-masked];
[email-masked]
Cc: [email-masked]

-Jonathan R.

---

---

From: [email-masked]
Date: Mon, 22 Oct 2001 09:55:32 +0300

> If there are two proxies challenging on the same realm, (esp. 
> in the digest example that Jonathan described below) should 
> we use the nonce ? Or should each proxy in the same domain 
> also have a unique realm ?

Currently the realm is used for displaying to the user some information. It
may have additional semantics, this is allowed in RFC 2617, but AFAIK
doesn't have it now. It is totally up to the server to define its own
namespace for the realm, because to the client, the Request-URI creates the
uniqueness of each challenge/realm. 

E.g. realm="business" needs different credentials for domain.com and
foobar.com. The server can't know which is which unless realm is specified
to be something in the form of realm="[email-masked]".

Nonce won't help, since it can always be considered stale on proxies that
don't store all sent challenges, but rather encode the state in the nonce.

Cheers,
Aki