Subject: Re: [Sip] DISCUSS: draft-ietf-sip-dtls-srtp-frameworkdraft-ietf-sip-dtls-srtp-framework

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Nov 2008 21:04:22 -0800

>  Suresh Krishnan provided a Gen-ART Review on 5-Nov-2008.  While it
>  is a bit late, I would like to see a response to the "substantial"
>  concern that is raised.  I have not taken the time to determine if
>  the man-in-the-middle attack is possible, and I hope the authors
>  can quickly tell if there is a concern or not.  If there is a
>  concern, it needs to be corrected or documented in the security
>  considerations.

I don't believe this is a serious issue.

A response to Suresh's complete review is below.

> Summary: This draft is almost ready for publication as Proposed Standard, but I have a few comments.
> 
> Substantial
> ===========
> 
> 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. 

Note the analagous situation with SSL/TLS, where the attacker
can mount an MITM attack, but only with an identity that doesn't
match the identity that the client expects, so it's not
useful.

> Minor
> =====
> 
> * draft-ietf-avt-dtls-srtp-05 needs to become a Normative reference instead of an informative reference. Section 6.10 has the following text
> 
> "Implementations of this specification MUST support DTLS-SRTP"
> 
> making it impossible to implement this spec without implementing DTLS-SRTP. This will also lead to a downref that needs to be called out.

Good catch. It won't be a downref, though, since the other
draft is also going to PS.

> * Section 7: Call flow with STUN
> 
> "Message (6):  STUN connectivity-check response Bob -> Alice"
> 
> Bob is responding to Message 5 instead of Message 3 as stated in the text. Please replace.
> 
> Editorial
> =========
> 
> * SBC (expand at first use) : Probably add reference to draft-ietf-sipping-sbc-funcs-07
> 
> * Section 6.10: s/less highly optimized/less optimized/
> 
> Typos
> =====
> Section 1 Para 4: s/sigaling/signaling/
> 
> Section 6.7.2: s/appopriate/appropriate/
> 
> Section 6.9 Title: s/Encryptions/Encryption/
> 
> Section 7 Para 3: s/especialy/especially/
> 
> Section 8.6 para 2: s/taht/that/
> 
> Appendix A.3. : s/Reusage/Reuse/
> 
> Appendix A.18. : s/Negotation/Negotiation/

Thanks, I'll fix these.

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 06 Nov 2008 01:02:10 -0500

> useful MITM attack since Bob thinks he's talking to the

If the certificate is self-signed and nonetheless accepted in the
DTLS handshake, then anybody can forge a signature pretending it
comes from Alice, including the MITM attacker (auto-issued
certificates would have the same property). Or did I miss
something?

> match the identity that the client expects, so it's not

This is because neither self-signed certificates (at least those that do 
not acquire the "trust anchor" status by "some other means") nor 
auto-issued certificates are allowed in SSL/TLS. Otherwise, 
impersonation is possible. Or did I miss something?

I guess the draft document might proceed only if the man-in-the-middle 
attack is referred to in the security considerations for self-signed 
certificates.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Nov 2008 10:52:25 -0800

At Thu, 06 Nov 2008 10:04:43 -0500,
Suresh Krishnan wrote:
> 
> Hi Eric,
>    Thanks for the quick response.
> 
> Eric Rescorla wrote:
> 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 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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Nov 2008 14:01:33 -0800

At Thu, 06 Nov 2008 15:58:52 -0500,
Suresh Krishnan wrote:
> Again. I agree with what you said. What I was commenting on is the 
> following text from the draft
> 
> "Bob would know that an attack was happening.  The fact that
>   one side can detect this attack means that in most cases where Alice
>   and Bob both wish the communications to be encrypted there is not a
>   problem."
> 
> My question was, how would Bob detect this attack?

Because the previous few sentences explicitly state that this is
an MITM:

   In some cases, answerers will not send an UPDATE and in many calls,
   some media will be sent before the UPDATE is received.  In these
   cases, no integrity is provided for the fingerprint from Bob to
   Alice.  In this approach, an attacker that was on the signaling path
   could tamper with the fingerprint and insert themselves as a man-in-
   the-middle on the media.  Alice would know that she had a secure call
   with someone but would not know if it was with Bob or a man-in-the-
   middle.  Bob would know that an attack was happening. 

So, Bob would detect this attack by seeing that the attacker's
credentials didn't match Alice's asserted identity. Or, he
would think (correctly) that he was talking to the attacker,
in which case this isn't an attack!

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 07 Nov 2008 08:05:26 -0800

At Fri, 07 Nov 2008 10:40:34 -0500,
Suresh Krishnan wrote:
> I still don't see how Bob detects the attack. Consider the following 
> message flow.
> 
> 1) Alice->Bob : INVITE (Fingerprint(Alice)) (No Tampering)
> 2) Alice->Bob : Certificate(Alice) (No Tampering)
> 3) Bob->Eve   : Certificate(Bob)
> 4) Eve->Alice : Certificate(Eve)
> 5) Bob->Eve   : 200 OK (Fingerprint(Bob))
> 6) Eve->Alice : 200 OK (Fingerprint(Eve))
> 7) Alice->Eve : Media encrypted with Eve's public key
> 8) Eve->Bob   : Media (potentially different from step 7) encrypted with 
> Bob's public key
> 
> After this exchange Eve can intercept and modify media flowing from 
> Alice to Bob without Bob detecting the attack.

Well, I think there is some question about whether this is an attack.

Everyone's beliefs about the system are correct:

1. Alice thinks she's talking to Eve. She is.
2. Bob thinks he's talking to Eve. She is.

Note that in this particular case, Alice would presumably hang up the
phone as soon as she realized that Eve gave her a certificate that 
wasn't what she expected. The case in which Alice doesn't detect it
is where Eve doesn't provide a cert and so Alice thinks she's talking
to an unknown person.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 07 Nov 2008 08:20:55 -0800

At Fri, 07 Nov 2008 10:53:16 -0500,
Suresh Krishnan wrote:
> Yes.
> Not really. Bob thinks he is talking to Alice. The identity, fingerprint 
> and certificate of his peer in the signaling exchange belong to Alice. 
> He is encrypting all the outgoing media for Alice.

I don't think what you're describing works the way you're suggesting
it does, because there is a *handshake* between the peers. Any
asymmetry between the Alice->Bob and Bob->Alice flows is detected
in the handshake.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 07 Nov 2008 16:39:29 -0800

At Thu, 06 Nov 2008 01:02:10 -0500,

> certificates would have the same property). Or did I miss

Yes. The fingerprints in the SIP messages preclude certificate
substitution.

> impersonation is possible. Or did I miss something?

But in DTLS-SRTP the fingerprints in the SIP messages (signed
via RFC 4474) substitute for the certificate chain.

> attack is referred to in the security considerations for self-signed 

I think you misunderstand the security issues, as discussed above.

-Ekr

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 06 Nov 2008 10:04:43 -0500

Hi Eric,

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 06 Nov 2008 15:58:52 -0500

Hi Eric,

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 07 Nov 2008 10:40:34 -0500

Hi Eric,

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 07 Nov 2008 10:53:16 -0500

Hi Eric,

Yes.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 07 Nov 2008 12:02:34 -0500

Hi Eric,

> asymmetry between the Alice->Bob and Bob->Alice flows is detected

That sounds great.

Cheers
Suresh

---

From: Dean Willis <[email-masked]>
Date: Sun, 9 Nov 2008 23:02:37 -0600

> My question was, how would Bob detect this attack?

I think I understand the question. Let's check.

Bob is talking, but nobody hears what he says, since he's encrypted it  
for Alice but Alice isn't getting it. Bob may well notice that there's  
something strange here.

An attacker in this position could also have affected things such that  
the call never reaches Bob. His phone doesn't ring, and Bob isn't  
talking to anybody. So how does he know there's an attack? Why would  
Eve have even allowed any signaling to get to Bob in the first place  
if she had this sort of control?

Bob can't detect the attack, and this is not an issue with DTLS-SRTP;  
it's a fundamental aspect of the signaling model.

However, Alice, who is the only party here that's honestly engaged in  
a call and saying something that could be intercepted, CAN detect the  
attack. That's the important piece.

--
Dean

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 10 Nov 2008 09:07:08 -0500

> via RFC 4474) substitute for the certificate chain.

RFC4474 signatures are optional in this draft, isn't it?

I agree that RFC4474 signatures introduce end-to-end authentication that 
has the potential to counter MITM (man-in-the-middle) attacks. I thougth 
the discussions of this draft pertained to use cases without such 
end-to-end signatures.

> I think you misunderstand the security issues, as discussed above.

Maybe. Worse, I am reluctant to trust those who claim to understand 
security issues! Protocol security issues are reasonably understandable 
after the fact, when attackers applied their skills and creativity on 
fielded implementations.

Attackers skills and creativity has the potential to create MITM schemes 
(e.g. with sophisticated application-level proxies) when end-to-end 
cryptographic authentication is missing from a protocol arrangement.

Anyway, turning more to the point of document progress, I must admit 
that the security considerations section indeed DOES refer to MITM 
("active attack") in the last paragraph of introductory section 8. I beg 
apologies for my earlier unsupported critique.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: "Schneider, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 10 Nov 2008 16:18:34 +0100

So maybe the draft should mention in section 8.1, second paragraph, also
the possibility that an attacker may only impersonate B, without doing a
full MITM-attack.

Peter

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Dean Willis
> Sent: Monday, November 10, 2008 6:03 AM
> To: Suresh Krishnan
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [Sip] 
> DISCUSS:draft-ietf-sip-dtls-srtp-frameworkdraft-ietf-sip-dtls-
> srtp-framework
> 
>