Re: [Sip] Errata report on errata 2602 and 2120 on RFC 5479, "Requirements and Analysis of Media Security Management Protocols"

[Cullen Jennings <[e-mail]>]

I agree with the Recommended status on these. Might be good to run the first one by EKR. 

On Dec 13, 2010, at 3:09 PM, Worley, Dale R (Dale) wrote:

> ======================================================================
> RFC5479, "Requirements and Analysis of Media Security Management Protocols"
> Source of RFC: sip (rai)
> 
> Errata ID: 2602
> 
> Status: Reported
> Type: Technical
> 
> Reported By: Fabio Pietrosanti
> Date Reported: 2010-11-04
> 
> Section A.5.2 says:
> 
>      SDP Security Descriptions with SIPS
>         Not applicable; SDP Security Descriptions does not have a long-
>         term secret.
> 
> It should say:
> 
>      SDP Security Descriptions with SIPS
>         The PFS feature of SDP Security Description with SIPS rely on
>         TLS and the availability or not of PFS for SRTP calls depends
>         on the negotiated TLS key negotiation algorithm.
> 
>         If the selected TLS key negotiation algorithm of SIPS provide
>         PFS feature, then the underlying SRTP encryption will support
>         PFS.  For example TLS_DHE_RSA_WITH_AES_256_CBC_SHA provde PFS
>         feature as described in RFC5246.  If the selected TLS key
>         negotiation algorithm of SIPS does not provide PFS feature,
>         then the underlying SRTP encryption will not support PFS.
>         For example TLS_RSA_WITH_AES_256_CBC_SHA does not provide PFS
>         feature as described in RFC5246.
> 
> 
> Notes:
> 
> It's not true that SDP Security Descriptions with SIPS have PFS "Not
> applicable" because the SDES rely on TLS that is part of the security
> scheme.
> 
> Practically if the long terms keys (the x509v3 RSA key of SIPS server)
> is compromised, the TLS sessions can be decrypted, the SDES key
> extracted and SRTP calls deciphered.
> 
> TLS support key exchange methods that provide PFS trough the use of
> Ephemeral Diffie Hellman keys.
> 
> When SIPS use TLS with DHE key negotiation, then SDES acquire PFS
> feature because even in case of long-term key compromise (the server
> x509v3 RSA key), the short term keys (the SDES keys exchanged) will be
> safe.
> ----------------------------------------------------------------------
> Recommended status:  (correct) Verified (publish)
> Should be reviewed by a security expert.
> 
> It seems that the entry for "SDP Security Descriptions with S/MIME" is
> also incorrect, as revelation of the private keys of the participants
> will render the SDES readable.  I think better phrasing of the revised
> wording is:
> 
>      SDP Security Descriptions with SIPS
>         PFS if the selected TLS cipher suites for the SIPS hops provide PFS.
> 
>      SDP Security Descriptions with S/MIME
>         No PFS.
> 
> This needs to be reviewed by a security expert.
> ======================================================================
> RFC5479, "Requirements and Analysis of Media Security Management Protocols"
> Source of RFC: sip (rai)
> 
> Errata ID: 2120
> 
> Status: Reported
> Type: Editorial
> 
> Reported By: Alfred Hoenes
> Date Reported: 2010-04-05
> 
> Section 4.4,3rd para says:
> 
> |  A typical case of using media security where two entities are having
>   a Voice over IP (VoIP) conversation over IP-capable networks.
>   [...]
> 
> It should say:
> 
> |  A typical case of using media security is where two entities are
>   having a Voice over IP (VoIP) conversation over IP-capable networks.
>   [...]
> 
> Notes:
> 
> Rationale: missing verb.
> ----------------------------------------------------------------------
> Recommended status:  (correct) Hold for document update
> ======================================================================
> 
> Dale
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use [e-mail] for questions on how to develop a SIP implementation.
> Use [e-mail] for new developments on the application of sip.
> Use [e-mail] for issues related to maintenance of the core SIP specifications.