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

Alissa Cooper <alissa@cooperw.in> Wed, 21 September 2016 01:43 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733E512B097 for <stir@ietfa.amsl.com>; Tue, 20 Sep 2016 18:43:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=3C2pSIU4; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=eAF3QCax
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRb2mupJzalL for <stir@ietfa.amsl.com>; Tue, 20 Sep 2016 18:43:38 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1E3127076 for <stir@ietf.org>; Tue, 20 Sep 2016 18:43:37 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 61E34205D7 for <stir@ietf.org>; Tue, 20 Sep 2016 21:43:37 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 20 Sep 2016 21:43:37 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ugDbSlZ2hwOU3KkE3kEyS6ZMSyc=; b=3C2pSI U4aNB1MHdRhykb33gLaBn4EHEf0YEsIOhX5c9E4qcZ0DH6riKAr8b6UZ5wfFgRS7 gjKJTJLJzirV2WXRryduHrcIxv3NpcX1gelyNKWXCclgG/3/lO3l4Ki+XOMlcgp1 SSg5Ht4leO3v3121s6bnS5e/mQCHVxCCNc+bk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ugDbSlZ2hwOU3Kk E3kEyS6ZMSyc=; b=eAF3QCaxWQ54KBxZcD791BElzOHjmmADuItU/XryFgGDcZ+ jPWhXv+2oQp6CkYgzYNocYXK2kZE2bia4Af4PAvpYPWuc2ztLoov1RNZr/CIdAy4 97hpUDlFmpd1BP5K1J67ETCyd9A6U7rFNJ4MqTuHgvmONSIHFCfegDAXrl38=
X-Sasl-enc: VGcnnOQDlH/oBofmdZlEly/e5jVN7viMVamvOdSX/8fh 1474422216
Received: from [10.24.25.193] (unknown [128.107.241.174]) by mail.messagingengine.com (Postfix) with ESMTPA id AA017F29CD for <stir@ietf.org>; Tue, 20 Sep 2016 21:43:36 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <20388E22-CF03-4338-954B-B9BAFA33C4AF@vigilsec.com>
Date: Tue, 20 Sep 2016 21:43:35 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F26F994-AE94-4C6E-B9F7-D5E6576E423E@cooperw.in>
References: <20388E22-CF03-4338-954B-B9BAFA33C4AF@vigilsec.com>
To: IETF STIR Mail List <stir@ietf.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/Y7dvC98rZWd-UWJZ6LpYOfkFk4c>
Subject: Re: [stir] Second WG Last Call for PASSporT Document
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2016 01:43:40 -0000

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 <housley@vigilsec.com> wrote:
> 
> 
> 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
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir