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

From: Robert Sparks <[email-masked]>
Date: Thu, 31 May 2001 10:48:22 -0400

> -----Original Message-----
> From: Christian Jansson [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 10:05 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [SIP] Problems with multi-proxy authentication
> 
> 
> Some questions on the multi-proxy authentication scenario from
> draft-ietf-sip-call-flows-03.txt:
> 
> How should the UAC figure out that the second 407 is from 
> another server
> than the first 407 came from, and not that the credentials 
> sent to Proxy1
> were wrong? In both cases the UAC sends the INVITE with the same
> Request-URI I assume, and because the realm could be any text string,
> both servers could have realm="SIP-Proxy". So what is the significant
> difference that makes the UAC add two Proxy-Authorization headers
> to the INVITE.

Proxies in different Realms (administrative domains) need
to be sure they provide unique realm strings. This is the
key the _end user_ needs to differentiate the source of
challenges.

> 
> 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 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?
> 
> Christian Jansson
> Hotsip
> www.hotsip.com
> 
> > The call-flows draft shows a multi-proxy authentication 
> scenario where a
> > client sends two Proxy-Authorization headers in a request 
> message. The
> > Proxy-Authorization header grammar doesn't provide for multiple
> > Proxy-Authorization header instances in a message. Perhaps 
> this grammar
> > needs to be defined differently for SIP instead of 
> referring to the syntax
> > in the HTTP draft.
> >
> > The other issue is regarding proxies optionally consuming 
> or relaying the
> > credentials in a message. Wouldn't this add to the 
> complexity of proxy
> > implementations for figuring out when to consume and when 
> to leave it
> alone
> > ? Wouldn't it be simpler if proxies never consumed the 
> proxy-authorization
> > header and proxies expecting credentials tried out the 
> entire list of
> > Proxy-Authorization headers for a match ? Also the draft 
> currently does
> not
> > seem to specify if proxies should only check the topmost
> > Proxy-Authorization header if they are expecting a response to a
> challenge.
> >
> > -Binu
> 
> 
> 
> _______________________________________________
> 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.
> 

_______________________________________________
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: Christian Jansson <[email-masked]>
Date: Thu, 31 May 2001 20:23:56 +0100

> Where do you get the idea that WWW-Authenticate is based on a To:

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

But the main question is still that an UAC that re-sends a request
after receiving a 407 can get a 401 back, which MUST have a
WWW-Authenticate header. I thougth this 401/WWW-Authenticate response
would mean the UAC was beeing queried for authentication by an UAS
(not Proxy) and that the next request should have a Authorization
header added to it. But all I wanted from the beginning was to get
through a proxy...

19.1, 3:rd sentence also seems to indicate that a proxy server isn't
allowed to send 401s:
"The 401 response is used by user agent servers in SIP to challenge
the authorization of a user agent client. Additionally, registrars and
redirect servers MAY make use of 401 responses for authorization, but
proxies MUST NOT, and instead MAY use the 407 response."

Shouldn´t the proxy just send another 407 with Proxy-Authenticate if
the credentials were wrong? Then the UAC would know that it is a
Proxy-Authorization header it should provide in the next request.

Christian Jansson
Hotsip
www.hotsip.com

> > bit strange as it talks a lot about the UAC "contacting a
> > specific proxy  server". Since when
> > proxy server and not a UAS, or a redirect server?
> > 
> > Christian Jansson
> > Hotsip
> > www.hotsip.com