RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search