--- Begin Message ---
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:ekr at networkresonance.com]
> 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 Uilexp03.ndc.lucent.com ([135.3.39.50]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 11:21:48 +0200
Received: from ihemail3.lucent.com ([135.245.2.37]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 04:21:42 -0500
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ihemail3.lucent.com (8.13.8/IER-i) with ESMTP id m6V9LfIr020930 for <drage at alcatel-lucent.com>; Thu, 31 Jul 2008 04:21:41 -0500 (CDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id m6V9LeGH001406; Thu, 31 Jul 2008 03:21:40 -0600
Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Thu, 31 Jul 2008 03:21:40 -0700 (MST)
Content-class: urn:content-classes:message
Subject: RE: Mutual-auth
Date: Thu, 31 Jul 2008 10:21:38 +0100
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C60132019C at srvxchg3.cablelabs.com>
In-Reply-To: <B1ED8A2E683E16479C92C3F4AE13677BE5CCE9 at srvxchg3.cablelabs.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Mutual-auth
Thread-Index: Acjd7Du/B4FPjUNrQBWJx0Ks2BI2gwDcTYZgAqjovBABu2huYA=References: <B1ED8A2E683E16479C92C3F4AE13677BE5CCE9 at srvxchg3.cablelabs.com>
From: "Sumanth Channabasappa" <sumanth at cablelabs.com>
To: "Stuart Hoggan" <s.hoggan at cablelabs.com>,
"Eric Rescorla" <ekr at networkresonance.com>
Cc: "Cullen Jennings" <fluffy at cisco.com>,
"Dean Willis" <dean.willis at softarmor.com>,
"DRAGE, Keith \(Keith\)" <drage at alcatel-lucent.com>
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:ekr at networkresonance.com]
> 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 aAC 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:sumanth at cablelabs.com]
> > 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
llow 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:sumanth at cablelabs.com]
> > 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:drage at alcatel-lucent.com]
> > 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
--- End Message ---