Subject: [stir] Second WG Last Call for PASSporT Document

From: Russ Housley <[email-masked]>
Date: Sat, 10 Sep 2016 12:04:11 -0400

A revised document to address the issues raised in the first WG Last Call
on this document was posted yesterday.
(https://www.ietf.org/id/draft-ietf-stir-passport-07.txt).

This message starts a second two-week WG Last Call for this document,
which will end on 24 September 2016.

Please review the document and send comments on it to the STIR WG mail
list.  Please clearly state your opinion as to whether the document is
ready for publication as a standards-track RFC.  Remember that support
for publication is needed, so if you think the document is ready to go
forward, please say so.

Thanks,
Russ & Robert

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 20 Sep 2016 21:43:35 -0400

I did my AD review of this document early to try to expedite the process.

Substantive comments and questions:

= Section 3.2 =

I have some suggested changes below which I think more accurately reflect the intent of the WG as regards algorithm support. But if I'm incorrect, let's discuss.

OLD 
For the creation and verification of PASSporT tokens and their digital signatures ES256 MUST be implemented as defined in JWA Section 3.4

Note that JWA defines other algorithms that may be utilized or updated in the future depending on cryptographic strength requirements guided by current security best practice.

NEW 
For the creation and verification of PASSporT tokens and their digital signatures, implementations MUST support ES256 as defined in JWA Section 3.4. Implementations MAY support other algorithms registered in the JSON Web Signature and Encryption Algorithms registry created by RFC 7518. The contents of that registry may be updated in the future depending on cryptographic strength requirements guided by current security best practice. The mandatory-to-support algorithm for PASSporT tokens may likewise be updated in future updates to this document.

= Section 4.1.1 =

"As defined this should be set to the date and time of the origination of the personal communications."

Actually, as defined in RFC 7519 this should be set to the time the JWT is issued. I think that is all that needs to be said here.

= Section 7 =

I suggest the edit below, but note that it modifies the way the normative MUST is to be interpreted. Does this match the intent of the existing language?

OLD 
In order to make the digital signature verification work deterministically, the JSON representation of the PASSporT Header and Claims, particularly if PASSporT is used across multiple signaling environments, specifically the JWS Protected Header object and JWS Payload object MUST be computed as follows.

NEW 
In order to make the digital signature verification work deterministically, the JSON representation of the PASSporT header and claims MUST be computed as follows.

= Section 8 =

I think the security considerations need a different approach. Passport tokens themselves do not provide defenses against replay or violations of confidentiality or integrity. That is natural, as all that is being specified is a format. The consequence of this is that those defenses, to the extent they can be made available, need to be built into the ways that applications make use of the tokens. I think this should be stated up front and I think the requirements on applications making use of passport tokens should be clearly listed and described with normative language.

For example, I would think that at least some of the recommendations in 8.1 and 8.3 could be normative recommendations on applications: a PASSporT token SHOULD only be sent together with application data fields that correspond directly to fields in the token and MUST NOT be used by applications to expose identifiers or other communications details that the application does not otherwise already expose.

= Section 8.2 =

"However, applications that use PASSporT should ensure the signer is in an authoritative position to represent the user and authenticate the user onto the communications network and should be the responsible party for protecting the destination party from potential identity spoofing in addition to other abuse of the communications network outside of PASSporT."

This sounds like a rather hefty set of requirements to levy on applications, especially if this is interpreted as a set of requirements to be implemented programmatically (although "should be the responsible party" is I guess clearly not a programmatic requirement). Perhaps what you're aiming for here is, instead, that operators of implementations that are verifying passport tokens should have some means of verifying that signers are authoritative, possibly automated but possibly not? I would recommend dropping the clause about the responsible party altogether as it seems out of scope for this document.

Nits:

= Abstract =

OLD 
This document defines a canonical string object or 'token' including a digital signature for verifying the author of the token, their authority to author the token and the information asserted in the token, minimally, the originating identity or 'persona' corresponding specifically to the originator of 'personal communications', or signalled communications between a set of parties with identities. The PASSporT token is cryptographically signed to protect the integrity of the identify the originator of a personal communications session (e.g. the telephone number or URI) and verify the assertion of the identity information at the destination.

NEW 
This document defines a method for creating and validating a token that cryptographically verifies an originating identity, or more generally a URI or telephone number representing the originator of personal communications. The PASSporT token is cryptographically signed to protect the integrity of the identity the originator and to verify the assertion of the identity information at the destination.

= Section 1 =

s/for the signing and verification of telephone numbers./for the signing and verification of telephone numbers and SIP URIs./

= Section 3 =

Throughout this section, several of the references to sections of RFC 7518 are not properly encoded, so, for example, a reference which is intended to link to RFC 7518 Section 3.1 is actually referencing Section 3.1 of this document. Please fix these.

s/the following header parameters defined the the next three subsections./the header parameters defined in the next three subsections.

= Section 4 =

s/and be encoded/and are encoded/

= Section 4.2.1 =

s/being called by the caller,/being called by the caller./

s/determined by the application must have the capability/determined by the application need to have the capability

= Section 4.2.1.1 =

Same problem with the section reference as in Section 3.

= Section 4.2.2 =

s/If there are more that one fingerprint/If there is more than one fingerprint/

= Section 7 =

OLD 
JSON, as a canonical format, can include spaces, line breaks and key value pairs can occur in any order and therefore makes it, from a string format, non-deterministic.

NEW 
JSON, as a canonical format, can include spaces and line breaks, and key value pairs can occur in any order. It is therefore a non-deterministic string format.

Alissa

> On Sep 10, 2016, at 12:04 PM, Russ Housley <[email-masked]> wrote:
> 
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Chris Wendt <[email-masked]>
Date: Thu, 29 Sep 2016 21:13:19 -0400

Hi Alissa,

Thanks very much for the review.  I have gone through your comments and noted inline the fixes i have made.

They are reflected in the draft-ietf-stir-passport-08 update.

-Chris

> On Sep 20, 2016, at 9:43 PM, Alissa Cooper <[email-masked]> wrote:
> 

I am ok with this, i think the text appropriate.

> Actually, as defined in RFC 7519 this should be set to the time the JWT is issued. I think that is all that needs to be said here.

Yes will add this.

> In order to make the digital signature verification work deterministically, the JSON representation of the PASSporT header and claims MUST be computed as follows.

Agree it’s a little wordy, we do mention the idea of gatewaying between signaling in the introduction, so i can remove that here.

> For example, I would think that at least some of the recommendations in 8.1 and 8.3 could be normative recommendations on applications: a PASSporT token SHOULD only be sent together with application data fields that correspond directly to fields in the token

I did update this text a bit to clear up the logic including a normative SHOULD

> and MUST NOT be used by applications to expose identifiers or other communications details that the application does not otherwise already expose.

I would probably just remove 8.3, it is admittedly not really stating anything useful, particularly since i added text similar to what you have above that says ONLY include application data fields, so exposing identifier that aren’t already exposed is not possible.

> This sounds like a rather hefty set of requirements to levy on applications, especially if this is interpreted as a set of requirements to be implemented programmatically (although "should be the r…

I’ve reworded this section to hopefully provide better guidance vs. requirements.

> This document defines a method for creating and validating a token that cryptographically verifies an originating identity, or more generally a URI or telephone number representing the originator o…

Fixed.

> Throughout this section, several of the references to sections of RFC 7518 are not properly encoded, so, for example, a reference which is intended to link to RFC 7518 Section 3.1 is actually refer…

Fixed.

> s/the following header parameters defined the the next three subsections./the header parameters defined in the next three subsections.
Fixed.

> s/and be encoded/and are encoded/

Fixed.
> s/being called by the caller,/being called by the caller./
Fixed.
> s/determined by the application must have the capability/determined by the application need to have the capability
Fixed.
> Same problem with the section reference as in Section 3.
I think this is ok, it points to 4474bis section 8.3 which is the intent i believe.
> s/If there are more that one fingerprint/If there is more than one fingerprint/
Fixed.

> JSON, as a canonical format, can include spaces and line breaks, and key value pairs can occur in any order. It is therefore a non-deterministic string format.
Fixed.