RE: Optional SRTP?
Wayne Mills (wmills <wmills <at> cisco.com>
2006-04-05 17:03:37 GMT
If I understand the ZRTP proposal correctly ....
The initial media connection is made with RTP, then the endpoints "upgrade" to SRTP using the media-inband
key exchange suggested by ZRTP, thus SRTP is negotiated outside the call signaling plane. Re-INVITE (by
correcting SDP after the fact) informs the signaling plane that it happened.
> -----Original Message-----
> From: Rick Porter [mailto:rporter <at> covergence.com]
> Sent: Wednesday, April 05, 2006 12:55 PM
> To: mmusic <at> ietf.org
> Subject: RE: [MMUSIC] Optional SRTP?
> Hi Alan,
> Why would you send a re-INVITE if SRTP is established? I
> thought everything you need to know is in the original
> INVITE/OK SDP pair.
> I don't have any strong feelings regarding indication
> requirements. I was afraid that you wanted real-time,
> user-interface indication which is not practical for
> multi-user network devices (e.g. b2bua, media-gateway). I
> agree that good UA's will provide the best indication they
> can to their user.
> -----Original Message-----
> From: Alan Johnston [mailto:alan <at> sipstation.com]
> Sent: Wednesday, April 05, 2006 9:51 AM
> To: Rick Porter
> Cc: mmusic <at> ietf.org
> Subject: Re: [MMUSIC] Optional SRTP?
> ZRTP essentially uses this approach - it uses a normal m=
> media line that any UA can accept and avoids all these failure modes.
> In the past I have proposed that other key management
> techniques could benefit from this as well by permitting the
> crypto and key-mgt attributes in normal m= lines, just as you discuss.
> If the SRTP session is then established, a re-INVITE could be
> sent to change the m= line to indicate that resulting session
> is in fact secure.
> I think any device performing this kind of function needs to
> provide an indication of the secure status of the call (hence
> a MUST), even if it is just a log or other non-real time indication.
> Rick Porter wrote:
> >Thanks for all the responses. I'm fascinated by the
> discussion, as I thought I would be when I asked the
> question. I raised my original question due to a situation I
> encountered in the lab. I have two phones as follows:
> >A - secure (SRTP, possibly TLS)
> >B - non-secure (no TLS or SRTP)
> >When A calls B, B rejects the call because he is not
> configured to accept a secure call (this phone requires TLS
> signaling to do SRTP). Per the SDES draft (Section 5.1.2, top
> of page 10), this is the correct behavior. I found the result
> (B didn't even ring, and call was not completed) to be rather
> unsatisfying. This sounds like a known issue with the current draft.
> >I hate to throw more proposals in the mix, but I have a
> couple thoughts on "simple" changes to the current draft to
> make a more deployable solution. I'm trying to take a simple,
> pragmatic approach that will get this deployed ASAP. It
> sounds like the conditional SDP is not deployed, so I do not
> want to depend on that. Take these proposals with as many
> shakers of salt as you see appropriate.
> >1) Use the same media stream. No special transport. Crypto
> is just another "optional" attribute of the media description.
> >2) Add an "a=encryption" attribute.
> >I believe those suggestions would result in the following
> behavior for the above scenario.
> >B would accept the call, but not provide a crypto attribute
> in the 200/OK/SDP. Then, if A does not like the 200/OK/SDP
> without crypto he can choose to CANCEL the call or continue
> the non-secure call. Based on configuration, phone A may
> prompt the user to accept that it is a non-secure call. B
> already knows that he is not configured to do secure calls,
> so being non-secure is not news to him.
> >In an early draft by Ahmar Ghaffar at Snom, I liked the
> "a=encryption:<optional|mandatory>" attribute that could be
> included as part of the media description. If the encryption
> attribute is present, you know whether you can accept the
> call even if you do not share a common set of crypto
> algorithms/options. It could give the end receiving the
> INVITE the chance to reject the call early (e.g. 480) instead
> of sending the 200/OK (without crypto) and letting the other
> end cancel the call upon receipt of the 200/OK.
> >I know the above scenario is not the only one, so I probably
> missed something...
> >I believe Alan and Paul are correct with respect to not
> being concerned about a bid-down attack. If you have access
> to the signaling stream, then you have access to key material
> necessary to decrypt each and every RTP packet. No need to
> bid it down crypto if you can decrypt the RTP packets anyway.
> Until you do some sort of end-to-end public key exchange
> (e.g. ZRTP), then you don't have end-to-end security. There
> are many technical and political reasons why SRTP is done on
> a hop-by-hop basis--please start another thread if you wish
> to discuss this.
> >I agree that the façade of security is worse than having no
> security. However, I don't think that there should be
> requirements for human notification/intervention in the
> specification--network devices do not typically have a per
> session user interface! IMHO, a "should" would be reasonable,
> but a "must" is too strong. This also becomes sticky when
> dealing with multiple streams that don't all have the same
> security attributes. Additionally, would you display the
> session as secure if it was negotiated with UNENCRYPTED_SRTP
> and UNAUTHENTICATED_SRTP?
> >mmusic mailing list
> >mmusic <at> ietf.org
> mmusic mailing list
> mmusic <at> ietf.org