Subject: [Sipping] Can a proxy authenticate on behalf of UAC?

From: "Szilagyi, Mike" <[email-masked]>
Date: Wed, 5 Dec 2007 16:48:50 -0500

Is it possible for a proxy to authenticate on behalf of a call initiated
by a UAC.  For example, many SIP phones sit behind a SIP proxy at a
site.  The site uses a SIP/VoIP carrier for local/long-distance calls.
It's desirable that all outbound SIP calls initiated by the phones would
be authenticated with the SIP carrier by the proxy server.   The proxy
would provide the carrier with credentials using SIP and digest
authentication.

Phone        Proxy            Carrier

INVITE ------>

             INVITE ----------->

             <--------- 407 Auth

             ACK -------------->

             INVITE (w/cred)--->

             <----------- 200 OK

<------ 200 OK

ACK --------->  

              ACK ------------->     

If so, are these call flows outlined in any documents?

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Adam Roach <[email-masked]>
Date: Wed, 05 Dec 2007 14:01:52 -0800

Simply put: no. Proxies cannot do this. (Consider the CSeqs for the 
various messages in the call flow you outline, and one of the key 
problems should become obvious).

To solve the class of problem you describe, I would suggest the use of 
mutually-authenticated TLS. You could also use a B2BUA, but doing so 
would cripple your ability to deploy new services in the future.

/a

On 12/5/07 1:48 PM, Szilagyi, Mike wrote:
>
> Is it possible for a proxy to authenticate on behalf of a call 
> initiated by a UAC. For example, many SIP phones sit behind a SIP 
> proxy at a site. The site uses a SIP/VoIP carrier for 
> local/long-distance calls. It’s desirable that all outbound SIP calls 
> initiated by the phones would be authenticated with the SIP carrier by 
> the proxy server. The proxy would provide the carrier with credentials 
> using SIP and digest authentication.
>
> Phone Proxy Carrier
>
> INVITE ------>
>
> INVITE ----------->
>
> <--------- 407 Auth
>
> ACK -------------->
>
> INVITE (w/cred)--->
>
> <----------- 200 OK
>
> <------ 200 OK
>
> ACK --------->
>
> ACK ------------->
>
> ------------------------------------------------------------------------
>

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 6 Dec 2007 11:19:56 -0500

Adam is correct about the cseq issue.  One of the options mentioned
during the rfc2543bis effort was to allow for smart proxies to "fork" to
the same location upon a failure response and not trigger a 482.

I don't recall if the suggestion was rejected because of backward
compatibility or complexity reasons.

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: Wednesday, December 05, 2007 5:02 PM
> To: Szilagyi, Mike
> Cc: [email-masked]
> Subject: Re: [Sipping] Can a proxy authenticate on behalf of UAC?
> 
> Simply put: no. Proxies cannot do this. (Consider the CSeqs 
> for the various messages in the call flow you outline, and 
> one of the key problems should become obvious).
> 
> To solve the class of problem you describe, I would suggest 
> the use of mutually-authenticated TLS. You could also use a 
> B2BUA, but doing so would cripple your ability to deploy new 
> services in the future.
> 
> /a
> 
> > local/long-distance calls. It's desirable that all outbound 
> SIP calls

---

From: [email-masked]
Date: Thu, 6 Dec 2007 14:56:55 -0500

From: "Szilagyi, Mike" <[email-masked]>

   Phone        Proxy            Carrier

   INVITE ------>

		INVITE ----------->

		<--------- 407 Auth

		ACK -------------->

		INVITE (w/cred)--->

		<----------- 200 OK

   <------ 200 OK

   ACK ---------> 

		 ACK ------------->    

I'd say "maybe".  The second INVITE from the Proxy to the Carrier
would have to have the same CSeq, and thus be treated as a second
branch of a fork.  You would have to ensure that Carrier didn't treat
that as a "merged request" and give a 482 response rather than
processing it.

But once you got around that problem, the Phone would not know of the
authentication credentials, and would not apply them to the next
request in the dialog.  I suppose you could have the Proxy remember
them and apply them to all later requests in the dialog.

Dale