[VOIPSEC] Using SRTP for University project

[Alan Johnston]

Hi Hadriel,

A few comments on ZRTP below.

Thanks,
Alan
- - - -

Hadriel Kaplan wrote:

>Hi Mark,
>Comments inline...
>
>  
>
>>-----Original Message-----
>>From: Mark Baugher [mailto:mbaugher at cisco.com]
>>Sent: Monday, March 27, 2006 2:10 PM
>>To: Hadriel Kaplan
>>Cc: 'Cesc Santasusana'; Voipsec at voipsa.org; Christian.Stredicke at snom.de
>>Subject: Re: [VOIPSEC] Using SRTP for University project
>>
>>I'm not sure why you say this but it is not based on draft-ietf-
>>mmusic-sdescriptions-12.txt.  It's true that the applicability
>>section recommends either sips or s/mime.  But I don't find your
>>interpretation in this document.  This is what the document says on
>>the topic:
>>
>>"When the communication path of the SDP message is routed through
>>intermediate systems that inspect parts of the SDP message, security
>>protocols such as IPsec or TLS SHOULD NOT be used for encrypting
>>and/or authenticating the security description.  In the case of
>>intermediate-system processing of a message containing SDP security
>>descriptions, the "a=crypto" attributes SHOULD be protected end-to-
>>end so that the intermediate system can neither modify the security
>>description nor access the keying material.  Network or transport
>>security protocols that terminate at each intermediate system,
>>therefore, SHOULD NOT be used for protecting SDP security
>>descriptions.  A security protocol SHOULD allow the security
>>descriptions to be encrypted and authenticated end-to-end
>>independently of the portions of the SDP message that any
>>intermediate system modifies or inspects:  MIME secure multiparts
>>are RECOMMENDED for the protection of SDP messages that are
>>processed by intermediate systems.  "
>>    
>>
>
>Those statements are only at SHOULD strength.  You said "required", which I
>don't consider SHOULD to be. (that's why I put required in dquotes in my
>original email response)
>
>  
>
In IETF specs, implementers may choose to not obey SHOULDs only if there 
is a very strong reason not to.  Ignoring SHOULDs that relate to 
security is especially hazardous and not good practice.

In my personal opinion, the use of sdes without S/MIME is very flawed 
security.

>>It might be that this is not realistic owing to the changes that are
>>required in the infrastructure.  Saying this is much different than
>>saying that sips offers good security.
>>    
>>
>
>I didn't say sips offers "good" security.  I said it offers sufficient
>security, given the constraints. (well... I implied that anyway)
>
>  
>
>>>If that's true, you're probably in a world of hurt
>>>anyway.
>>>      
>>>
>>An end system has no way of knowing what devices are handling the
>>call message.  So you are in fact in a world of hurt if you want a
>>secure end-to-end phone call when the message is routed through
>>unknown and unknowable intermediate systems.
>>    
>>
>
>Yup, of course.  An end system only knows its local tls hop, and has to
>trust that the intermediate systems follow sips rules.  The rub is
>definitely that they rely on transitive trust, and if the chain-of-trust is
>broken they're in trouble.  My only point was if the chain is broken they're
>in trouble anyway, because their signaling says a lot, and can be
>manipulated, spoofed, rejected etc. (of course that's a generalization, but
>I think you get my point)  If you don't want it going through intermediate
>systems, don't send it through the first one you don't control.
>  
>
I think Mark's point is that by trusting the confidentiality of your 
keying material to hopwise TLS means trusting any proxy that may be 
inserted in the signaling path - this effectively means trusting every 
intermediary in every domain you traverse.  For example, even though 
your domain may be sensible about this, my domain might route the SIP 
request through 15 proxies, all of which would have access to the keying 
material...

>  
>
>>>And you don't seriously expect people to read out hex values over
>>>the phone before talking, do you?  Somehow I think that will make
>>>for a lot
>>>more car accidents due to cell phones.  :)
>>>      
>>>
>>You misunderstand the process.  One does not do this for each phone
>>call or even necessarily for the initial phone call, although that's
>>an obviously good time to establish a secure association with a user
>>who calls you or whom you are calling.  As has been pointed out on
>>this list before, the procedure is done once, the key is admitted to
>>a key ring or something like that, and then subsequent (even future)
>>calls can be authenticated end to end.
>>    
>>
>
>Yup, I understood that.  Maybe it's just me, but I get and make a lot of
>cell calls to new parties (conference calls especially), and I doubt my cell
>has enough memory for a key ring the size of my speed-dial.  But I have the
>cheap free cell phone. :) 
>I was somewhat joking about the car thing, although I'm not joking about
>changing basic user communication behavior being a bit unrealistic.  Zrtp
>though has the advantage that at least it gives you some eavesdropping
>protection if you don't care about authentication.  Although really a
>middle-man could then do ZRTP back-to-back and you'd know no better (I
>think?) - it's the key verbalizing that provides the real (authenticated)
>security if I recall.  
>  
>
ZRTP does provide authentication if a secret from the signaling (such as 
the dialog identifier which has been protected using hopwise TLS) is 
available.  Also, ZRTP uses key continuity which forces an attacker to 
perform an active DH MitM attack on every call or be detected.

>  
>
>>>(note I'm talking about the 99.9% population, not the DoD)
>>>      
>>>
>>Most people won't do this, just as most people do not use secure
>>email.  But we need to have these things for people who do want to
>>use it and at least some means to determine if a secure call is being
>>spoofed.  The good alternatives involve third-party or device (e.g.
>>sim card) infrastructure such as SIP Identity. In the absence of such
>>infrastructure, it is a poor security solution in which a user cannot
>>even tell if their call security has been subverted.
>>    
>>
>
>Absolutely we agree on that.  If someone wants to make a secure call they
>can feel free to use s/mime or better, plus zrtp, plus speak in pig-latin.
>They can do whatever they wish.  Just don't expect the signaling to flow
>through most service providers for s/mime, that's all. (and by that I mean
>don't expect it to be sip-forwarded through all of their sip infrastructure
>- it will probably work transparently through/across their IP network)  Zrtp
>may work through it in some cases, some cases not.
>  
>
Last week at the IETF, Phil made an excellent argument in his 
presentation that the encryption of media is none of the business of a 
the signaling.  From an architectural point of view, tying the 
encryption of media to the signaling is a bad idea.

>  
>
>>SRTP will only work inside an environment in which all the phones are
>>changed to use SRTP.  Obviously, some parts of the environment must
>>be changed.  Perhaps your point is that there are some parts of the
>>environment that are too hard to change.  Why not say that?
>>    
>>
>
>All I meant was that you said you heard s/mime was not deployable - to which
>I said if you want to get it through a service-provider's sip
>infrastructure, it won't work.  Since the user has no power to change that,
>other than not using service providers, their change of environment to
>s/mime is not that useful. (Since it is probably the call through the
>service-provider they're worried about the most)
>
>But yes, I definitely think there are some parts of the environment that are
>practically impossible to change, to meet the needs/wants of everyone.
>  
>
Users are going to demand confidentiality in their media sessions.  If a 
service provider deploys an architecture in which they can not support 
this, they will loose users to another service provider who has been 
smart enough to use an architecture that allows end-to-end media encryption.

> 
>  
>
>>If you are going to rely on sips for security, then you need to
>>explain how one can control or even detect which proxies handle the
>>calls, at minimum.  I haven't heard such an explanation.  
>>    
>>
>
>There is no way to detect the proxies or control them (part of the point is
>their owners don't want you to).  You have to trust the owner.  If you don't
>trust them, then I don't know why you'd want to use them.
>
>  
>
>>The reason
>>that we have several new proposals for voip key management is because
>>sips alone is not considered to be good enough security for
>>establishing secure voice calls.
>>    
>>
>
>I don't think that's the only reason. Or at least I hope that's not the
>reason. (otherwise there should only be one other mechanism, as opposed to
>11 different ones)  Dan Wing's summary table slide at the IETF put it very
>succinctly I think.  Each has pro's/con's. 
>  
>
Most of the new proposals (except a few that focus on small problems 
with the existing mechanisms) have a common theme in that they perform 
the key management in-band instead of the signaling.  Purely 
signaling-based approaches have been shown not work. 

>I was only referring to the one that in my opinion has the best chance of
>widespread use. (which in my opinion is one that will work through the most
>service-provider sip infrastructures - but other opinions will vary, and
>some people would prefer it not work through service-providers at all)
>  
>
>-hadriel
>
>
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>  
>