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

["Dan Wing" <[e-mail]>]

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

I agree solving the problem within the key management protocol
may not be the right place to solve it.  However, the requirement
to have it solved remains necessary.  I don't know where
else to capture this requirement, and am open to suggestions.

I am co-author of draft-wing-sipping-srtp-key, which proposes
one solution to meet requirement R23, using PUBLISH.

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

That is also my understanding from RFC1984 and RFC2804.

Yet, IETF has stated that it owns SIP standards.  This leaves IETF
in an interesting position which I, as an author, am unable to 
reconcile.

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

Transcoding of media by a device outside of the endpoint.  For
example, a device might be on a bandwidth-constrained link but
due to peering or interoperability requirements (such as those
that are born out of SPEERMINT), it might be necessary for the
initial Invite to offer both the highly-compressed codec and a
'typical' codec for interoperability (say, G.711).  However,
G.711 takes up too much bandwidth for the bandwidth-constrained
link.

Today, this is solvable with RTP, and being done with RTP.

We also want this solvable with SRTP.  It is well-known how
to solve this with Security Descriptions [RFC4568]; what is 
important is to provide solutions for this with other key
management protocols, such as DTLS-SRTP.

I have added "transcoding and SBC" as examples to R25, but if
there is additional wording that would be helpful, please let 
me know; perhaps we should add a section at the top (which we 
have done for some of the more complicated requirements)??

-d


_______________________________________________
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