[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-dotson-sip-mutual-auth
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 fFrom sip-bounces at ietf.org Sun Nov 16 19:25:09 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E92973A6915;
Sun, 16 Nov 2008 19:25:08 -0800 (PST)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 512393A6915
for <sip at core3.amsl.com>; Sun, 16 Nov 2008 19:25:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.463
X-Spam-Level:
X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768,
HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id EIZ6n0RIfV1b for <sip at core3.amsl.com>;
Sun, 16 Nov 2008 19:25:05 -0800 (PST)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61])
by core3.amsl.com (Postfix) with ESMTP id 0ACC03A68CF
for <sip at ietf.org>; Sun, 16 Nov 2008 19:25:05 -0800 (PST)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7])
by ondar.cablelabs.com (8.14.2/8.14.2) with ESMTP id mAH3P18I030984;
Sun, 16 Nov 2008 20:25:01 -0700
Received: from srvxchg3.cablelabs.com (10.5.0.25)
by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com);
Sun, 16 Nov 2008 20:25:01 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 16 Nov 2008 20:25:00 -0700
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601600B45 at srvxchg3.cablelabs.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180024D92F3 at DEEXC1U01.de.lucent.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-dotson-sip-mutual-auth
thread-index: AclICcNv0mAZtdqGSQq1zJHk1aHxPgAAB2twABaGkHA=
References: <5D1A7985295922448D5550C94DE29180024D92F3 at DEEXC1U01.de.lucent.com>
From: "Sumanth Channabasappa" <sumanth at cablelabs.com>
To: "DRAGE, Keith (Keith)" <drage at alcatel-lucent.com>, <sip at ietf.org>
X-Approved: ondar
Subject: Re: [Sip] draft-dotson-sip-mutual-auth
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
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 or 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:drage at alcatel-lucent.com]
Sent: Sunday, November 16, 2008 1:07 PM
To: sip at ietf.org
Cc: Eric Rescorla; Sumanth Channabasappa
Subject: draft-dotson-sip-mutual-auth
(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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
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:drage at alcatel-lucent.com]
Sent: Sunday, November 16, 2008 1:07 PM
To: sip at ietf.org
Cc: Eric Rescorla; Sumanth Channabasappa
Subject: draft-dotson-sip-mutual-auth
(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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip