[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] A proposal for breaking the DTLS-SRTP vsRFC4474 gateway deadlock
I think that seem to highlight all the problems so I can live with
that if we can just get this done.
Cullen <with my individual contributor hat on>
On Jul 1, 2008, at 7:32 PM, Eric Rescorla wrote:
At Tue, 24 Jun 2008 12:48:20 -0700,
Eric Rescorla wrote:
From sip-bounces at ietf.org Wed Jul 2 09:53:22 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 BA5373A6916;
Wed, 2 Jul 2008 09:53:22 -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 6473A3A6916
for <sip at core3.amsl.com>; Wed, 2 Jul 2008 09:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.472
X-Spam-Level:
X-Spam-Status: No, score=-106.472 tagged_above=-999 required=5
tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4,
USER_IN_WHITELIST=-100]
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 BdvkNsa-eI6W for <sip at core3.amsl.com>;
Wed, 2 Jul 2008 09:53:17 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71])
by core3.amsl.com (Postfix) with ESMTP id B5CBA3A68BE
for <sip at ietf.org>; Wed, 2 Jul 2008 09:53:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,738,1204502400"; d="scan'208";a="62244601"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
by sj-iport-2.cisco.com with ESMTP; 02 Jul 2008 16:53:27 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m62GrRUf022831;
Wed, 2 Jul 2008 09:53:27 -0700
Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82])
by sj-core-5.cisco.com (8.13.8/8.13.8) with SMTP id m62GrQdS015975;
Wed, 2 Jul 2008 16:53:26 GMT
From: Cullen Jennings <fluffy at cisco.com>
To: "Eric Rescorla" <ekr at networkresonance.com>
In-Reply-To: <20080702023258.76C78327549 at kilo.rtfm.com>
Impp: xmpp:cullenfluffyjennings at jabber.org
References: <7C76092F-6FD4-4951-9166-935CC9001ACD at softarmor.com><20080624194820.BD39B306834 at kilo.rtfm.com>
<20080702023258.76C78327549 at kilo.rtfm.com>
Message-Id: <1D391976-37ED-4E49-AD84-A3726F2298D6 at cisco.com>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Wed, 2 Jul 2008 09:53:16 -0700
X-Mailer: Apple Mail (2.924)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3856; t=1215017607;
x=1215881607; c=relaxed/simple; s=sjdkim1004;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=fluffy at cisco.com;
z=From:=20Cullen=20Jennings=20<fluffy at cisco.com>
|Subject:=20Re=3A=20[Sip]=20A=20proposal=20for=20breaking=2
0the=20DTLS-SRTP=20vsRFC4474=09gateway=09deadlock |Sender:=20;
bh=JYvi5iQqT68/YV+yasO4kcxYPMY0GFvPPYZ5zRxrhdY=;
b=VA+u6yW8ftlXILY/Ums8wZ3L8hEYJyBz3W60SyTCEzRLSjNDZXBc2xJpU5
V6XutY8iAMQBu9/TzWCbdPj5CglfZ+eDe1sQShyfUTgVFrOUvapZPiBITguq
apOS7zQUCVGQhDDxRfhWBc/G3YMsb30a19r9p5hj9WXPeeYNM40DM=;
Authentication-Results: sj-dkim-1; header.From=fluffy at cisco.com; dkim=pass (
sig from cisco.com/sjdkim1004 verified; );
Cc: sip at ietf.org, Eric Rescorla <ekr at rtfm.com>,
Keith Drage <drage at alcatel-lucent.com>,
Dean Willis <dean.willis at softarmor.com>
Subject: Re: [Sip] A proposal for breaking the DTLS-SRTP
vsRFC4474 gateway deadlock
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
I think that seem to highlight all the problems so I can live with
that if we can just get this done.
Cullen <with my individual contributor hat on>
On Jul 1, 2008, at 7:32 PM, Eric Rescorla wrote:
At Tue, 24 Jun 2008 12:48:20 -0700,
Eric Rescorla wrote:
>
>
>
>
> Dean,
>
> This sounds like an excellent way to proceed. I'll generate some
candidate text
> and send it to the list in the next few days.
As promised, here's my proposed text:
Because DTLS-SRTP uses RFC 4474 to bind the media keying material
to
the SIP signalling, the assurances about the provenance and
security
of the media are only as good as those for the signalling. There
are
two important cases to note here:
o RFC 4474 assumes that the proxy with the certificate
"example.com"
controls the namespace "example.com". Therefore the RFC 4474
authentication service which is authoritative for a given
namespace can control which user is assigned each name. Thus,
the
authentication service can take an address formerly assigned to
Alice and transfer it to Bob. This is an intentional design
feature of RFC 4474 and a direct consequence of the SIP
namespace
architecture.
o When phone number URIs (e.g.,
'sip:+17005551008 at chicago.example.com') are used, there is no
structural reason to trust that the domain name is authoritative
for a given phone number, although individual proxies and UAs
may
have private arrangements that allow them to trust other
domains.
This is a structural issue in that PSTN elements are trusted to
assert their phone number correctly and that there is no real
concept of a given entity being authoritative for some number
space.
In both of these cases, the assurances of DTLS-SRTP provides in
terms of data origin integrity and confidentiality are necessarily
no better than SIP provides for signalling integrity when RFC 4474
is used. Implementors should therefore take care not to indicate
misleading peer identity information in the user interface.
e.g. If the peer's identity is
sip:+17005551008 at chicago.example.com, it is not sufficient to
display that the identity of the peer is +17005551008. In cases
where the UA can determine that the peer identity is clearly an
E.164 number, it may be less confusing to simply identify the call
as encrypted but to an unknown peer.
In addition, some middleboxes (B2BUAs and Session Border
Controllers) are known to modify portions of the SIP message which
are included in the RFC 4474 signature computation, thus breaking
the signature. This sort of man-in-the-middle operation is
precisely the sort of message modification that 4474 is intended to
detect. In cases where the middlebox is itself permitted to
generate valid RFC 4474 signatures (e.g., it is within the same
administrative domain as the RFC 4474 authentication service), then
it may generate a new signature on the modified
message. Alternately, the middlebox may be able to sign with some
other identity that it is permitted to assert. Otherwise, the
recipient cannot rely on the RFC 4474 Identity assertion, and the
DTLS-SRTP call set up will fail or be marked as a call with an
unknown peer.
-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
Dean,
>
> This sounds like an excellent way to proceed. I'll generate some
candidate text
> and send it to the list in the next few days.
As promised, here's my proposed text:
Because DTLS-SRTP uses RFC 4474 to bind the media keying material
to
the SIP signalling, the assurances about the provenance and
security
of the media are only as good as those for the signalling. There
are
two important cases to note here:
o RFC 4474 assumes that the proxy with the certificate
"example.com"
controls the namespace "example.com". Therefore the RFC 4474
authentication service which is authoritative for a given
namespace can control which user is assigned each name. Thus,
the
authentication service can take an address formerly assigned to
Alice and transfer it to Bob. This is an intentional design
feature of RFC 4474 and a direct consequence of the SIP
namespace
architecture.
o When phone number URIs (e.g.,
'sip:+17005551008 at chicago.example.com') are used, there is no
structural reason to trust that the domain name is authoritative
for a given phone number, although individual proxies and UAs
may
have private arrangements that allow them to trust other
domains.
This is a structural issue in that PSTN elements are trusted to
assert their phone number correctly and that there is no real
concept of a given entity being authoritative for some number
space.
In both of these cases, the assurances of DTLS-SRTP provides in
terms of data origin integrity and confidentiality are necessarily
no better than SIP provides for signalling integrity when RFC 4474
is used. Implementors should therefore take care not to indicate
misleading peer identity information in the user interface.
e.g. If the peer's identity is
sip:+17005551008 at chicago.example.com, it is not sufficient to
display that the identity of the peer is +17005551008. In cases
where the UA can determine that the peer identity is clearly an
E.164 number, it may be less confusing to simply identify the call
as encrypted but to an unknown peer.
In addition, some middleboxes (B2BUAs and Session Border
Controllers) are known to modify portions of the SIP message which
are included in the RFC 4474 signature computation, thus breaking
the signature. This sort of man-in-the-middle operation is
precisely the sort of message modification that 4474 is intended to
detect. In cases where the middlebox is itself permitted to
generate valid RFC 4474 signatures (e.g., it is within the same
administrative domain as the RFC 4474 authentication service), then
it may generate a new signature on the modified
message. Alternately, the middlebox may be able to sign with some
other identity that it is permitted to assert. Otherwise, the
recipient cannot rely on the RFC 4474 Identity assertion, and the
DTLS-SRTP call set up will fail or be marked as a call with an
unknown peer.
-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