RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Reported (2)

RFC 8224, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", February 2018

Source of RFC: stir (art)

Errata ID: 5390
Status: Reported
Type: Technical

Reported By: Invalid restriction on when to add "mky"
Date Reported: 2018-06-14

Section 12.1 says:

When signing a request that contains a fingerprint of keying material
in SDP for DTLS-SRTP [RFC5763], this mechanism always provides a
signature over that fingerprint. 

It should say:

When signing a request that contains a fingerprint
of keying material in SDP, this mechanism always 
provides a signature over that fingerprint. 

Notes:

Attack vector described in 12.1 to justify addition of "mky" is applicable for scenarios, where a fingerprint in SDP is used for reasons other than DTLS-STRP as well.
Use of fingerprint for MSRP per RFCRFC4975 is an example of this.

From RFC4975:

14.4. Using TLS in Peer-to-Peer Mode

TLS can be used with a self-signed certificate as long as there is a
mechanism for both sides to ascertain that the other side used the
correct certificate. When used with SDP and SIP, the correct
certificate can be verified by passing a fingerprint of the
certificate in the SDP and ensuring that the SDP has suitable
integrity protection. When SIP is used to transport the SDP, the
integrity can be provided by the SIP Identity mechanism [17]. The
rest of this section describes the details of this approach.

Errata ID: 5391
Status: Reported
Type: Technical

Reported By: Invalid content for "iat"
Date Reported: 2018-06-14

Section 4.1 says:


      Third, the JSON key "iat" MUST appear.  The authentication service
      SHOULD set the value of "iat" to an encoding of the value of the
      SIP Date header field as a JSON NumericDate (as UNIX time, per
      [RFC7519], Section 2), though an authentication service MAY set
      the value of "iat" to its own current clock time.  If the
      authentication service uses its own clock time, then the use of
      the full form of PASSporT is REQUIRED.  In either case, the
      authentication service MUST NOT generate a PASSporT for a SIP
      request if the Date header is outside of its local policy for
      freshness (sixty seconds is RECOMMENDED).

It should say:

“4.1 PASSPorT Construction”:

Third, the JSON key "iat" MUST appear. 
The authentication service SHOULD set the 
value of "iat" to an encoding of the value of 
JWT generation as a JSON NumericDate 
(as UNIX time, per [RFC7519], Section 2).

Notes:

RFC7519 JSON Web Token (JWT)

4.1.6. "iat" (Issued At) Claim

The "iat" (issued at) claim identifies the time at which the JWT was
issued. This claim can be used to determine the age of the JWT. Its
value MUST be a number containing a NumericDate value. Use of this
claim is OPTIONAL.

This text clearly states that “iat” is for the generation time of JWS.

One may argue that origination of SIP dialog - on which Date header content is based - and JWT generation times would be very close to each other but this is not always true. JWT, for example, can be added only at administrative boundaries and a session may have started long before that,e .g. it involves user interaction with an IVR for announcement/PIN verification.

It should be noted that populating "iat" with JWT issuance time makes use of complete form mandatory. So, if this errata is accepted, there probably would be a need to remove compact form as an option.

Report New Errata