Subject: [Sipping] Errata report on errata 2123 through 2126 on RFC5479 ("Requirements and Analysis of Media Security Management Protocols")

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 28 Dec 2010 20:37:55 -0500

======================================================================
RFC5479, "Requirements and Analysis of Media Security Management Protocols"
Source of RFC: sip (rai)

Errata ID: 2123

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-04-05

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!
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update
======================================================================
RFC5479, "Requirements and Analysis of Media Security Management Protocols"
Source of RFC: sip (rai)

Errata ID: 2124

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-04-05

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!
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update
======================================================================
RFC5479, "Requirements and Analysis of Media Security Management Protocols"
Source of RFC: sip (rai)

Errata ID: 2125

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-04-05

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!
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update

Given the terminology in RFC 3711 ("SRTP") section 3.2, a better
phrase would be "determined by" -- an SRTP security context is
*identified* by these data but *contains* the various crypto
parameters.
======================================================================
RFC5479, "Requirements and Analysis of Media Security Management Protocols"
Source of RFC: sip (rai)

Errata ID: 2126

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-04-05

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.
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update

Although "opportunistic" may be a good choice in this situation.
======================================================================

Dale