[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-ietf-sip-media-security-requirements-05
With respect to the proposed text for R-CERTS, I agree with Dean that
this doesn't seem like a requirement on protocols, but on how protocols
are operated. The set of trust anchors that peers choose is an
operating policy choice of those peers, not an issue of protocol.
Perhaps you could put some operating recommendations in the explanatory
section, but I don't think this issue belongs in the requirements for
the protocol.
One minor technical issue with the explanatory text: Both parties don't
need to trust the same trust anchor, but each peer has to have a trust
anchor that can be used to validate the other.
--RLB
Eric Rescorla wrote:
> At Tue, 13 May 2008 08:38:33 -0400,
> Dan York wrote:
>> Dan,
>>
>>> The 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 seFrom sip-bounces at ietf.org Mon May 19 12:08:40 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 B9C153A6ABF;
Mon, 19 May 2008 12:08:40 -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 D20A03A6B83
for <sip at core3.amsl.com>; Mon, 19 May 2008 12:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=-0.001,
BAYES_50=0.001]
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 9LyuKn-6W1lZ for <sip at core3.amsl.com>;
Mon, 19 May 2008 12:08:12 -0700 (PDT)
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81])
by core3.amsl.com (Postfix) with ESMTP id AF6D428C17E
for <sip at ietf.org>; Mon, 19 May 2008 12:04:07 -0700 (PDT)
Received: from dhcp89-089-033.bbn.com ([128.89.89.33] helo=[127.0.0.1])
by mx12.bbn.com with esmtp (Exim 4.60)
(envelope-from <rbarnes at bbn.com>)
id 1JyAeP-0006Mf-3r; Mon, 19 May 2008 15:04:01 -0400
Message-ID: <4831CF20.3070203 at bbn.com>
Date: Mon, 19 May 2008 15:04:00 -0400
From: Richard Barnes <rbarnes at bbn.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Eric Rescorla <ekr at networkresonance.com>
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>
In-Reply-To: <20080513171527.4D4025081A at romeo.rtfm.com>
Cc: 'IETF SIP List' <sip at ietf.org>, Dan Wing <dwing at cisco.com>, "'Fries,
Steffen \(CT\)'" <steffen.fries at siemens.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
With respect to the proposed text for R-CERTS, I agree with Dean that
this doesn't seem like a requirement on protocols, but on how protocols
are operated. The set of trust anchors that peers choose is an
operating policy choice of those peers, not an issue of protocol.
Perhaps you could put some operating recommendations in the explanatory
section, but I don't think this issue belongs in the requirements for
the protocol.
One minor technical issue with the explanatory text: Both parties don't
need to trust the same trust anchor, but each peer has to have a trust
anchor that can be used to validate the other.
--RLB
Eric Rescorla wrote:
> At Tue, 13 May 2008 08:38:33 -0400,
> Dan York wrote:
>> Dan,
>>
>>> The 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 rection 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 application of sip
>
>
_______________________________________________
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
lates 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 application of sip
>
>
_______________________________________________
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