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

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Oct 2001 17:34:54 +0300

Hi,

I've been looking at the use of HTTP authentication
framework within SIP, and in particular its ability
to authenticate a client to a proxy. Does this
authentication work for incoming as well as outgoing
INVITEs?

In HTTP, proxy authentication allows a local proxy
to ensure that only authenticated clients access the
net through it. A one way client-server relationship
exists in this situation.

In contrast, SIP user agents act as servers when receiving
an INVITE. Does the current bis draft/rfc 2617 allow
authenticating the user agent to the proxy in this case?
If yes, how? If not, why can't authentication be provided
in a symmetric manner in this situation?

Also, why does section 19.4 in the bis draft forbid
proxies to add proxy-authorization? Doesn't this also
prevent the user agent from requesting the proxy to
authenticate itself, because even if the agent gave
a 407, the proxy could not respond to it?

Jari

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

---

From: "James Undery" <[email-masked]>
Date: Wed, 17 Oct 2001 16:34:58 +0100

Hi,

You've come across the problem I've recently noticed. The inclusion
(in bis04) of Authentication-Info allows the server to authenticate
itself to the client, similarly including the
Proxy-Authentication-Info header (rfc2617 hidden in section 3.6) would
allow the reverse.

My only concern about this issue is that the server can't authenticate
itself to the client except in a response to an authenticated request.
This is because you can't be sure of the username until the client
authenticates. While this sounds petty it prevents the sever from
ensuring no step down attack can occur.

HTH

James

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On
> Behalf Of Jari Arkko

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Oct 2001 14:18:40 +0300

> Proxy-Authentication-Info header (rfc2617 hidden in section 3.6) would

You mean "... would allow the proxy to do the same"?

By the way, table 3 in bis-04 does not include the
*-Authentication-info headers. Has someone made a
bug report about this? (And where are by the way the
current outstanding issue lists for the bis?)

> ensuring no step down attack can occur.

Yes, and this is OK.

But I'm uncertain if your explanations above offer any
solution to my original problem, i.e. the fact that we
proxy authentication in SIP seems to work in one
direction only, while the end-to-end authentication
works in both directions?

Jari

---

From: "James Undery" <[email-masked]>
Date: Thu, 18 Oct 2001 12:31:36 +0100

> From: [email-masked] [mailto:[email-masked]]

> You mean "... would allow the proxy to do the same"?

Yes.

> current outstanding issue lists for the bis?)

Yes, I've mentioned that Authentication-Info was missing from section
10, Jonathan noted it so I guess it'll be in bis05. I've not mentioned
Proxy-Authentication-Info before.

> works in both directions?

Proxy-Authentication-Info should be included in responses to any
requests that have been authenticated with Proxy-Authorization (at
that proxy obviously) according to rfc2617. But
Proxy-Authentication-Info has never been discussed on the SIP lists to
my knowledge.

James

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Oct 2001 15:04:08 +0300

> Proxy-Authentication-Info has never been discussed on the SIP lists to

So, do you suggest the following:

UA<---------------------INV---------------------Proxy
UA--------407, P-Authenticate: challenge------->Proxy
UA<-------INV, P-Authorization: response--------Proxy
UA--------200 OK, P-Auth-Info: response-------->Proxy

This scheme looks good, but it has two problems:

1) 19.4 in the bis draft requires passing the 407 upstream
   (which in this case would be somewhere beyond the proxy).
   Hence, the local proxy doesn't doesn't even think of
   answering.

2) 19.4 also forbids proxies to add Proxy-Authorization
   header, which prevents the proxy from answering
   even if knew it would have to.

But perhaps I missed something and this wasn't what
you were proposing?

Jari

---

From: "James Undery" <[email-masked]>
Date: Thu, 18 Oct 2001 13:50:22 +0100

Ah, now I see what you wanted, you want the UAS (callee) to be able to
authenticate proxies, you are right this doesn't work.

Only an Entity with server behaviour can mutually authenticate with
the UAC in the current security model. A server can't authenticate
(using SIP) with other non UAC entities. And the UAC can only add a
Require header so that all servers must authenticate with it.

The only HACK solution I can see is, if the INVITE was record routed,
send a request (OPTIONS, COMET or whatever) back, in this case the
callee gets to be the UAC and insert a suitable Require header.
However, that is a really bad solution.

James

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Oct 2001 16:06:07 +0300

>authenticate proxies, you are right this doesn't work.

This confirms my fear. Does anyone think we should do
something about it?

I can sort of see why we ended up in this based on
the CSeq explanations in 19.4. However, I don't
think the end-result is good. SIP doesn't have
proxy authentication if it can only be done half
of the time! Don't we have to do something about
this in the Bis RFC?

Any suggestions on how to fix this properly?

Jari

---

From: Michael Hammer <[email-masked]>
Date: Thu, 18 Oct 2001 13:51:21 -0400

Jari,

Is there a reason for doing proxy-authenticate half the time versus for
the whole path?  What is the gain in that?  If for some reason
you do not trust the N-proxy, what would stop it from being the N-1-proxy
and go to an N-proxy you do trust?  If you assume the N-proxy will
authenticate the N-1-proxy and follow that thought all the way, you end
up with all proxies needing to authenticate.

Mike

something about it?

this in the Bis RFC?

Jari

[email-masked]

---

From: "Jari Arkko" <[email-masked]>
Date: Thu, 18 Oct 2001 23:54:21 +0300

>Is there a reason for doing proxy-authenticate half the time
>versus for the whole path?  What is the gain in that?  If for
>some reason you do not trust the N-proxy, what would
>stop it from being the N-1-proxy and go to an N-proxy you
>do trust?  If you assume the N-proxy will authenticate the
>N-1-proxy and follow that thought all the way, you end up
>with all proxies needing to authenticate. 

Well, we could discuss proxies authenticating each other
or clients authenticating to everyone on the path, but this
wasn't really why I brought this issue up. (That issue propably
deserves its own thread here.)

The fact of the matter is that SIP *does* allow user
agents to authenticate with the local proxy, but for some
reason seems to implement this *partially*, i.e. only for outgoing
calls and not incoming. I think there's good reasons to have
authentication in local proxies regardless of what happens
after the proxy, but I'd like to have the full functionality. Especially
when all this worked for HTTP, including the situation of having
both a server and client on your machine!

Jari

---

From: Pekka Pessi <[email-masked]>
Date: 18 Oct 2001 18:52:27 +0300

>Any suggestions on how to fix this properly?

	Require the proxy to use different branch value for resubmitted
	request?

					Pekka

---

From: "James Undery" <[email-masked]>
Date: Fri, 19 Oct 2001 09:05:49 +0100

> From: Pekka Pessi [mailto:[email-masked]]

> 	Require the proxy to use different branch value for 

That isn't going to help, it'll just look like a retransmission

James

---

From: Pekka Pessi <[email-masked]>
Date: 19 Oct 2001 12:42:22 +0300

>That isn't going to help, it'll just look like a retransmission

	No, changing the topmost Via is enough.

						Pekka

---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)---
        Isomorphic request or response: Two requests or responses are
             defined to be isomorphic for the purposes of this document
             if they have the same values for the Call-ID, To, From and
             CSeq header fields. In addition, isomorphic requests have
             to have the same Request-URI and the same top-most Via
             header.
---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)---(bis04)---

---

From: "James Undery" <[email-masked]>
Date: Fri, 19 Oct 2001 11:01:50 +0100

> Sent: 19 October 2001 10:42
> To: James Undery
> Cc: Pekka Pessi; Jari Arkko; [email-masked]
> Subject: Re: [Sip-security] Proxy authentication in
> incoming INVITEs?
>
>
> In message
> <[email-masked]> James
> Undery <[email-masked]> writes:

And how pray tell are you going to change the topmost via in all cases

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 19 Oct 2001 10:12:13 -0500

Huh? SIP doesn't authenticate proxies. SIP Proxies authenticate clients
making use of those proxies.

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.

Of course, one could implement TLS with bidirectional certification. That
would essentisally authenticate edge proxies.

--
Dean

---

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Oct 2001 18:24:47 +0300

Dean Willis wrote:

> SIP Proxies authenticate clients

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.

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

>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

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 19 Oct 2001 11:10:07 -0500

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?

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 19 Oct 2001 20:43:58 +0300

> Perhaps further analysis of the requirement would help.

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. I don't have major requirements in this
case, though it is possible that if this problem was fixed then
HTTP authentication in SIP would be applicable in some cases
that it currently isn't.

2) Since we jumped into the discussion of the security architecture
and its requirements, we might as well start the discussions based
on the one published set of requirements: Miguel Garcia's draft
on 3g requirements to SIP [1]. This includes security in chapters
6.22-6.24. Here, I care much more than in point 1!

> UAS, or authenticate the identity of the human operating that system? What

Usually the human. (I'm not sure though it makes much of a difference
protocol wise, username/passwords for instance could be given to
the device or prompted from the user. More fine-grained systems
such as smart cards allow users to 'open' the security with a PIN
for a period, from there on the device can act from the behalf of the
user.)

> is the persistency of the relationship between the proxy and the UAS? Will

For 3g, authentication is towards the home environment, and there's
a contractual business relationship between the UA owner and the
home environment. (There are proxies in between.)

> the UAS need to know how to authenticate to many proxies?

Yes, at least in the sense of load-sharing and fault-tolerance, though not
necessarily in terms of authenticating to a bunch of unknown proxies
somewhere else.

> What level of

Authentication as such is useful, but not sufficient. It will also be necessary
to protect the actual messages somehow (which is another drawback of
HTTP authentication, though there's some work in progress fixing this).
I think integrity protection is a MUST, while confidentiality may be a SHOULD
or a MAY.

I believe replay protection is necessary. If service providers want to
bill for their service, it would be bad for users if anyone could replay
their sessions/calls. I suspect call signature might be useful here, but
the thought of storing a huge amount of these triplets might be troublesome.
Could be better to nonces, sequence numbers etc. that require only the
storage of the last state.

Oh yes, and I should mention all this should be ready and defined in
the March IETF...

Jari
[1] http://search.ietf.org/internet-drafts/draft-garcia-sipping-3gpp-reqs-00.txt