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

[Matt Lepinski <[e-mail]>]

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