Subject: [Sip] draft-dotson-sip-mutual-auth

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 16 Nov 2008 20:07:18 +0100

(As WG chair)

A long while back there was some interest in getting this chartered as a
SIP WG item.

We have been having a long and delayed thread external to the list on
this which may be summarised as:

-	the AD wants evidence of a clear use case

-	the security adviser to the SIP WG not seeing that there is a
use case.

-	the authors having so far failed to convince either.

I attach the two key mails that relate to the technical discussion and
you can scroll down and see the rest of the thread.

I invite other members of the SIP WG to add further input to this
discussion.

regards

Keith

Subject: RE: Mutual-auth
From: "Sumanth Channabasappa" <[email-masked]>
To: "Stuart Hoggan" <[email-masked]>, "Eric Rescorla" <[email-masked]>
Cc: "Cullen Jennings" <[email-masked]>, "Dean Willis" <[email-masked]>, "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 31 Jul 2008 10:21:38 +0100

Ekr,

Any further thoughts on this? Let us know if you want to get on a quick
call to discuss this further. 

- S

-----Original Message-----
From: Stuart Hoggan 
Sent: Tuesday, July 08, 2008 7:09 PM
To: 'Eric Rescorla'
Cc: Cullen Jennings; Dean Willis; Sumanth Channabasappa; DRAGE, Keith
(Keith)
Subject: RE: FW: Mutual-auth

Hi Ekr,

Responses are inline...

-Stuart

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Friday, July 04, 2008 9:47 AM
> To: DRAGE, Keith (Keith)
> Cc: Cullen Jennings; Eric Rescorla; Dean Willis; Sumanth
Channabasappa;
> Stuart Hoggan
> Subject: Re: FW: Mutual-auth
> 
> I'm sorry, I'm still not getting what the issue is here.
> 
> 1. As I understand the situation, this mechanism only gets engaged
>    when the proxy challenges the UAC. So, if the proxy doesn't
>    share a key with the UAC, then why doesn't it just not challenge
>    the UAC? How does the UAC know? You can just mount an
>    MITM attack, right?

You are correct in that the UAC does not know whether P2 is a proxy with
which it shares a key or not! This allows for two kinds of attacks:

= Impersonation: A rogue proxy responds as though it is a valid proxy
that should be responding to the UAC. Such a proxy may not challenge the
request (and the UAC will not know). Or it may challenge the UAC to
obtain enough challenge response information to launch say a dictionary
attack (again the UAC will not know). 

= MITM: Which you describe, and you are right, the UAC would not know.
However, this MiM may be 'passive' or 'active'. In the case of the
latter, it can modify the header or the body to cause undesirable
behavior even when the two endpoints are 'valid'.

The Proxy-Authentication-Info header mitigates some of these issues.
Specifically, it limits a rogue proxy from launching an impersonation
attack (non-MITM) and get away with a fake challenge. It also provides
for limited integrity protection over the response to limit active
modification of (parts of) the response in the case of an active MITM
attack.

> 
> 2. In many cases, the UAC has no real way of knowing who its
>    non first-hop proxies are. How does this work if the
>    first hop proxy makes a different routing decision?
> 
> 3. As I understand it, this doesn't let the UAC challenge
>    or authenticate requests from P2, right? So, this seems
>    rather limited.

I will respond to 2 and 3 together. In #3 you hit on a good point, which
is that the mechanism proposed does not allow a UAC to challenge P2. (Is
there a way to do it in SIP?). Assuming that there are no mechanisms for
the client to challenge the proxy:
- the UAC can be configured (say, in PacketCable) to expect a challenge
for a request, and to verify that this challenge response allows for
mutual authentication. If there is no challenge, or mutual
authentication is unsuccessful, the UAC retries.
 - the proxy is similarly configured, i.e., it challenges the requests
and ensures mutual authentication in the response.

The above allows a client to - indirectly - challenge a proxy that
accepts its request, mitigating part of the security threats. Apart from
security reasons, it also allows for efficiency (e.g., next-nonce). 

This is similar to the Authentication-Info header in RFC3261, except
that it is not being presented as an optional header. 

[I am also curious as to why the Authentication-Info header presents a
significant advantage for UAC-Registrar over Proxy-Authentication-Info
header for UAC-Proxy]?

> 
> Can you please describe an attack which this mechanism would
> circumvent?
> 
> -Ekr
> 
> 
> At Thu, 3 Jul 2008 18:35:48 +0200,
> DRAGE, Keith (Keith) wrote:
> >
> > Some more information from the author, or at least a colleague.
> >
> > Regards
> >
> > Keith
> >
> > -----Original Message-----
> > From: Sumanth Channabasappa [mailto:[email-masked]]
> > Sent: Thursday, July 03, 2008 5:32 PM
> > To: DRAGE, Keith (Keith); Stuart Hoggan
> > Subject: RE: Mutual-auth
> >
> > Keith,
> >
> > Stuart is on vacation, so I am filling in for him.
> >
> >
> > To respond to the AD's question:
> > "This would be used in deployments where the SIP UA authenticates
with
> > proxies beyond the next-hop, mutual authentication is required (or
> > desired), and TLS with the next-hop does not suffice (or is absent).
> >
> > To be specific, if the deployment scenario is that the SIP UA
> > authenticates with the next-hop, and that's all there is to it
(e.g.,
> > the next-hop is trusted by the remote proxy or the TLS with the
next-hop
> > is sufficient), then the header proposed in this I-D is not
required.
> > However, if the scenario is that the SIP UA is being challenged by a
> > proxy that is not the next-hop and conditions such as: there is no
TLS
> > with the next-hop or the next-hop is not trusted by the remote proxy
is
> > possible, then you need mechanisms proposed in this I-D (or
similar).
> >
> > Another scenario (brought up by Scott in the WG) is where you have
> > multiple proxies beyond the next-hop, and the client mutual
> > authenticates with two or more of them (assume there is no
relationship
> > between them). We cannot rely on TLS between the UA and the next-hop
> > (unless there are security mechanisms between the proxies, implying
> > proxy-proxy relationships). Current digest procedures in 3261 do not
> > allow a UA to authenticate such remote proxies (they only allow
remote
> > proxies to authenticate the UA).
> >
> > Examples of deployments are IMS and PacketCable. The UA registers
with
> > the S-CSCF (in the role of a SIP Registrar) via the P-CSCF. This
> > registration is mutually authenticated, but TLS may or may not be
> > established. If TLS is not established, then future SIP requests
from
> > the client (e.g., SIP INVITE) that are sent to the network are
> > challenged by the S-CSCF (in the role of a SIP proxy). When this
occurs
> > we need to allow for the client to authenticate the S-CSCF to avoid
> > security threats such as CSCF impersonations. This cannot be done
> > without an equivalent of the Authentication-Info header supported
for
> > registrations.
> >
> > Another, simpler, example (albeit less common) is the one I call
Dean's
> > home. This is where there is a SIP Proxy in the local network
through
> > which all the SIP messages are routed. In such a scenario, the local
> > Proxy is not trusted by the remote Service Providers who would
desire
> > mutual authentication between the SIP UA in the home and their
proxy.
> >
> > There was also a usecase in SPEERMINT from the last IETF where this
I-D
> > was suggested, that I don't seem to recall right now.
> >
> > As a note, since we agreed in the WG that not all deployments will
need
> > the Proxy-Authentication-Info header, we have presented it as an
> > optional mechanism and not "essential corrections". Without the I-D
(or
> > a similar mechanism) such deployments may not be able to provide for
> > mutual authentication in the identified scenarios.
> >
> >
> >
> >               SIP UA        PROXY           Remote PROXY
> >                 |                |                |
> >                 |                |                |
> >                 |   SIP REQ      |                |
> >                 |--------------->|   SIP REQ      |
> >                 |                |--------------->|
> >                 |                |     401        |
> >                 |                |<---------------|
> >                 |      401       |                |
> >                 |<---------------|                |
> >                 |                |                |
> >                 |                |                |
> >                 |                |                |
> >                 |                |                |
> >                 |                |                |
> >                 |SIP REQ(pr-auth)|                |
> >                 |--------------->|SIP REQ(pr-auth)|
> >                 |                |--------------->|
> >                 |                |200(pr-authinfo)| <--- This header
is
> > what
> >                 |                |<---------------|      being
proposed
> >                 |200(pr-authinfo)|                |
> >                 |<---------------|                |
> >                 |                |                |
> >                 |                |                |
> >
> > "
> >
> >
> > Let me know if this helps.
> >
> > - S
> >
> > -----Original Message-----
> > From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> > Sent: Thursday, July 03, 2008 2:54 AM
> > To: Stuart Hoggan; Sumanth Channabasappa
> > Subject: Mutual-auth
> >
> > One question back from the AD:
> >
> > "I've asked in the past but I am still unclear on where or why this
> > would be deployed. It was never clear to me what problem it solved.
> > I'm not saying there is not one, I'm just unclear on what it is. Do
you
> > guys understand the need for it? If it was clear what the problem
was, i
> > think we could generate more support for this or not."
> >
> > Apart from just answering IMS, is there something more coherent you
> > would like to put into words.
> >
> > Keith

Subject: Re: Chartering of draft-dotson-sip-mutual-auth
From: "Eric Rescorla" <[email-masked]>
To: "DRAGE, Keith \(Keith\)" <[email-masked]>
Cc: "Cullen Jennings" <[email-masked]>, "Eric Rescorla" <[email-masked]>, <[email-masked]>
Date: Sat, 8 Nov 2008 19:03:07 +0100

At Wed, 5 Nov 2008 15:55:20 +0100,
DRAGE, Keith (Keith) wrote:
> We made a charter request some time ago to charter work based on:
> 
>
http://www.ietf.org/internet-drafts/draft-dotson-sip-mutual-auth-03.txt
> 
> There was ongoing discussion between EKR and the proposers on the need
> for this.
> 
> As far as I know the last input was made by the authors, and no
further
> response has been heard from either EKR or Cullen.
> 
> Do I therefore understand it is acceptable to charter this work?

Hi Keith,

So, I reread the document and went to write a review explaining my
concerns with it, only to find that I have an existing review of 
of the current (-03) version in my reviews directory.

To recap, I don't see an interesting attack that this mechanism
prevents. An attacker can generally insert themselves in the of the
signalling channel and as long as they remain invisible vis-a-vis the
SIP routing headers seen by the end-host, they can simply proxy any
challenge/response interactions that the user attempts to use to
validate correctness. This is easily sufficient to mount passive
observation attacks on the signalling and is also sufficient to
mount active attacks as long as those particular messages aren't
subject to Digest Auth (and as far as I know, nobody expects
all messages to be so subject, as this would be very inefficient).

Rereading Sumanth's response from 7/31, I don't see that it 
describes any particularly compelling use cases either, so my
opinion remains that this is a solution looking for a problem.
As a practical matter, this style of initial cryptographic
authentication followed by cleartext messaging only really works
well either as (1) an imperfect access control mechanism or (2) in
environments where the channel over which the signalling is
being sent is secured (TLS in the case of SIP). However, neither
situation applies here.

Accordingly, IMO this document shouldn't be chartered until it
comes with a much more compelling security rationale. If, in
future, a rationale is provided that you find convincing, I'll
be happy to rereview the document in that light at that time.

-Ekr

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

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Sun, 16 Nov 2008 20:25:00 -0700

Keith,

Thanks for resurfacing this, it has been a while! To refresh the group's
memory the origin of the I-D was the need to allow a UA to mutually
authenticate with proxies other than the next-hop
(UA<->Proxies<->Proxy). For authenticating with the next-hop proxy, TLS
should be used (as acknowledged in the I-D). The earlier versions (-01
and -02) raised more questions than answers! With -03 there seemed to be
a few interested people within this WG (and outside) who saw value in
this I-D (e.g., Scott Lawrence, Milan Patel, Christer Holmberg, Martin
Dolly, Francois Audet; see emails from around July '08). It would be
nice to get their feedback once again on the need (or not) for this
requirement (independent of the I-D). If we still see a need for this
requirement, I would solicit suggestions to revise the I-D to clearly
articulate the requirement and the potential solution(s).

Additionally, I had offline discussions (in Ireland) with one of the ADs
(Cullen) who saw value in (or at least did not dismiss) this I-D; unless
I misunderstood the conversation. We left the conversation with a plan
to discuss further with the security adviser. Did we miss any further
communication (from the ADs)?

Ekr, 

Thanks for your response. To clarify, perhaps the I-D is not the answer
to the requirement we are trying to solve, in which case we need to look
at other alternatives (or surface other I-Ds). I (personally) would not
like the I-D to be the holdup for us to solve the need (stated above).

I have a few follow-up responses to your comments. When you say
"cryptographic authentication followed by clear text messaging", I am
hoping that you are not dismissing subsequent challenges. For example,
if there is a UA request which is deemed sensitive, the proxy should
challenge it. To ensure that an 'impersonator' cannot get away without a
challenge, the UA can be configured to discontinue further messaging in
the absence of a challenge (this is because we don't have a mechanism
for the UA to challenge the proxy, unless I am mistaken). This may not
prevent a passive attack, but would it not thwart an active attack? If
not, given the limited integrity protection offered by the header,
should we extend the requirements to provide better integrity
protection? Is that an option?

In response to your second point about the non-applicability of secure
signaling, the I-D allows for the UA to mutually authenticate with
multiple non-next-hop proxies, each of which can share unique
credentials with the UA. This model works even in the presence of TLS.
Why is this not applicable, or am I missing the point (sorry, it has
been a while since we discussed this issue)? 

Thanks!

- S

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Sunday, November 16, 2008 1:07 PM
To: [email-masked]
Cc: Eric Rescorla; Sumanth Channabasappa
Subject: draft-dotson-sip-mutual-auth

(As WG chair)

regards

Keith

---

From: "Scott Lawrence" <[email-masked]>
Date: Tue, 25 Nov 2008 15:03:59 -0500

> communication (from the ADs)?

I think that this is a simple and obvious extension of the existing HTTP
digest mechanism.  SIP made the choice to change proxy authentication
from the hop-by-hop architecture from HTTP to the end-to-middle model in
SIP, but did not adopt the ability of the end to verify that the proxy
actually can verify the credentials. 

It seems entirely reasonable to me to rectify this now.

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Tue, 25 Nov 2008 14:32:08 -0700

Scott,

I had additional offline discussions with Ekr and Cullen last week. Ekr
indicated that the proposed I-D does not align with the SIP security
model (UE <=> next-hop authentication; no need for UE <=>
<authentication beyond next hop>). 

This led to the question as to why we allow for the use of the
Authentication-Info header. The response I received was that this may
have been an oversight. If this is the case, I indicated that we may
want to clarify (or correct) this. 

Ekr, Cullen,

Feel free to add (or correct) my understanding.

- S

<snip>

---

From: Dean Willis <[email-masked]>
Date: Tue, 25 Nov 2008 17:30:01 -0600

> <authentication beyond next hop>).

Huh?

We have long held that there may be multiple proxies (possibly in  
different domains) challenging a given request. This has been a  
hallmark of scenarios such as the "hotel proxy" that doesn't do  
authentication or act as a an identity server but that does do local  
firewall control.

So somebody is confused about something. Who knows, might be me,  
occasionally I wake up in a different time-space continuum, but AFAIK,  
we've always intended to support authentication more than one hop  
away. In fact, I recall design discussions with Pingtel and 3Com  
people about that as far back as 1999. Robert Sparks had a lot to say  
about it, IIRC.

--
Dean

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 26 Nov 2008 11:42:03 -0700

Huh?

[S] My understanding -- based on the offline discussions -- is that the
proxy can still challenge the UA. However, the UA trusts its connection
with the next-hop and does not need to authenticate any elements beyond
the next-hop. In other words, mutual authentication is not necessary (I
used <=> to indicate mutual authentication). [[ Today, we allow for the
Authentication-Info header that allows the UA to authenticate the
registrar (even after it has established TLS with the next-hop proxy),
which also breaks this model. ]]

- S