Search RFCs

RFC Editor

Found 5 records.

Status:Verified (2)

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

Note: This RFC has been updated byRFC 8946

Errata ID:5715
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Lee
Date Reported: 2019-05-01
Verifier Name: Orie Steele
Date Verified: 2024-11-15

Section 4.1 says:

o  Second, the JSON "dest" array MUST be populated.  If the   destination identity is a telephone number, then the array MUST be   populated with a JSON object containing a "tn" element with a   value set to the value of the quoted destination identity, a   canonicalized telephone number (see Section 8.3).  Otherwise, the   array MUST be populated with a JSON object containing a "uri"   element, set to the value of the addr-spec component of the   To header field, which is the AoR to which the request is being   sent, per the procedures in Section 8.5.  Multiple JSON objects   are permitted in "dest" for future compatibility reasons....The "orig" and "dest" arrays may contain identifiers of heterogeneoustype; for example, the "orig" array might contain a "tn" claim, whilethe "dest" contains a "uri" claim.  Also note that in some cases, the"dest" array may be populated with more than one value.  This could,for example, occur when multiple "dest" identities are specified in ameshed conference.  Defining how a SIP implementation would alignmultiple destination identities in PASSporT with such systems is leftas a subject for future specifications.

It should say:

o  Second, the JSON "dest" object MUST be populated.  If the   destination identity is a telephone number, then the object MUST   contain a "tn" element with a value set to an array containing the   value of the quoted destination identity, a   canonicalized telephone number (see Section 8.3).  Otherwise, the   object MUST contain a "uri" element, set to an array containing   the value of the addr-spec component of the   To header field, which is the AoR to which the request is being   sent, per the procedures in Section 8.5.  Additional elements   are permitted in "dest" for future compatibility reasons....The "orig" and "dest" objects may contain identifiers of heterogeneoustype; for example, the "orig" object might contain a "tn" claim, whilethe "dest" contains a "uri" claim.  Also note that in some cases, the"dest" object may be populated with more than one claim, and its claimvalue arrays may contain more than one value.  This could,for example, occur when multiple "dest" identities are specified in ameshed conference.  Defining how a SIP implementation would alignmultiple destination identities in PASSporT with such systems is leftas a subject for future specifications.

Notes:

The description of the "dest" element does not match RFC8225 or the example that is provided in this section.

The terminology is a bit less clear than in RFC8225 section 5.2.1, in that no differentiation is made between the top level "claims" and embedded "identity claims". The proposed correction does not address this lack of clarity, however.

From RFC8225 section 5.2.1:

The "dest" claim is a JSON object with the claim name of "dest" and
MUST have at least one identity claim object. The "dest" claim value
is an array containing one or more identity claim JSON objects
representing the destination identities of any type (currently "tn"
or "uri"). If the "dest" claim value array contains both "tn" and
"uri" claim names, the JSON object should list the "tn" array first
and the "uri" array second. Within the "tn" and "uri" arrays, the
identity strings should be put in lexicographical order, including
the scheme-specific portion of the URI characters.

(The above text might need correction as well, because it refers to the '"dest" claim value array'.)

Errata ID:6499
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marc Petit-Huguenin
Date Reported: 2021-03-27
Verifier Name: Orie Steele
Date Verified: 2024-11-15

Section 4 says:

Identity = "Identity" HCOLON signed-identity-digest SEMI          ident-info *( SEMI ident-info-params )signed-identity-digest = 1*(base64-char / ".")ident-info = "info" EQUAL ident-info-uriident-info-uri = LAQUOT absoluteURI RAQUOTident-info-params = ident-info-alg / ident-type /    ident-info-extensionident-info-alg = "alg" EQUAL tokenident-type = "ppt" EQUAL tokenident-info-extension = generic-parambase64-char = ALPHA / DIGIT / "/" / "+"

It should say:

Identity = "Identity" HCOLON signed-identity-digest SEMI          ident-info *( SEMI ident-info-params )signed-identity-digest = 1*(base64url-char / ".")ident-info = "info" EQUAL ident-info-uriident-info-uri = LAQUOT absoluteURI RAQUOTident-info-params = ident-info-alg / ident-type /    ident-info-extensionident-info-alg = "alg" EQUAL tokenident-type = "ppt" EQUAL tokenident-info-extension = generic-parambase64url-char = ALPHA / DIGIT / "-" / "_"

Notes:

RFC 8225 makes it clear that the encoding is BASE4URL, not the standard BASE64 encoding.

See also:
- https://datatracker.ietf.org/doc/html/rfc8224#section-4.1.1
- https://datatracker.ietf.org/doc/html/rfc7515#appendix-F
- https://datatracker.ietf.org/doc/html/rfc7515#appendix-C
- https://datatracker.ietf.org/doc/html/rfc4648#section-5

Status:Held for Document Update (2)

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

Note: This RFC has been updated byRFC 8946

Errata ID:5391
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Invalid content for "iat"
Date Reported: 2018-06-14
Held for Document Update by: Orie Steele
Date Held: 2024-11-15

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.

See related: https://www.rfc-editor.org/errata/eid5392

Errata ID:6519
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Roman Shpount
Date Reported: 2021-04-06
Held for Document Update by: Murray Kucherawy
Date Held: 2023-03-29

Section 4 says:

ident-type = "ppt" EQUAL token

It should say:

ident-type = "ppt" EQUAL DQUOTE token DQUOTE

Notes:

Based on IETF 101 STIR notes ptr= values should always be quoted. Also, ATIS-1000074 is using double quotes around ppt value.

[AD note] See the minutes of the STIR WG at IETF 116, and https://datatracker.ietf.org/doc/minutes-interim-2021-stir-01-202104141600/.

Status:Rejected (1)

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

Note: This RFC has been updated byRFC 8946

Errata ID:5390
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Invalid restriction on when to add "mky"
Date Reported: 2018-06-14
Rejected by: Orie Steele
Date Rejected: 2024-11-15

Section 12.1 says:

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

It should say:

When signing a request that contains a fingerprintof 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.
--VERIFIER NOTES--

Report New Errata