RFC Errata System
2010-11-04 10:55:25 UTC
The following errata report has been submitted for RFC5479,
"Requirements and Analysis of Media Security Management Protocols".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5479&eid=2602
--------------------------------------
Type: Technical
Reported by: Fabio Pietrosanti <***@pietrosanti.it>
Section: A.5.2
Original Text
-------------
SDP Security Descriptions with SIPS
Not applicable; SDP Security Descriptions does not have a long-
term secret.
Corrected Text
--------------
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.
Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.
--------------------------------------
RFC5479 (draft-ietf-sip-media-security-requirements-09)
--------------------------------------
Title : Requirements and Analysis of Media Security Management Protocols
Publication Date : April 2009
Author(s) : D. Wing, Ed., S. Fries, H. Tschofenig, F. Audet
Category : INFORMATIONAL
Source : Session Initiation Protocol
Area : Real-time Applications and Infrastructure
Stream : IETF
Verifying Party : IESG
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.
"Requirements and Analysis of Media Security Management Protocols".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5479&eid=2602
--------------------------------------
Type: Technical
Reported by: Fabio Pietrosanti <***@pietrosanti.it>
Section: A.5.2
Original Text
-------------
SDP Security Descriptions with SIPS
Not applicable; SDP Security Descriptions does not have a long-
term secret.
Corrected Text
--------------
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.
Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.
--------------------------------------
RFC5479 (draft-ietf-sip-media-security-requirements-09)
--------------------------------------
Title : Requirements and Analysis of Media Security Management Protocols
Publication Date : April 2009
Author(s) : D. Wing, Ed., S. Fries, H. Tschofenig, F. Audet
Category : INFORMATIONAL
Source : Session Initiation Protocol
Area : Real-time Applications and Infrastructure
Stream : IETF
Verifying Party : IESG
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.