[Sip] Re: Review of draft-ietf-sip-media-security-requirements-00

[Richard Barnes <[e-mail]>]

> Disclosing the SRTP via PUBLISH (option (2)) also creates the same 
> awareness.

Acknowledged.  R24 cannot be satisfied by a protocol with robust 
confidentiality protection, without the cooperation of at least one 
endpoint.  The point of confidentiality protection is to prevent access 
by parties that have not been authorized by the communicants to receive 
access -- and that's exactly what R24 requires.

Conversely, if you want to satisfy R24 with a secure protocol, you need 
at least one endpoint to give access to the communications.  That's not 
a problem for the security protocol to solve; it's more in the domain of 
regulation.

> Not necessarily.  It could be accomplished with DTLS-SRTP with two
> DTLS handshakes, like this diagram:

Here, let me re-label that:

>    endpoint         man-in-the-middle          remote endpoint
>       |                     |                     | 
>       |                     |<-----make keys----->|
>       |<-----make keys----->|                     |

Your diagram is exactly a man-in-the-middle attack, just with a special 
middleman.  So if you allow the above functionality, either the protocol 
can't detect MitM attacks or it can't provide end-to-end authentication.

> There are two SRTP keys (A and B), and the middlebox would need
> to decrypt SRTP and re-encrypt SRTP.  I expect this is not terribly
> desirable due to the computational effort to decrypt and re-encrypt
> the SRTP traffic.

I don't how to transcode encrypted media without decrypting and 
re-encrypting.  I think this is more or less a trade-off you have to accept.

> But I'm trying to step back and ensure that it meets with everyone's
> requirements regarding recording (for banks, stock brokers, etc.), 
> and transcoding (compressed codecs to 'standard' codecs).  I don't
> yet have a message flow for how draft-wing-sipping-srtp-key would
> work well with transcoding; what I have sketched out is far 
> uglier (more messages) than what everyone does for RTP transcoding 
> today.

I'm not sure why you would think that things would be the same as for 
RTP transcoding.  You already have to have a transcoder that does crypto 
(unless there are techniques I'm not aware of).  And there's really only 
one more message to the flow (at least conceptually; two if you include 
a response) for the endpoint to deliver key to the middlbox.  For a 
simple case, just have the middlebox act as the presence server in 
draft-wing-sipping-srtp-key:

UAC         middlebox         UAS
  |              |              |
  |<-------establish keys------>|
  |---PUBLISH--->|              |
  |<----200------|              |
  |              |              |

Again here, UAC compliance is not an issue, since presumably the UAC 
wants the services of the middlebox in order for his call to go through. 
  The single major issue is latency, but since we're talking 1-2 UDP 
messages, that seems like it's about as small as you're going to get. 
Any smaller, and you'd have to communicate with the middlebox via a key 
negotiation message, which really dirty protocol design, and doesn't 
save much (it just makes the keying message bigger/slower).

So, in conclusion:
-- R24 is incompatible with secure operation, and
-- Out-of-band mechanisms seem sufficient for other requirements
-- Ergo, R23-35 don't belong in this document

--Richard




> -d
> 
>> --Richard
>>
>>
>>> R23 refers only to recording of media.  This is necessary in many 
>>> business environments such as banks, stock brokers, catalog 
>> ordering call
>>> centers, and so on.  This is a requirement for many businesses.  It
>>> is not yet clear if draft-wing-sipping-srtp-key (or 
>> something like it) 
>>> meets requirement R23.
>> It seems like does, provided that (1) endpoints are willing 
>> to send key 
>> to authorized listeners, and (2) the delay induced by SIP is 
>> tolerable. 
>>   Both of these would seem to be true in the enterprise 
>> environments you 
>> describe.
>>
>>> I agree R24 refers to lawful intercept.  This is a requirement from
>>> other SDOs that need to provide lawful intercept with their 
>> solutions.
>>> Another email on R24 lawful intercept will be forthcoming shortly.
>>> R25 reference to 'intermediate nodes' is to transcoders and 
>> SBCs which
>>> handle signaling and media traffic.  It seems important 
>> that any keying
>>> mechanism work with such intermediate nodes, as those 
>> intermediate nodes
>>> are common on many SIP networks.
> 
> 



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