[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Thoughts on SIP Identity issues
At Fri, 1 Aug 2008 09:36:36 +0100,
Dan Wing wrote:
>
> > At Thu, 31 Jul 2008 20:54:43 -0400,
> > Hadriel Kaplan wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eric Rescorla [mailto:ekr at networkresonance.com]
> > > >
> > > > Funny you should mention that.
> > > >
> > > > It's becoming increasingly clear that VBR codecs leak a fair
> > > > amount of information, even when they are encrypted [WBC+08].
> > > > So, if, for instance, you were planning to use a fixed-rate
> > > > codec and an attacker could force you into a VBR codec, that
> > > > might leak information.
> > >
> > > Fascinating paper. (truly) But it sounds more like just a reason to
> > > fix SRTP for VBR, through random padding or whatever.
> >
> > I haven't studied the problem, but I suspect random padding
> > is of limited use because it averages out. Probably better
> > to use a fixed length codec.
> >
> > However, I think focusing on that misses the larger point: the UAC aFrom sip-bounces at ietf.org Fri Aug 1 06:47:29 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 999B63A6CE3;
Fri, 1 Aug 2008 06:47:29 -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 6E16A3A6CE3
for <sip at core3.amsl.com>; Fri, 1 Aug 2008 06:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.468
X-Spam-Level:
X-Spam-Status: No, score=-0.468 tagged_above=-999 required=5 tests=[AWL=0.027,
BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
RDNS_NONE=0.1]
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 9IhvYGAK+Muh for <sip at core3.amsl.com>;
Fri, 1 Aug 2008 06:47:27 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [74.95.2.169])
by core3.amsl.com (Postfix) with ESMTP id 894573A6CA6
for <sip at ietf.org>; Fri, 1 Aug 2008 06:47:27 -0700 (PDT)
Received: from kilo-2.local (localhost [127.0.0.1])
by kilo.rtfm.com (Postfix) with ESMTP id 1B8C9516C54;
Fri, 1 Aug 2008 06:46:10 -0700 (PDT)
Date: Fri, 01 Aug 2008 06:46:10 -0700
From: Eric Rescorla <ekr at networkresonance.com>
To: "Dan Wing" <dwing at cisco.com>
In-Reply-To: <0a2101c8f3b1$b75dd500$6a94150a at cisco.com>
References: <0D5F89FAC29E2C41B98A6A762007F5D0F266CD at GBNTHT12009MSX.gb002.siemens.net>
<02829328-7B0E-41AB-B325-01246363D09C at cisco.com>
<4DAE5E60BA49D8419D7C8832503F5FFC072817AF26 at EVS10.ams.gblxint.com>
<0D5F89FAC29E2C41B98A6A762007F5D0F26CCB at GBNTHT12009MSX.gb002.siemens.net>
<48919248.7060600 at cisco.com>
<0ae201c8f310$d183a0f0$3675150a at cisco.com>
<E6C2E8958BA59A4FB960963D475F7AC30F04C561DB at mail.acmepacket.com>
<20080731205152.03E7E514892 at kilo.rtfm.com>
<E6C2E8958BA59A4FB960963D475F7AC30F04C5632F at mail.acmepacket.com>
<20080801010212.654B5515743 at kilo.rtfm.com>
<0a2101c8f3b1$b75dd500$6a94150a at cisco.com>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080801134611.1B8C9516C54 at kilo.rtfm.com>
Cc: 'Cullen Jennings' <fluffy at cisco.com>, "'Uzelac,
Adam'" <Adam.Uzelac at globalcrossing.com>,
'SIP IETF' <sip at ietf.org>, "'Elwell, John'" <john.elwell at siemens.com>
Subject: Re: [Sip] Thoughts on SIP Identity issues
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
At Fri, 1 Aug 2008 09:36:36 +0100,
Dan Wing wrote:
>
> > At Thu, 31 Jul 2008 20:54:43 -0400,
> > Hadriel Kaplan wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eric Rescorla [mailto:ekr at networkresonance.com]
> > > >
> > > > Funny you should mention that.
> > > >
> > > > It's becoming increasingly clear that VBR codecs leak a fair
> > > > amount of information, even when they are encrypted [WBC+08].
> > > > So, if, for instance, you were planning to use a fixed-rate
> > > > codec and an attacker could force you into a VBR codec, that
> > > > might leak information.
> > >
> > > Fascinating paper. (truly) But it sounds more like just a reason to
> > > fix SRTP for VBR, through random padding or whatever.
> >
> > I haven't studied the problem, but I suspect random padding
> > is of limited use because it averages out. Probably better
> > to use a fixed length codec.
> >
> > However, I think focusing on that misses the larger point: the UAC and
> > Und
> > UAS have certain desires as expressed in the messages/SDP
> > To the extent to which we allow the intermediaries to change
> > those messages, we need to carefully analyze each instance,
> > and this analysis may actually depend on facts yet to be
> > discovered.
>
> 4474 allows intermediaries to change SDP, and re-create a new
> >From and a new signature.
Well, it allows it in the sense that there's no known
cryptographic way to stop it in any system, then sure.
> This (a) destroys end-to-end identity
> (which is the subject of this thread) *and* (b) allows
> intermediaries to perform the very downgrade attack you
> cited ([WBC+08]).
>
> This is why I want to improve upon 4474.
I don't agree with this analysis.
Let's say that alice at atlanta.com sends bob at biloxi.com an INVITE.
It's 4474 signed by atlanta.com. Now, some SBC in the middle
edits the SDP. This breaks the signature.
At this point, when Bob gets the message, he knows:
(1) This message claims to be from Alice.
(2) The signature was broken.
He therefore has no knowledge of what happen. He can choose to
accept or reject the call, but can't reasonably infer that
the call came from Alice or anything else about Alice's
intentions.
Now, if the SBC resigns, then Bob gets a valid message
from somebody else other than Alice. Effectively, the
SBC. Now, the SBC claims that it is connecting Bob to
Alice, but it could be lying. If Bob trusts the SBC,
he can accept the call, but he's trusting the SBC.
Sure, the SBC can edit the SDP to replace codecs, but
it can do *anything*. It could, for instance, replace
the DTLS-SRTP fingerprint. This isn't surprising, since
the SBC is really a B2BUA and this is a call from it.
The schemes being proposed here allow the RFC 4474 signature
to survive some editing of the message by the SBC. The
question here is the extent to which that enables *silent*
attacks by the SBC. To take an extreme case, if we allowed
editing of the fingerprint, then Bob could think he was
talking to Alice, but he was actually talking to the
SBC. Editing the codecs to allow this kind of traffic
analysis is a (much) less serious version of the same
threat. Again, this differs qualitatively from the former
case because Bob does not know he is under attack.
The question, then, when someone proposes exempting some
field from the signature, is what silent attacks it enables.
I have yet to see any satisfactory analysis along these
lines.
-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
AS have certain desires as expressed in the messages/SDP
> > To the extent to which we allow the intermediaries to change
> > those messages, we need to carefully analyze each instance,
> > and this analysis may actually depend on facts yet to be
> > discovered.
>
> 4474 allows intermediaries to change SDP, and re-create a new
> >From and a new signature.
Well, it allows it in the sense that there's no known
cryptographic way to stop it in any system, then sure.
> This (a) destroys end-to-end identity
> (which is the subject of this thread) *and* (b) allows
> intermediaries to perform the very downgrade attack you
> cited ([WBC+08]).
>
> This is why I want to improve upon 4474.
I don't agree with this analysis.
Let's say that alice at atlanta.com sends bob at biloxi.com an INVITE.
It's 4474 signed by atlanta.com. Now, some SBC in the middle
edits the SDP. This breaks the signature.
At this point, when Bob gets the message, he knows:
(1) This message claims to be from Alice.
(2) The signature was broken.
He therefore has no knowledge of what happen. He can choose to
accept or reject the call, but can't reasonably infer that
the call came from Alice or anything else about Alice's
intentions.
Now, if the SBC resigns, then Bob gets a valid message
from somebody else other than Alice. Effectively, the
SBC. Now, the SBC claims that it is connecting Bob to
Alice, but it could be lying. If Bob trusts the SBC,
he can accept the call, but he's trusting the SBC.
Sure, the SBC can edit the SDP to replace codecs, but
it can do *anything*. It could, for instance, replace
the DTLS-SRTP fingerprint. This isn't surprising, since
the SBC is really a B2BUA and this is a call from it.
The schemes being proposed here allow the RFC 4474 signature
to survive some editing of the message by the SBC. The
question here is the extent to which that enables *silent*
attacks by the SBC. To take an extreme case, if we allowed
editing of the fingerprint, then Bob could think he was
talking to Alice, but he was actually talking to the
SBC. Editing the codecs to allow this kind of traffic
analysis is a (much) less serious version of the same
threat. Again, this differs qualitatively from the former
case because Bob does not know he is under attack.
The question, then, when someone proposes exempting some
field from the signature, is what silent attacks it enables.
I have yet to see any satisfactory analysis along these
lines.
-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