RE: Evaluation: draft-ietf-mmusic-sdp-new-13

["Peterson, Jon" <jon.peterson@neustar.biz>]

Hi Russ,

Thanks for these helpful notes! A few comments below.

> SDP: Session Description Protocol (Proposed Standard)
> <draft-ietf-mmusic-sdp-new-13.txt>
> 
>    Russ Housley        [   ]     [   ]       [ X ]      [   ]
> 
>    Section 4.3 talks about private sessions.  It says:
> 
>       "The details of how encryption is performed are dependent on the
>       mechanism used to convey SDP - e.g. mechanisms are defined for SDP
>       transported using SAP [RFC2974] and SIP [RFC3261]."
> 
>    Why aren't S/MIME for email and TLS for WWW included here?
> 


As far as I know, no one has proposed using email to carry SDP, but I
suppose this could be included. I agree that TLS for WWW deserves a mention.

>    In section 5, the discussion of encryption keys says:
> 
>       "k=clear:<encryption key>
> 
>        The encryption key is included untransformed in this key field.
>        This method MUST NOT be used unless it can be guaranteed that
>        the SDP is conveyed over a secure channel.
> 
>        k=base64:<encoded encryption key>
> 
>        The encryption key is included in this key field but has been
>        base64 encoded because it includes characters that are
>        prohibited in SDP.  This method MUST NOT be used unless it can
>        be guaranteed that the SDP is conveyed over a secure channel."
> 
>    These restrictions are necessary but not sufficient.  You must also 
> ensure that the secure channel is with the party that is authorized to
join 
> the session, not an intermediary.  If a caching server is used, there
ought 
> to be a way to keep the server from accessing the key.
> 

I agree that this risk is worth mentioning here.

>    Also, it is generally a good idea to indicate the algorithm that a 
> cryptographic key is intended to support.  I suggest that the encryption 
> key type be revised to specify the key as well as the algorithm that the 
> key will be used with.
> 

This is actually underway now as a separate draft:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-00.txt

... but I'd rather not hold up the SDP-new draft to wait for that to
complete. Is that okay?

>    Finally, many security protocols require two keys, one for 
> confidentiality and another for integrity.  This specification does not 
> support the transfer of two keys.

I think the keys specified in the k= line are tooled to the security
protocols that are expected to be used by the sessions set up with SDP (such
as sRTP). sRTP supports a key derivation function based on a master key that
creates separate keys for confidentiality and integrity.

>    In section 6, the document says:
> 
>       "Use of the "k=" field poses a significant security risk, since it
>       conveys session encryption keys in the clear.  SDP MUST NOT be used
>       to convey key material, unless it can be guaranteed that the channel
>       over which the SDP is delivered is both private and authenticated."
> 
>    I agree.  It would therefore be desirable for the "k=" field to support

> two other alternatives.  First, it would be nice to name the key without 
> actually including the key.  In PEM (see RFC 1040), the Recipient-ID was 
> used to name key-encryption keys, and a similar scheme could be employed 
> here.  Second, it would be nice to encrypt the session key in a key that
is 
> not included in SDP.  PEM also includes a mechanism for 
> wrapped symmetric keys.
> 

It is already possible to include a reference to a key rather than the key
itself. As Ted notes in his comments, there is a

         k=uri:<URI to obtain key>

URI-based field that shows where a key can be acquired (presumably that URI
could be something like HTTPS, and indicate a server that performs Digest
authentication and so on).

If SDP is encrypted by S/MIME (the common case for protocols like SIP) then
the entire SDP is encrypted with a session key that is not included in SDP.
This would probably be my preference for providing your second alternative
above.

>