Subject: Re: [MMUSIC] Optional SRTP?

From: Cullen Jennings <[email-masked]>
Date: Sat, 01 Apr 2006 09:55:51 -0800

Hi Rick - this is an important problem and it needs to be solved. There are
a lot of proposal but certainly no solutions yet.

On 3/30/06 9:23 AM, "Alan Johnston" <[email-masked]> wrote:

> Another bad alternative is to offer a secure SDP offer first, and then
> if it fails, send a second insecure SDP offer.

As has been pointed out before, one of the downsides of this is, if your
voicemail system supports SRTP, and your phone does not. This guarantees
that callers that do SRTP will only be able to get voicemail.

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Rick Porter" <[email-masked]>
Date: Wed, 5 Apr 2006 12:54:51 -0400

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.  

Thanks,
Rick

-----Original Message-----
From: Alan Johnston [mailto:[email-masked]] 
Sent: Wednesday, April 05, 2006 9:51 AM
To: Rick Porter
Cc: [email-masked]
Subject: Re: [MMUSIC] Optional SRTP?

Rick,

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.

Thanks,
Alan

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?
>
>Cheers,
>Rick
>
>

---

From: "Wayne Mills \(wmills\)" <[email-masked]>
Date: Wed, 5 Apr 2006 13:03:37 -0400

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.

Regards,
Wayne

> From: Rick Porter [mailto:[email-masked]] 
> Sent: Wednesday, April 05, 2006 12:55 PM
> To: [email-masked]
> 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.  
> 
> Thanks,
> Rick
> 
> 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.
> 
> Thanks,
> Alan
> 
> 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: 
> >
> >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.
> >
> >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 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?
> >
> >Cheers,
> >Rick
> >
> >