Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs?

From: "Sanjoy Sen" <[email-masked]>
Date: Mon, 22 Oct 2001 17:16:24 -0500

I was hoping that the UA and the Proxy are in the participatory mode (as
defined in draft-willis-sip-cookies-00.txt) and are able to modify the
cookie to a certain extent (am I correct in assuming this?). The Cookie
header will contain the credential generated (by the Proxy) using the
already existing security state association between the UA and the Proxy &
will be added by the Proxy to all incoming Requests to the  UA (after the
security association has been established). Thoughts?
 
Sanjoy

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Monday, October 22, 2001 4:12 PM
To: Sen, Sanjoy [NGB:B602:EXCH]; sip-security
Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs?

That might work, but it would take some thinking. One of the issues is that
the credential set needs to include something like a a serial number or a
hash of the message it is in, or it is subject to replay attacks. The cookie
draft is mostly intended to force "replays" of certain information, so this
could be problematic for use in credential transfer.
 
I suppose one could have something like an "adaptive cookie" that is
modified by the UA, but this is sort of antithetical to the original cookie
concept.
 
--
Dean

----- Original Message ----- 
From: Sanjoy Sen <mailto:[email-masked]>  
To: [email-masked]' <mailto:[email-masked]'>  ;
[email-masked]' <mailto:[email-masked]'>  
Sent: Monday, October 22, 2001 4:05 PM
Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs?

Dean, 

   I like the option of using extended Remote-party-id header for
transfering the credential. How about the option of using the Cookie header
for the same purpose? 

Sanjoy 

====================== 

To: "Jari Arkko" < [email-masked]
<mailto:[email-masked]> > 
Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? 
From: "Dean Willis" < [email-masked]
<mailto:[email-masked]> > 
Date: Fri, 19 Oct 2001 11:10:07 -0500 
Cc: "Pekka Pessi" <[email-masked]>, "James Undery"
<[email-masked]>, <[email-masked]> 
List-Id: Security Issues for the SIP protocol <sip-security.ietf.org> 
References: <[email-masked]>
<[email-masked]>
<005701c158b0$71c24510$7d7075d5@flak> <[email-masked]> 

Sender: [email-masked] 

----------------------------------------------------------------------------
---- 

Ah, Perhaps I was being dense. I've just reread the entire thread. 

Perhaps further analysis of the requirement would help. 

Do we wish to authenticate the identity of the system that is acting as a 
UAS, or authenticate the identity of the human operating that system? What 
is the persistency of the relationship between the proxy and the UAS? Will 
the UAS need to know how to authenticate to many proxies? What level of 
security is required? Do we need to protect against playback, or does the 
call signature (to:, From:, Call-ID) provide sufficient uniqueness on its 
own? 

Several possible candidates might include 

TLS (already discussed, just issue a client cert signed by a CAS trusted by 
the proxy) 
IPSEC (key management base problem for IKE) 
HIP 
SSH 
Kerberos (it has to be said) 
Use of remote-party-ID extended with some sort of cryptographic signature of

the response 
-- shared secret key 
-- PGP 
-- PKI cert 
--  kerberos key exchange 

Personally, I'm leaning toward the latter. This would have interesting 
interaction with the goals of the DCS Privacy draft. 

-- 
Dean 

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]> 
To: "Dean Willis" <[email-masked]> 
Cc: "Pekka Pessi" <[email-masked]>; "James Undery" 
<[email-masked]>; <[email-masked]> 
Sent: Friday, October 19, 2001 10:24 AM 
Subject: Re: [Sip-security] Proxy authentication in incoming INVITEs? 

> Dean Willis wrote: 
> 
> > SIP Proxies authenticate clients 
> > making use of those proxies. 
> 
> Yes... and this has to be interpreted very literally. 
> If you have a local proxy and a user agent, you can 
> authenticate half of what the user agent does, namely 
> the user agent client part, but not the user agent 
> server part. 
> 
> > If you want UAs to be able to authenticate every proxy that has 
processed a 
> > message, you'll need to do something like using a PKI to have each proxy

> > sign the message and attach a signed copy of the message to the body of 
the 
> > outgoing message. Checking the authentications requires processing the 
> > signature chain in reverse order. It's pretty seriously tedious, and 
> > consumes vast amounts of signaling bandwidth, not to mention CPU. 
> 
> I don't think anyone is proposing authenticating every proxy. 
> Just the whole user agent to the local proxy. 
> 
> >Of course, one could implement TLS with bidirectional certification. That

> >would essentisally authenticate edge proxies. 
> 
> This would work, if you can pay for it... seems a bit strange 
> that one has to upgrade to PKIs, TCP, public key cryptography, 
> etc. because an otherwise suitable scheme only works in one 
> direction. 
> 
> But I do appreciate the problems outlined in 19.4. Are 
> there any other possible solutions than TLS? 
> 
> Jari 
> 
> _______________________________________________ 
> Sip-security mailing list 
> [email-masked] 
> http://www1.ietf.org/mailman/listinfo/sip-security
<http://www1.ietf.org/mailman/listinfo/sip-security>  

_______________________________________________ 
Sip-security mailing list 
[email-masked] 
http://www1.ietf.org/mailman/listinfo/sip-security
<http://www1.ietf.org/mailman/listinfo/sip-security>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Oct 2001 21:13:39 -0400

> From: Jari Arkko [mailto:[email-masked]]
> Sent: Friday, October 19, 2001 1:44 PM
> To: Dean Willis; Jari Arkko
> Cc: Pekka Pessi; James Undery; [email-masked]
> Yes. Two cases:
> 1) I started this thread in order to discuss something which
> at first look seemed more like a bug than a feature in current
> SIP. HTTP authentication in SIP is propably going to stay,
> so if possible it might make sense to try to make it work like,
> uh, HTTP authentication which does allow what I originally
> assumed SIP would allow. But this is mainly for the purpose
> of keeping the specs symmetric and to give the right impression
> to folks who use SIP. 

No, HTTP does not do what you are asking.

Translating SIP elements to HTTP elements:

UAC -> client
proxy -> proxy
UAS -> origin server

What you want is for the proxy server to authenticate the identity of the
UAS which has generated a response. This translates to having the proxy
authenticate the identity of the origin server. rfc2617 does not provide
that capability, to my knowledge. 

Proxy-Authorization-Info allows a client to authenticate the identity of
proxies, which is not what you want. THe reason it is not mentioned in bis
is that it has a fatal flaw - no realms. As a result, there is no way for a
client to determine which set of credentials is provided by which proxy.
This is an open issue I am currently tracking (issue #164).

Now, that said, I do think its useful to be able to authenticate the
identity of a responder by a proxy, but its not as critical as you might
think. Authenticating the UAC is clearly critical, since they are the ones
actively making a call. But, the UAS is responding to an event initiated by
someone else. Thus, the attacks are different. An attacker could inject
false responses to an INVITE, stopping someone else from getting calls. This
would require eavesdropping of requests in order to see the call-ids, tags,
and so on, and would require them to inject a response before the UAS
answers. Yeah, its possible, but its much harder than other attacks where
the attacker pretends to be a valid UAC. Its also not a fraud attack, but
more of an individual dos attack.

That said, how might we provide this functionality? Well, there are two ways
that are within the realm of the current framework:

1. TLS between the proxy and the UAS
2. some kind of proxy->uas challenge

(1) works within SIP now. You might think there is an issue because most UA
won't have certs, and they are the server side in this transaction, but that
need not be the case. If that same proxy is the one that a client registers
to, the client can use a TLS connection to send its registration, and then
maintain that connection. It performs basic or digest auth over it. Now, the
server knows that the thing on the other end of this connection is a
specific user, and can trust that any requests sent to it, and any responses
from it, are actually from that user. More on this in a separate note.

The other approach (2) is to have the proxies insert a new header into
requests, Proxy-UAS-Authenticate or some other such thing. This contains a
challenge. When the UAS sends a response, the response has an answer to the
challenge, in another header of sorts, like Proxy-UAS-Authorization. The
proxy inspects this, and then passes the response if its valid. If not, it
may need to "resubmit" the request in order to ask for credentials once more
(in the case of a stale nonce, for example). Now, thats the hard part, since
proxies resubmitting requests seems untenable. But, turns out its not.

The reason its not is that "proxies resubmitting requests" is no different
than sequential forking. Just think about it. Granted, the R-URI doesn't
change, but the proxy resubmitting the request would use a different branch
ID on the topmost via. This would appear to the downstream proxy as a merged
request. Now, we have recently agreed on the lists that merged requests are
fine, and since the transaction is identified including the topmost via, the
next hop proxy won't see this as a retransmission at all. When it arrives at
the UAS, the UAS would see it as a separate transaction, but correlated with
the previous request through call leg IDs. It could then generate a
successful response, and that gets forwarded as usual.

Thus, through "legal merged requests" we do have the ability for a proxy to
retry a request after modification. I am not sure how interoperable this
would be; since detecting request merging is hard, it might work through
proxies that didn't try to detect this condition (and my guess is that most
don't), but a UAS would probably be confused. THen again, this is all new
behavior for a UAS, so maybe thats OK.

-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: "Sanjoy Sen" <[email-masked]>
Date: Tue, 23 Oct 2001 16:02:39 -0500

Jonathan,

    A couple of questions/clarifications related to your scheme (2) below:

1. When you talk about using a different branch id with the topmost Via
header, are you just talking about the part used for matching requests with
responses or the entire via-branch parameter? 

2. Given your scheme below which allows "resubmission" of a Request by a
Proxy, is it possible for the Proxy now to add the Proxy-Authorization (or
UAS-Proxy-Authorization?) header to Requests towards the UAS? This can be
used to satisfy the requirement of authenticating Request messages from the
Proxy towards the UAS. I'm assuming that the Proxy and UAS have an already
set-up Security Association which can be used to generate the
message-authentication credential which is inserted by the Proxy in the
Proxy-Authorization(?) header. If message authentication is the sole purpose
(as in this case), is it more clean to define a new header?

Regards,
Sanjoy

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, October 22, 2001 8:14 PM
> To: Jari Arkko; Dean Willis; Jari Arkko
> Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs?
> 
> 
> 
> 
>  
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Oct 2001 23:05:48 -0400

-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]]
Sent: Tuesday, October 23, 2001 5:03 PM
To: 'Jonathan Rosenberg'; Jari Arkko; Dean Willis
Cc: Pekka Pessi; James Undery; [email-masked]
Subject: RE: [Sip-security] Proxy authentication in incoming INVITEs?

>1. When you talk about using a different branch id with the topmost Via
header, are you 
>just talking about the part used for matching requests with responses or
the entire via-
>branch parameter? 

The part for matching requests with responses, which, being part of the
entire branch parameter, means the entire via branch parameter will be
different.

>2. Given your scheme below which allows "resubmission" of a Request by a
Proxy, is it 
>possible for the Proxy now to add the Proxy-Authorization (or
UAS-Proxy-Authorization?) 

Sure. Proxies that do sequential forking can have different requests on each
forked branch.

>header to Requests towards the UAS? This can be used to satisfy the
requirement of 
>authenticating Request messages from the Proxy towards the UAS. I'm
assuming that the 
>Proxy and UAS have an already set-up Security Association which can be used
to generate 
>the message-authentication credential which is inserted by the Proxy in the
Proxy-
>Authorization(?) header. If message authentication is the sole purpose (as
in this case), 
>is it more clean to define a new header?

I don't understand. If you already have a security association between the
ua and proxy (ala tls or ipsec) then what do you need from sip?

-Jonathan R.

---

---

From: "Sanjoy Sen" <[email-masked]>
Date: Wed, 24 Oct 2001 11:24:38 -0500

> Sent: Tuesday, October 23, 2001 10:06 PM
> To: Sen, Sanjoy [NGB:B602:EXCH]; Jonathan Rosenberg; Jari Arkko; Dean
> Willis

Consider the case when an incoming INVITE (through a local Proxy) & the
Proxy itself, need to be authenticated by the UAS. According to section 3.6
of RFC 2617, a Proxy can be authenticated to an origin server using the
Proxy-Authenticate and Proxy-Authorization headers. As you said, for
SIP<->HTTP translation, Proxy<-->Proxy & UAS<-->origin server. The call
sequence is as follows:

1. Proxy-->UAS: INVITE (Proxy-Authorization:...) 
//Proxy adds "Proxy-Authorization", but according to Sec. 19.4 of bis04,
Proxies are NOT allowed to insert Proxy-Authorization header, unless the
request is re-submitted. Hence, as you've proposed, the Proxy can mimick
forking by using a new branch-id & resubmit the INVITE

2. UAS-->Proxy: 407 (Proxy-Authenticate:...)  
//if the credentials do not satisfy the UAS, it sends a new challenge

3. Proxy-->UAS: INVITE (Proxy-Authorization:...) 
// This is also re-submitted as before with new credentials

4. UAS-->Proxy: 200 OK (Proxy-Authentication-Info:...) 
// For mutual authentication. If the Proxy is okay with this, it forwards
the 200 OK. If not, it issues a new challenge to the UAS. Q: In the latter
case, does the Proxy resubmit the INVITE with a Proxy-UAS-Authenticate
header?

For any new request, the Proxy, if required, can pre-emptively insert the
Proxy-Authorization header for message authentication purpose & resubmit the
request. 

5. Proxy-->UAS: (re)INVITE (Proxy-Authorization:...)
...

Is this call flow valid?

Regards,
Sanjoy