[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] DISCUSS: draft-ietf-sip-dtls-srtp-frameworkdraft-ietf-sip-dtls-srtp-framework
At Thu, 06 Nov 2008 10:04:43 -0500,
Suresh Krishnan wrote:
>
> Hi Eric,
> Thanks for the quick response.
>
> Eric Rescorla wrote:
> >> Section 8.1: Responder identity
> >>
> >> When Bob does not respond with an UPDATE message, his identity is
> >> not integrity protected.
> >
> > Absolutely correct.
> >
> >
> >> The draft states that in such case, a MITM
> >> attacker may tamper with the fingerprint but Bob would be aware of
> >> this. It is not clear to me how Bob would be aware of this. Consider
> >> the scenario where an attacker Eve (who can attack both the
> >> signaling and media paths) has switched Bob's key fingerprint with
> >> hers. She can receive encrypted media coming from Alice, decrypt it
> >> for her own use and re-encrypt it for Bob and send it to him. How
> >> will Bob detect this tampering?
> >
> > This is a classic single sided authentication situation. If
> > Alice calls Bob and the attacker mounts a MITM attack, then
> > it will not be able to impersonate Alice to Bob because it
> > can't generate the correct RFC 4474 signature. Thus, either
> > the attacker won't provide a valid signature (being anonymous
> > from Bob's perspective) or it will produce a valid signature
> > with its own identity. In either case, this isn't really a
> > useful MITM attack since Bob thinks he's talking to the
> > attacker, not to Alice.
>
> I agree with everything you have said, and I this is the same
> understanding I had from the draft. The case I was concerned about
> involves the attacker impersonating Bob towards Alice, since he can
> modify the fingerprint and the certificates, thus becoming capable of
> interFrom sip-bounces at ietf.org Thu Nov 6 10:52:33 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 B541B3A69F5;
Thu, 6 Nov 2008 10:52:33 -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 E90B33A6918;
Thu, 6 Nov 2008 10:52:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level:
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
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 0yILlg6sGqcy; Thu, 6 Nov 2008 10:52:31 -0800 (PST)
Received: from kilo.rtfm.com (wireless-am10.ucsd.edu [128.54.48.14])
by core3.amsl.com (Postfix) with ESMTP id B42E53A6825;
Thu, 6 Nov 2008 10:52:30 -0800 (PST)
Received: from kilo-2.local (localhost [127.0.0.1])
by kilo.rtfm.com (Postfix) with ESMTP id D398D6F64F1;
Thu, 6 Nov 2008 10:52:25 -0800 (PST)
Date: Thu, 06 Nov 2008 10:52:25 -0800
From: Eric Rescorla <ekr at networkresonance.com>
To: Suresh Krishnan <suresh.krishnan at ericsson.com>
In-Reply-To: <4913078B.90700 at ericsson.com>
References: <20081106050422.DBE096F59D2 at kilo.rtfm.com>
<4913078B.90700 at ericsson.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: <20081106185225.D398D6F64F1 at kilo.rtfm.com>
Cc: sip at ietf.org, gen-art at ietf.org, housley at vigilsec.com, iesg at ietf.org
Subject: Re: [Sip] DISCUSS:
draft-ietf-sip-dtls-srtp-frameworkdraft-ietf-sip-dtls-srtp-framework
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 Thu, 06 Nov 2008 10:04:43 -0500,
Suresh Krishnan wrote:
>
> Hi Eric,
> Thanks for the quick response.
>
> Eric Rescorla wrote:
> >> Section 8.1: Responder identity
> >>
> >> When Bob does not respond with an UPDATE message, his identity is
> >> not integrity protected.
> >
> > Absolutely correct.
> >
> >
> >> The draft states that in such case, a MITM
> >> attacker may tamper with the fingerprint but Bob would be aware of
> >> this. It is not clear to me how Bob would be aware of this. Consider
> >> the scenario where an attacker Eve (who can attack both the
> >> signaling and media paths) has switched Bob's key fingerprint with
> >> hers. She can receive encrypted media coming from Alice, decrypt it
> >> for her own use and re-encrypt it for Bob and send it to him. How
> >> will Bob detect this tampering?
> >
> > This is a classic single sided authentication situation. If
> > Alice calls Bob and the attacker mounts a MITM attack, then
> > it will not be able to impersonate Alice to Bob because it
> > can't generate the correct RFC 4474 signature. Thus, either
> > the attacker won't provide a valid signature (being anonymous
> > from Bob's perspective) or it will produce a valid signature
> > with its own identity. In either case, this isn't really a
> > useful MITM attack since Bob thinks he's talking to the
> > attacker, not to Alice.
>
> I agree with everything you have said, and I this is the same
> understanding I had from the draft. The case I was concerned about
> involves the attacker impersonating Bob towards Alice, since he can
> modify the fingerprint and the certificates, thus becoming capable of
> intercepting cepting their communications. This attack is not detectable by Bob.
But then the attacker isn't *intercepting* their communications.
Alice calls Bob and ends up talking to someone but she knows
that she doesn't know who. The point is you can't use this to
mount an MITM attack.
-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
their communications. This attack is not detectable by Bob.
But then the attacker isn't *intercepting* their communications.
Alice calls Bob and ends up talking to someone but she knows
that she doesn't know who. The point is you can't use this to
mount an MITM attack.
-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