Subject: RE: [SIP] Problems with multi-proxy authentication

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 3 Jun 2001 02:08:16 -0400

> -----Original Message-----
> From: Robert Sparks 
> Sent: Friday, June 01, 2001 1:36 PM
> To: Jonathan Rosenberg; 'Christian Jansson'
> Cc: [email-masked]'; [email-masked]'
> Subject: RE: [SIP] Problems with multi-proxy authentication
> 
> I really disagree that the To: field should be involved in
> the key to the cache at all. It should _only_ be the realm.
> Consider the case where the UAS is a conference server on
> which I have an account and a set of credentials that go with
> that account. If I call in to use the conference server on
> sip:[email-masked] it 401s me (realm="Big Bucket
> Conference Services") and I provide credentials to my device,
> which caches them for future queries. I make the next call to 
> sip:[email-masked], it 401s me (realm="Big Bucket
> Conference Services"). With the above, the UAC is going to
> prompt me again! Have you discovered a problem with just
> using the realm as the key?

Ah, now I see the confusion.

There are two interpretations of caching:

1. Before sending a new request, a user checks to see if it has any
credentials that might apply for that request, and inserts them right away.
This avoids extra round-trips for challenges.

2. Send a new request, and then get a 407 or 401. Check to see if you have
any credentials that apply to the challenges in the response, and use those
instead of re-querying the user. Resend the request immediately with those
cached credentials.

I was talking about case 1, in which case the UAC doesn't know what the
realm is before sending a request. Assuming you are talking about case 2,
using the realm is indeed the right thing. I think Christian is also
thinking about case 1.

That said, Mike Thomas make some good points about cached credentials.
Should those credentials contain any kind of signature information, they
will effectively not be cacheable at all.

Christian writes:
> 
> 10.48 in bis-03 also mentions the Request-URI three lines 
> above the line
> talking about the To header. This can be a bit confusing.

Hmm. I'm honestly not even sure what those lines mean. "parameters
applicable to the request-URI" is kind of vague. Henning?

> > Yes, I agree this is confusing. We need a concise 
> definition of how to
> cache
> > credentials, if we want to provide support for that. I'm 
> not really sure
> how
> > to do it, since its hard to say whether a specific request 
> will reach a
> > specific proxy. The most important case, local outbound 
> proxies, is easy,
> > since the UAC knows that every request goes to that. I'm 
> not sure any
> other
> > proxy credential caching will be that useful. Maybe we 
> should limit the
> > discussion to just that case?
> 
> Yes the UAC knows that every request goes to the outbound 
> proxy, but if
> the UAC gets a 407, how can it detect that it is from the 
> local outbound
> proxy
> and not from some other proxy in the chain?

Right, I agree. This is what I'm saying about it being hard to know whether
a specific request will reach a specific proxy.

> 
> I think local outbound proxy is the special case as every request,
> independent
> of request-uri, will pass through it and could be challenged for proxy
> authentication.
> This could really mess up the credential cache with one entry 
> per every
> request-uri,
> even though we know that we probably could have used already cached
> credentials.

Right, so what I am saying is that we might want to only consider this case,
in which case the spec says to attach credentials for the configured local
outbound domain in every request, or something like that.

> 
> Could we make use of the "domain" parameter as defined in 3.2.1
> RFC2617HttpAuth
> and instead cache credentials according to the domain provided in the
> challenge? Then
> if the address of the local outbound proxy matched one of the 
> domains in the
> cache we
> could add the correct Proxy-Authorization header to every 
> request without
> having
> the request-407 roundtrip. This would prevent the credentials 
> cache from
> having
> an entry for each request-uri.

The problem is that the address of the local outbound proxy is likely to be
configured as an IP address in the UA, and the domain is not likely to be an
IP address in the challenge.

In any case, it just occurs to me that caching credentials for requests with
differing request URIs and methods is fruitless anyway. For digest, the hash
covers the request URI (albeit indirectly) and method. WIth rfc2617, it can
even cover the body, which will be different in each request. So, this whole
bit about caching credentials is not likely to ever be useful for local
outbound proxies, or ever, in fact.

-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

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.