Dan,
Thanks for moving quickly towards a -01 version of the draft.
I couple of comments R23, R24, and R25:
For reference in this response, R23, R24, and R25 are:
R23: The media security key management protocol SHOULD support
recording of decrypted media.
Media recording may be realized by an intermediate nodes. An
example for those intermediate nodes are devices, which could
be used in banking applications or for quality monitoring in
call centers. Here, it must be ensured, that the media
security is ensured by the intermediate nodes on the
connections to the involved endpoints as originally
negotiated. The endpoints need to be informed that there is
an intermediate device and need to cooperate. A solution
approach for this is described in [I-D.wing-sipping-srtp-key].
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.
[MBL]: I understand the need for media recording (with the concent and
cooperation of the end-point) in many environments. However, it is not
clear to me that the media security key management protocol is the right
place to solve the media recording problem. That is, regardless of which
key management protocol I use between the endpoints, each endpoint is
going to end up with the SRTP key. Once an endpoint who consents to
media recording has the SRTP key, he can use a separate mechanism to
support media recording. My fear is that integrating the media recording
as part of the key management protocol will add significant complexity
to the key management protocol to solve a problem that could easily be
solved with a separate protocol mechanism.
R24: The media security key management protocol SHOULD NOT allow
end users to determine whether their end-to-end interaction is
subject to lawful interception.
I agree R24 refers to lawful intercept. This is a requirement from
other SDOs that need to provide lawful intercept with their solutions.
[MBL]: I understand that other SDOs have requirements for lawful
intercept. However, my understanding from reading RFC 2804 is that the
IETF does not include such requirements in its documents.
Another email on R24 lawful intercept will be forthcoming shortly.
R25: The media security key management protocol MUST work when
there are intermediate nodes, terminating or processing media,
between the end points."
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.
[MBL]: I am confused by this requirement. Clearly, in many environments
SBCs (and other intermediate nodes) are used to terminate and process
media (e.g. to translate between two different codecs). However, in any
environment where an intermediate node is processing the media, there is
no way that end-to-end security of media can be achieved. (Indeed, from
a security point of the view, the intermediate node who that processes
the media stream is playing the role of a man-in-the-middle.) Therefore,
I'm not sure what R25 is trying to require.
_______________________________________________
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
