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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
