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

From: Robert Sparks <[email-masked]>
Date: Fri, 1 Jun 2001 13:36:17 -0400

> -----Original Message-----
> From: Jonathan Rosenberg 
> Sent: Friday, June 01, 2001 2:44 AM
> To: Robert Sparks; 'Christian Jansson'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [SIP] Problems with multi-proxy authentication
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Robert Sparks [mailto:[email-masked]]
> > Sent: Thursday, May 31, 2001 2:29 PM
> > To: 'Christian Jansson'; Robert Sparks; [email-masked]'
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [SIP] Problems with multi-proxy authentication
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Christian Jansson [mailto:[email-masked]]
> > > Sent: Thursday, May 31, 2001 2:24 PM
> > > To: "Robert Sparks"
> > > Cc: [email-masked]; [email-masked]
> > > Subject: RE: [SIP] Problems with multi-proxy authentication
> > > 
> > > 
> > > 
> > > > > Another question is about the description of 
> > > > > Proxy-Authenticate.The last
> > > > > sentence states that: "The server responds with 401 
> > > > > (Unauthorized) if the
> > > > > client guessed wrong". And the description for 
> WWW-Authenticate
> > > > > states
> > > > > that: "the WWW-Authenticate response-header MUST be 
> included in 
> > > > > 401".
> > > > > But the handling of WWW-Authenticate seems to be totally 
> > > > > different as it is
> > > > > based on the To header while Proxy-Authenticate handling is 
> > > > > based on the
> > > > > Request-Uri. So how is a UAC supposed to handle this?
> > > > 
> > > > Where do you get the idea that WWW-Authenticate is 
> based on a To:
> > > > header?
> > > 
> > > I got it from 10.48 WWW-Authenticate (bis-03). The second 
> > part states
> > > that: "A user agent SHOULD cache the authorization 
> credentials for a
> > > given value of the destination (To header) and realm ...".
> > 
> > I'm not sure why that's there. It implies that I (the user) 
> > will have to
> > reenter my proxy credentials every time I call someone new. I 
> > don't think
> > that's what was intended. Jonathan?
> 
> No, it doesn't imply you will re-enter them. Remember, we are 
> talking about UAS authentication of a UAC. It has nothing to 
> do with proxies. So, if you call someone new, odds are that 
> it will require new credentials. In fact, using the request 
> URI here would be wrong, since it might be different between 
> the initial INVITE and the ACK/re-INVITE/BYE because of 
> Contact and Record-Routing. However, the URL portion of the 
> To field doesn't change (I'll update the text to say URL 
> portion, not just the whole To field).

Ok, I was extending this to caching credentials used to
respond to 407's. I'll go look for the text to make sure
_that_ at least doesn't try to use the To:.

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?

> 
> Christian also wrote:
> > Ok, it seems like we both agree on this. But take a look at 10.31 in
> > bis-03, last sentence. I think it trying to say that if I send the
> > wrong credentials to a 407/Proxy-Authentication I will get 
> a 401 back!
> 
> Yikes... that seems wrong to me also, and would explain your 
> confusion. Henning?
> 
> Christian wrote:
> > I also think that the description of Proxy-Authenticate is a 
> > bit strange as
> > it
> > talks a lot about the UAC "contacting a specific proxy 
> > server". Since when
> > did a SIP UAC actually know that it was going to contact a 
> > proxy server
> > and not a UAS, or a redirect server?
> 
> 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?

All you are doing is caching responses to a challenge. If you
get a challenge from the same place, you try reusing what you
have in your cache before you pester your user. For the case 
of multiple challenging proxies in the path, a device that doesn't
cache my credentials will get put in the round file very quickly.

You don't have to know ahead of time whether a specific request
reaches a specific challenging proxy because if it does, it will
challenge you.

Or am I really missing the point?

RjS

_______________________________________________
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.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 1 Jun 2001 13:51:16 -0700 (PDT)

> Or am I really missing the point?

Robert,

I believe that http authentication is indeed
stateless on the server as I think you are
alluding to here, and with Basic authentication it
is probably the least of your worries because
you're just sending a uuencoded plaintext password
each time. For more reasonable authentication
schemes -- especially ones that prove freshness --
this may be problematic. If you're using public
key signatures with anti-replay precautions, it
implies that the UAC would have to resign each
message; indeed, mutual would require all messages
to be signed. This could lead to performance
issues on low CPU performance UA's as well as high
aggregation UA's. The second problem is that the
two of the current popular means of asserting
identity -- symmetric key signatures of kerberos
tickets, and public key signatures over X.509
certs -- generate a large number of bytes on the
wire. For Kerberos, that's typically between
300-500 bytes, and X.509 certs are typically
bigger yet. This could become problematic where
you are trying to keep the message count down for
post dial delay considerations if it routinely
runs over MTU, and could be a problem if the bit
error rate on the access media favors smaller
packets.

In general, I agree that state sux(tm) and that if
we can reasonably avoid storing state on proxies
and UAS's, we should make that a priority. In this
particular situation, however, I'm inclined to
believe that creating shared state on the
proxy/UAS for faster/smaller keyed integrity
checksums may be the right tradeoff, despite not
being especially enamored with the implications.

		 Mike