errata logo graphic

Found 4 records.

Status: Verified (1)

RFC3329, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", January 2003

Source of RFC: sip (rai)

Errata ID: 3799

Status: Verified
Type: Technical

Reported By: Hadriel Kaplan
Date Reported: 2013-11-13
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-11-14

Section Appendix A says:

spivalue           = 10DIGIT; 0 to 4294967295

It should say:

spivalue           = 1*10DIGIT; 0 to 4294967295

Notes:

The number string does not have to have 10 digit characters if the number is not 10 digits in length.


Status: Held for Document Update (2)

RFC3329, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", January 2003

Source of RFC: sip (rai)

Errata ID: 2169

Status: Held for Document Update
Type: Technical

Reported By: Peter Dawes
Date Reported: 2010-04-23
Held for Document Update by: Robert Sparks

Section 4.1 says:

The 200 OK response (6) for the INVITE and the ACK (7) are also sent
   over the TLS connection.  The ACK will contain the same Security-
   Verify header field as the INVITE (3).

It should say:

The 200 OK response (6) for the INVITE and the ACK (7) are also sent
   over the TLS connection.

Notes:

RFC3329 Section 2.6, Table 1: Summary of Header Usage. indicates that Security-Client, Security-Server, Security-Verify are "Not applicable" to the SIP ACK request.

RFC 3261 says (section 20) "Not applicable" means that the header
field MUST NOT be present in a request. If one is placed in a
request by mistake, it MUST be ignored by the UAS receiving the
request.


Errata ID: 2170

Status: Held for Document Update
Type: Technical

Reported By: Peter Dawes
Date Reported: 2010-04-23
Held for Document Update by: Robert Sparks

Section 4.2 says:

The second INVITE (4) and the ACK (8) contain a Security-Verify
   header field that mirrors the Security-Server header field received
   in the 421.

It should say:

The second INVITE (4) contains a Security-Verify
   header field that mirrors the Security-Server header field received
   in the 421.

Notes:

RFC 3329 Section 2.6, Table 1: Summary of Header Usage. indicates that Security-Client, Security-Server, Security-Verify are "Not applicable" to the SIP ACK request.

RFC 3261 says "Not applicable" means that the header field MUST NOT be present in a request. If one is placed in a request by mistake, it MUST be ignored by the UAS receiving the request."


Status: Rejected (1)

RFC3329, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", January 2003

Source of RFC: sip (rai)

Errata ID: 3800

Status: Rejected
Type: Technical

Reported By: Hadriel Kaplan
Date Reported: 2013-11-13
Rejected by: Richard Barnes
Date Rejected: 2014-02-15

Section Appendix A says:

mech-parameters    = ( algorithm / protocol /mode /
                             encrypt-algorithm / spi /
                             port1 / port2 )
encrypt-algorithm  = "ealg" EQUAL ( "des-ede3-cbc" / "null" )
spi                = "spi" EQUAL spivalue
port1              = "port1" EQUAL port
port2              = "port2" EQUAL port

It should say:

mech-parameters    = ( algorithm / protocol /mode /
                             encrypt-algorithm / spi-c / spi-s /
                             port-c / port-s )
encrypt-algorithm  = "ealg" EQUAL ( "des-ede3-cbc" / 
                             "aes-cbc" / "null" )
spi-c              = "spi-c" EQUAL spivalue
spi-s              = "spi-s" EQUAL spivalue
port-c             = "port-c" EQUAL port
port-s             = "port-s" EQUAL port

Notes:

3GPP 33.203 has different ABNF than the Appendix in this RFC. Note the "spi-c", "spi-s", "port-c", "port-s" parameter names instead of "spi", "port1", or "port2". And a new algorithm token of "aes-cbc" as well.
--VERIFIER NOTES--
The ABNF changes described here would have required substantial changes to the remainder of Appendix A. If the reporter wishes to make this update, he should submit an Internet-draft that updates this RFC.


Report New Errata