headers
Cullen Jennings | 1 Apr 2006 19:55
Picon
Favicon
Gravatar

Re: Optional SRTP?


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" <alan <at> sipstation.com> 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.
Permalink | Reply | 0 comments |
headers
Colin Perkins | 4 Apr 2006 19:25

Re: I-D ACTION:draft-ietf-mmusic-fec-grouping-03.txt

On 21 Mar 2006, at 20:50, Internet-Drafts <at> ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Multiparty Multimedia Session  
> Control Working Group of the IETF.
>
> 	Title		: Forward Error Correction Grouping Semantics in Session  
> Description Protocol
> 	Author(s)	: A. Li
> 	Filename	: draft-ietf-mmusic-fec-grouping-03.txt
> 	Pages		: 7
> 	Date		: 2006-3-21
> 	
> This document defines the semantics that allows for grouping of
>    forward error correction (FEC) streams with the protected payload
>    streams in Session Description Protocol (SDP). The semantics  
> defined
>    in this document is to be used with Grouping of Media Lines in the
>    Session Description Protocol (RFC 3388) to group together "m" lines
>    in the same session.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-fec- 
> grouping-03.txt

Re-reading this, I noticed a bug in the SDP example (section 4.3).  
The parity FEC codes use the "application" media type, but should  
match the media they are protecting:

        v=0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hadriel Kaplan | 4 Apr 2006 20:05
Favicon

Media security choices mailing list?

I apologize if this has been answered previously, but is there a mailing list for the multiple-choice SRTP (and ZRTP) discussion?  I thought I heard there would be when I listened to the audio-cast of the Dallas meeting, but I haven’t been able to find it.

Thanks!

-hadriel

 

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 1 comment |
headers
Rick Porter | 5 Apr 2006 15:22

RE: Optional SRTP?

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
Permalink | Reply | 1 comment |
headers
Alan Johnston | 5 Apr 2006 15:50

Re: 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
>
>
>_______________________________________________
>mmusic mailing list
>mmusic <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/mmusic
>
>
>  
>
Permalink | Reply | 0 comments |
headers
Rick Porter | 5 Apr 2006 18:54

RE: 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

-----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?

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
>
>
>_______________________________________________
>mmusic mailing list
>mmusic <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/mmusic
>
>
>  
>
Permalink | Reply | 0 comments |
headers
Wayne Mills (wmills | 5 Apr 2006 19:03
Picon
Favicon

RE: Optional SRTP?

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

> -----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.  
> 
> Thanks,
> Rick
> 
> -----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?
> 
> 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
> >
> >
> >_______________________________________________
> >mmusic mailing list
> >mmusic <at> ietf.org
> >https://www1.ietf.org/mailman/listinfo/mmusic
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>
Permalink | Reply | 0 comments |
headers
Hadriel Kaplan | 5 Apr 2006 21:15
Favicon

RE: Optional SRTP?

Hi Colin,
Was there a consensus to determine a single approach?  I didn't hear it. (I
was on audio-cast, and it was hard to hear)  

Or is the consensus to improve the SDP syntax so that a common mechanism
could be chosen more easily during offer/answer? (if a common one exists)
Assuming negotiation even occurs in SDP.

Or by choosing a "single" approach do you mean choosing signaling handshake
vs. bearer (ZRTP, RTP/DTLS).

-hadriel

> -----Original Message-----
> From: Colin Perkins [mailto:csp <at> csperkins.org]
> Sent: Thursday, March 30, 2006 12:56 PM
> To: Rick Porter
> Cc: Alan Johnston; IETF MMUSIC WG
> Subject: Re: [MMUSIC] Optional SRTP?
> 
> Rick,
> 
> It's important to note that there was a lot of discussion on this
> subject in the MMUSIC and AVT working groups, and the RAI area
> meeting, at the IETF last week. The zrtp draft is one of many
> proposals, and it is by no means clear that there is consensus on any
> single approach.
> 
> Colin
Permalink | Reply | 1 comment |
headers
Colin Perkins | 6 Apr 2006 11:01

Re: Optional SRTP?

Hadriel,

It's clear that a single approach is desirable, rather than multiple  
incompatible solutions, but I don't see any consensus on how to  
proceed yet.

Colin

On 5 Apr 2006, at 20:15, Hadriel Kaplan wrote:
> Hi Colin,
> Was there a consensus to determine a single approach?  I didn't  
> hear it. (I
> was on audio-cast, and it was hard to hear)
>
> Or is the consensus to improve the SDP syntax so that a common  
> mechanism
> could be chosen more easily during offer/answer? (if a common one  
> exists)
> Assuming negotiation even occurs in SDP.
>
> Or by choosing a "single" approach do you mean choosing signaling  
> handshake
> vs. bearer (ZRTP, RTP/DTLS).
>
> -hadriel
>
>
>> -----Original Message-----
>> From: Colin Perkins [mailto:csp <at> csperkins.org]
>> Sent: Thursday, March 30, 2006 12:56 PM
>> To: Rick Porter
>> Cc: Alan Johnston; IETF MMUSIC WG
>> Subject: Re: [MMUSIC] Optional SRTP?
>>
>> Rick,
>>
>> It's important to note that there was a lot of discussion on this
>> subject in the MMUSIC and AVT working groups, and the RAI area
>> meeting, at the IETF last week. The zrtp draft is one of many
>> proposals, and it is by no means clear that there is consensus on any
>> single approach.
>>
>> Colin
>
>
> _______________________________________________
> mmusic mailing list
> mmusic <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 0 comments |
headers
Rick Porter | 6 Apr 2006 14:36

RE: Optional SRTP?

I could not see why a re-INVITE was necessary using the scheme outlined
in the Security Descriptions draft (with possible modification). 

I'm still a ZRTP novice, but I can understand the re-INVITE when doing
ZRTP. However, the re-INVITE to keep signaling informed raises a red
flag about layering. My instinct tells me that if it is important to the
signaling, then the signaling should be driving the train. I still have
many ZRTP discussions to catch up on... 

Thanks,
Rick

-----Original Message-----
From: Wayne Mills (wmills) [mailto:wmills <at> cisco.com] 
Sent: Wednesday, April 05, 2006 1:04 PM
To: Rick Porter; mmusic <at> ietf.org
Subject: RE: [MMUSIC] Optional SRTP?

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
Permalink | Reply | 501 comments |

Gmane