[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-ietf-sip-media-security-requirements-05
Hi Eric,
your proposal is fine with me. I just have one point I would like to
change. Your current proposal is restricted to media plane key
management protocols. I think the text you proposed holds for both
(media and signaling) so I would suggest to just state "key management
protocol" instead of "media plane key management protocol" in section
4.9
Ciao
Steffen
> -----Original Message-----
> From: Eric Rescorla [mailto:ekr at networkresonance.com]
> Sent: Tuesday, May 13, 2008 7:15 PM
> To: Dan York
> Cc: Dan Wing; 'Eric Rescorla'; 'IETF SIP List'; Fries,
> Steffen (CT); 'Dean Willis'
> Subject: Re: [Sip] draft-ietf-sip-media-security-requirements-05
>
> At Tue, 13 May 2008 08:38:33 -0400,
> Dan York wrote:
> >
> > >
> > Dan,
> >
> > > TheFrom sip-bounces at ietf.org Wed May 14 03:36:59 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 DDC823A692C;
Wed, 14 May 2008 03:36:59 -0700 (PDT)
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 6DFA13A67A2
for <sip at core3.amsl.com>; Wed, 14 May 2008 03:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level:
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5
tests=[AWL=-1.200, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 ZVSExjbIOT05 for <sip at core3.amsl.com>;
Wed, 14 May 2008 03:36:54 -0700 (PDT)
Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2])
by core3.amsl.com (Postfix) with ESMTP id 174553A697E
for <sip at ietf.org>; Wed, 14 May 2008 03:36:33 -0700 (PDT)
Received: from mail3.siemens.de (localhost [127.0.0.1])
by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m4EA5HIn006242;
Wed, 14 May 2008 12:05:17 +0200
Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net
[139.25.131.189])
by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id
m4EA5HSd003210; Wed, 14 May 2008 12:05:17 +0200
Received: from MCHP7IEA.ww902.siemens.net ([139.25.131.146]) by
mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959);
Wed, 14 May 2008 12:05:16 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 14 May 2008 12:05:09 +0200
Message-ID: <B13E851D00E14E4F8B1C2750D952FD5B9D0A at MCHP7IEA.ww902.siemens.net>
In-Reply-To: <20080513171527.4D4025081A at romeo.rtfm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] draft-ietf-sip-media-security-requirements-05
Thread-Index: Aci1HHMYvfKpCJJ1S0qciHZT+/WOkwAjK+Xw
References: <066701c8af02$2445f8e0$c3f0200a at cisco.com><20080506000110.499525081A at romeo.rtfm.com><03f901c8afde$ee9398f0$c3f0200a at cisco.com><62CA37AF-C3DD-49BE-9128-057711C78E81 at voxeo.com>
<20080513171527.4D4025081A at romeo.rtfm.com>
From: "Fries, Steffen (CT)" <steffen.fries at siemens.com>
To: "Eric Rescorla" <ekr at networkresonance.com>
X-OriginalArrivalTime: 14 May 2008 10:05:16.0122 (UTC)
FILETIME=[01E9B3A0:01C8B5AA]
Cc: IETF SIP List <sip at ietf.org>, Dan Wing <dwing at cisco.com>,
Dean Willis <dean.willis at softarmor.com>
Subject: Re: [Sip] draft-ietf-sip-media-security-requirements-05
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-Archive: <https://www.ietf.org/mailman/private/sip>
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
Hi Eric,
your proposal is fine with me. I just have one point I would like to
change. Your current proposal is restricted to media plane key
management protocols. I think the text you proposed holds for both
(media and signaling) so I would suggest to just state "key management
protocol" instead of "media plane key management protocol" in section
4.9
Ciao
Steffen
> -----Original Message-----
> From: Eric Rescorla [mailto:ekr at networkresonance.com]
> Sent: Tuesday, May 13, 2008 7:15 PM
> To: Dan York
> Cc: Dan Wing; 'Eric Rescorla'; 'IETF SIP List'; Fries,
> Steffen (CT); 'Dean Willis'
> Subject: Re: [Sip] draft-ietf-sip-media-security-requirements-05
>
> At Tue, 13 May 2008 08:38:33 -0400,
> Dan York wrote:
> >
> > >
> > Dan,
> >
> > > The wordsmi wordsmithing task falls to me, I suppose.
> > >
> > > Here is another straw man, which I think captures your sentence
> > > above your signature and your [0] comment:
> > >
> > > R-CERTS:
> > >
> > > The media security key management protocol MUST NOT require
> > > using a trust anchor to validate credentials (e.g., a
> > > certificate) or to obtain credentials (e.g., a private key)
> > > used in the protocol.
> >
> > Your wordsmithing is fine by me. I also liked the discussion you
> > included in section 4.9 which explains the rationale for this
> > requirement more.
> >
> > 4.9. Certificates
> >
> > The discussion in this section relates
> to R-CERTS.
> >
> > On the Internet and on some private
> networks, validating another
> > peer's certificate is often done
> through a trust anchor -- a list of
> > Certificate Authorities that are
> trusted. It can be difficult or
> > expensive for a peer to obtain these
> certificates. In all cases,
> > both parties to the call would need to
> trust the same trust anchor
> > (i.e., "certificate authority"). For
> these reasons, it is important
> > that authentication mechanisms that
> utilize trust anchors not rely
> > exclusively on such Certificate
> Authority-issued certificates, but
> > to
> > also allow self-signed certificates. By
> allowing the use of such
> > self-signed certificates, an
> out-of-band mechanism (e.g., manual
> > configuration) can be used to trust a
> peer's certificate.
>
> I was sort of OK with Dan's original text, though I probably
> would have wordsmithed it differently, but I don't agree with
> this discussion at all.
> Any certificate system can in principle be used with
> self-signed certs by doing SSH-style fingerprint exchange.
> The question is whether there is a practical deployment model
> that actually supports this.
>
>
> Consider two examples, both using TLS:
>
> - HTTPS in the majority of cases is incompatible with manual
> establishment
> of peer credentials. You connect to a lot of different Web
> servers and
> it's not practical to obtain their certificates out of band.
> - IMAP over TLS is compatible with manual establishment of
> peer credentials
> because you connect with only one or two servers and you
> already share
> a shared secret (the password) so it's at least in
> principle possible
> to record their cert fingerprint. This is also why SSH works.
>
> So, this isn't fundamentally an issue of protocol encoding
> (as Richard has observed) but rather of the context in which
> the protocol is embedded.
>
>
> So, I would rewrite this section as follows:
>
> On the Internet and on some private networks, validating another
> peer's certificate is often done through a trust anchor -- a list
> of Certificate Authorities that are trusted. It can be difficult
> or expensive for a peer to obtain these certificates. In all
> cases, both parties to the call would need to trust the same
> trust anchor (i.e., "certificate authority"). For these reasons,
> it is important that the media plane key management protocol
> offer a mechanism that allows end-users who have no prior
> association to authenticate to each other without acquiring
> credentials from a third party trust point. Note that this does
> not rule out mechanisms in which servers have certificates and
> attest to the identities of end-users.
>
> And since I'm in the writing business, I would adjust R-CERTS
> as follows:
>
> The media security key management protocol MUST NOT require
> that end-users obtain credentials (certificates or private
> keys) from a third-party trust anchor.
>
> -Ekr
>
_______________________________________________
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 thing task falls to me, I suppose.
> > >
> > > Here is another straw man, which I think captures your sentence
> > > above your signature and your [0] comment:
> > >
> > > R-CERTS:
> > >
> > > The media security key management protocol MUST NOT require
> > > using a trust anchor to validate credentials (e.g., a
> > > certificate) or to obtain credentials (e.g., a private key)
> > > used in the protocol.
> >
> > Your wordsmithing is fine by me. I also liked the discussion you
> > included in section 4.9 which explains the rationale for this
> > requirement more.
> >
> > 4.9. Certificates
> >
> > The discussion in this section relates
> to R-CERTS.
> >
> > On the Internet and on some private
> networks, validating another
> > peer's certificate is often done
> through a trust anchor -- a list of
> > Certificate Authorities that are
> trusted. It can be difficult or
> > expensive for a peer to obtain these
> certificates. In all cases,
> > both parties to the call would need to
> trust the same trust anchor
> > (i.e., "certificate authority"). For
> these reasons, it is important
> > that authentication mechanisms that
> utilize trust anchors not rely
> > exclusively on such Certificate
> Authority-issued certificates, but
> > to
> > also allow self-signed certificates. By
> allowing the use of such
> > self-signed certificates, an
> out-of-band mechanism (e.g., manual
> > configuration) can be used to trust a
> peer's certificate.
>
> I was sort of OK with Dan's original text, though I probably
> would have wordsmithed it differently, but I don't agree with
> this discussion at all.
> Any certificate system can in principle be used with
> self-signed certs by doing SSH-style fingerprint exchange.
> The question is whether there is a practical deployment model
> that actually supports this.
>
>
> Consider two examples, both using TLS:
>
> - HTTPS in the majority of cases is incompatible with manual
> establishment
> of peer credentials. You connect to a lot of different Web
> servers and
> it's not practical to obtain their certificates out of band.
> - IMAP over TLS is compatible with manual establishment of
> peer credentials
> because you connect with only one or two servers and you
> already share
> a shared secret (the password) so it's at least in
> principle possible
> to record their cert fingerprint. This is also why SSH works.
>
> So, this isn't fundamentally an issue of protocol encoding
> (as Richard has observed) but rather of the context in which
> the protocol is embedded.
>
>
> So, I would rewrite this section as follows:
>
> On the Internet and on some private networks, validating another
> peer's certificate is often done through a trust anchor -- a list
> of Certificate Authorities that are trusted. It can be difficult
> or expensive for a peer to obtain these certificates. In all
> cases, both parties to the call would need to trust the same
> trust anchor (i.e., "certificate authority"). For these reasons,
> it is important that the media plane key management protocol
> offer a mechanism that allows end-users who have no prior
> association to authenticate to each other without acquiring
> credentials from a third party trust point. Note that this does
> not rule out mechanisms in which servers have certificates and
> attest to the identities of end-users.
>
> And since I'm in the writing business, I would adjust R-CERTS
> as follows:
>
> The media security key management protocol MUST NOT require
> that end-users obtain credentials (certificates or private
> keys) from a third-party trust anchor.
>
> -Ekr
>
_______________________________________________
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 aon the application of sip
pplication of sip