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

[Russ Housley <housley@vigilsec.com>]

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?

  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.

  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.

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

  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.