RFC Errata
Found 8 records.
Status: Verified (1)
RFC 5479, "Requirements and Analysis of Media Security Management Protocols", April 2009
Source of RFC: sip (rai)
Errata ID: 2602
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Fabio Pietrosanti
Date Reported: 2010-11-04
Verifier Name: Robert Sparks
Date Verified: 2011-02-21
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.
----
From reviewer Dale Worley:
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.
Status: Held for Document Update (7)
RFC 5479, "Requirements and Analysis of Media Security Management Protocols", April 2009
Source of RFC: sip (rai)
Errata ID: 2120
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks
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.
Errata ID: 2121
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks
Section 5.1 - 5.3 says:
Notes:
Sections 5.1 through 5.3 use unexpected irregular, non-uniform
indentation in hanging lists; this is accompanied by dangling
hyphens in 5.2 ( s/third- party/third-party/ and
s/crypto- agility/crypto-agility/ !).
(Keep for update!)
third- party
Errata ID: 2122
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks
Section App. A says:
[[ second-to-last paragraph, on mid-page 24: ]] Related to SRTP's characteristics is a goal that any SRTP keying | mechanism to also be efficient and not cause additional call setup delay.
It should say:
Related to SRTP's characteristics is a goal that any SRTP keying | mechanism also be efficient and not cause additional call setup delay.
Notes:
Rationale: language/grammar improvement -- keep for update!
Errata ID: 2123
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks
Section A.1.7 says:
[[ second paragraph: ]] With this proposal, the ECDSA signature, MIKEY-ECIES, and MIKEY-ECMQV | function exactly like MIKEY-RSA, and the new DH-Group code function exactly like MIKEY-DHSIGN. Therefore, these ECC mechanisms are not discussed separately in this document.
It should say:
With this proposal, the ECDSA signature, MIKEY-ECIES, and MIKEY-ECMQV | function exactly like MIKEY-RSA, and the new DH-Group code functions exactly like MIKEY-DHSIGN. Therefore, these ECC mechanisms are not discussed separately in this document.
Notes:
Rationale: singular/plural mismatch -- keep for update!
Errata ID: 2124
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks
Section A.1.11 says:
MIKEYv2 [MIKEYv2] adds mode negotiation to MIKEYv1 and removes the time synchronization requirement. It therefore now takes 2 round trips to complete. In the first round trip, the communicating parties learn each other's identities, agree on a MIKEY mode, crypto | algorithm, SRTP policy, and exchanges nonces for replay protection. In the second round trip, they negotiate unicast and/or group SRTP context for SRTP and/or SRTCP.
It should say:
MIKEYv2 [MIKEYv2] adds mode negotiation to MIKEYv1 and removes the time synchronization requirement. It therefore now takes 2 round trips to complete. In the first round trip, the communicating parties learn each other's identities, agree on a MIKEY mode, crypto | algorithm, SRTP policy, and exchange nonces for replay protection. In the second round trip, they negotiate unicast and/or group SRTP context for SRTP and/or SRTCP.
Notes:
Rationale: singular/plural mismatch -- keep for update!
Errata ID: 2125
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks
Section A.4.3 says:
| In SRTP, a cryptographic context is defined as the SSRC, destination | network address, and destination transport port number. Whereas RTP, | a flow is defined as the destination network address and destination transport port number. This results in a problem -- how to communicate the SSRC so that the SSRC can be used for the cryptographic context.
It should say:
| In SRTP, a cryptographic context is defined by the SSRC, destination | network address, and destination transport port number, whereas in RTP, | a flow is defined by the destination network address and destination transport port number. This results in a problem -- how to communicate the SSRC so that the SSRC can be used for the cryptographic context.
Notes:
Rationale: clarification/language improvement -- keep for update!
Errata ID: 2126
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-05
Held for Document Update by: Robert Sparks
Section A.5.3 says:
[[ 4th paragraph: ]] Currently, several techniques are commonly considered as candidates | to provide opportunistic encryption:
It should say:
Currently, several techniques are commonly considered as candidates | to provide best effort encryption:
Notes:
Rationales: consistency with section headline.