Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-06 Glitches

Mike Jones <Michael.Jones@microsoft.com> Mon, 16 November 2015 21:40 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B73B1B31FA for <oauth@ietfa.amsl.com>; Mon, 16 Nov 2015 13:40:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 SIzCmGj0I2Kx for <oauth@ietfa.amsl.com>; Mon, 16 Nov 2015 13:40:46 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EBBD1B31F8 for <oauth@ietf.org>; Mon, 16 Nov 2015 13:40:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rwHZiRKaKrSpk8l448mL7D8xxb4J5jLOcfXUYkFWDlI=; b=nLC3Wori0mLsKg0E0yd8sOOlhHL65l27kr4cge/h0rwBdIuWyQTKu81qJ4H2tQ/MOH7hQRMFzRsUXhQusKYgmkCmoSij1TYGqa5upsTgUIQL2x4wjD91FG7UFZSFxiklan1inoyo8H9/dvFER1F3O5vyNinnmWLEwxZXuPylb5Q=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.325.17; Mon, 16 Nov 2015 21:40:44 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0325.003; Mon, 16 Nov 2015 21:40:44 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-06 Glitches
Thread-Index: AQHRIH79mKZHRXxwvE+48vmOkQX4Rp6fJFzA
Date: Mon, 16 Nov 2015 21:40:43 +0000
Message-ID: <BY2PR03MB4425A1BD990DD8D673BA2A1F51E0@BY2PR03MB442.namprd03.prod.outlook.com>
References: <5649EE61.8060803@gmx.net>
In-Reply-To: <5649EE61.8060803@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-originating-ip: [2001:4898:80e8:2::650]
x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:3H5AERth2kju0wo4jSf+/ll0v8/n5POupIM4Cqo2r99K0gp9ll8bwbugoKkwILWjiF8Bfox22JWEL5LEpWgtyLEDqTwpXQ+Z4/y9f0Z0PdHpDLjZqDvXZ0a+3DddPhmOSvBNWGs+O2tI3J7FrLUh4Q==; 24:v5tKN//20bDqALlWKMXp6VW9ssaak1bwDu57/LPyT7OPj1kojf/DKYt6pxae6WdHzeddRUYXAlioSZk3K8K+zggEyMaEpoK0eF8i0kOh1HI=; 20:TUtdV8eXRtSJ8onH4/jr8+FVT1XfBYyIEB8eNye8PEkxwJj3UzZuZ6lutQi/TyF+6Rd7Sm2uaj3bq16ovBQeeQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444;
x-microsoft-antispam-prvs: <BY2PR03MB4445EE65CFFB135F4CE4378F51E0@BY2PR03MB444.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444;
x-forefront-prvs: 0762FFD075
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(51914003)(43784003)(199003)(189002)(377454003)(13464003)(8990500004)(40100003)(87936001)(11100500001)(2501003)(50986999)(74316001)(122556002)(76576001)(230783001)(102836002)(106356001)(92566002)(5001960100002)(77096005)(54356999)(81156007)(106116001)(19580395003)(15975445007)(97736004)(19580405001)(33656002)(5003600100002)(5005710100001)(10290500002)(76176999)(189998001)(586003)(99286002)(2900100001)(86612001)(2950100001)(101416001)(5008740100001)(5007970100001)(10400500002)(107886002)(86362001)(5001770100001)(5002640100001)(575784001)(10090500001)(105586002)(5004730100002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2015 21:40:43.8608 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/-zDnE68wtPtvxhinws8po71oRIw>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-06 Glitches
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2015 21:40:49 -0000

Hi Hannes.  Thanks for the feedback.  Replies are inline below...

> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes
> Tschofenig
> Sent: Monday, November 16, 2015 6:55 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-06 Glitches
> 
> Hi all,
> 
> I noticed a few glitches with the most recent version of the draft-ietf-oauth-
> proof-of-possession document.
> 
> ** PoP Figure (Symmetric Key)
> 
> FROM:
> 
>      +--------------+
>      |              |                         +--------------+
>      |              |--(4) Presentation of -->|              |
>      |              |      JWT w/ Encrypted   |              |
>      |  Presenter   |      PoP Key            |              |
>      |              |                         |              |
>      |              |<-(5) Communication ---->|              |
>      |              |      Authenticated by   |              |
>      +--------------+      PoP Key            |              |
>        |          ^                           |              |
>        |          |                           |              |
>       (1) Sym.   (3) JWT w/                   |  Recipient   |
>        |  PoP     |  Encrypted                |              |
>        |  Key     |  PoP Key                  |              |
>        v          |                           |              |
>      +--------------+                         |              |
>      |              |                         |              |
>      |              |                         |              |
>      |              |<-(2) Key Exchange for ->|              |
>      |   Issuer     |      Key Encryption Key |              |
>      |              |                         |              |
>      |              |                         |              |
>      |              |                         +--------------+
>      +--------------+
> 
>             Figure 1: Proof-of-Possession with a Symmetric Key
> 
> TO:
> 
>  +--------------+
>  |              |                         +--------------+
>  |              |--(3) Presentation of -->|              |
>  |              |      JWT w/ Encrypted   |              |
>  |  Presenter   |      PoP Key            |              |
>  |              |                         |              |
>  |              |<-(4) Communication ---->|              |
>  |              |      Authenticated by   |              |
>  +--------------+      PoP Key            |              |
>    |          ^                           |              |
>    |          |                           |              |
>   (1) Sym.   (2) JWT w/                   |  Recipient   |
>    |  PoP     |  Encrypted                |              |
>    |  Key     |  PoP Key                  |              |
>    v          |                           |              |
>  +--------------+                         |              |
>  |              |                         |              |
>  |              |                         |              |
>  |              |<=======================>|              |
>  |   Issuer     |    Key Exchange for     |              |
>  |              |    Key Encryption Key   |              |
>  |              |                         |              |
>  |              |                         +--------------+
>  +--------------+
> 
>             Figure 1: Proof-of-Possession with a Symmetric Key
> 
> 
> The reason for this change is that the figure currently included in the
> document gives the impression that the key used to protect the PoP token is
> actually dynamically exchanged in step (2), which isn't the case.
> 
> While text says that it is dynamically established if it does not exist there is
> nothing in this or any document that provides this functionality.
> Hence, I am also suggesting to change the text accordingly:
> 
> FROM:
> 
> This symmetric key is encrypted with a key known only to the issuer and the
> recipient, which is established in step (2), if it doesn't already exist.
> 
> TO:
> 
> This symmetric key is encrypted with a key known only to the issuer and the
> recipient.
> 
> The problem with dynamically establishing keys is that we are then requiring
> yet another key to be in place to allow this procedure to happen securely.
> Without anything in place we are quickly vulnerable to various attacks.
> 
> 
> FROM:
> 
> In the case illustrated in Figure 1, the presenter generates a symmetric key
> and (1) privately sends it to the issuer.
> 
> TO:
> 
> In the case illustrated in Figure 1, the presenter generates a symmetric key
> and in (1) sends it to the issuer. The key transport is confidentiality
> protected.

OK - I can make changes along these lines.  I'll tentatively plan on labelling the key exchange for the key encryption key as (0) in the diagram, and referring to it as such in the text.  I'll send the revised text to you and the other editor for review before publication.

> ** CNF Claim
> 
> I also have a question regarding this paragraph from Section 3.1. What does it
> mean to have other members of the "cnf" claim?

It means that additional methods of confirming the authenticity of the token may be defined in the future.  They will be registered in the JWT Confirmation Methods Registry established in Section 6.2.  As an example, SAML has an IP Address confirmation method.  While I'm not recommending that we define an equivalent confirmation method here, it's an example showing that we haven't covered the complete spectrum of possible confirmation methods.

> What is the semantic of these two examples:
> 
> {
> "iss": "https://server.example.com",
> "aud": "https://client.example.org",
> "exp": "1361398824",
> "cnf":{
> "jwk":{...},
> "jwk":{...}
> }
> }

The example above is invalid, since it contains two "jwk" members.  JWT parsers should reject such input, per Section 4 of RFC 7519.

> {
> "iss": "https://server.example.com",
> "aud": "https://client.example.org",
> "exp": "1361398824",
> "cnf":{
> "jwk":{...},
> "jwe":{...},
> "kid":"..."
> }
> }

This example is ambiguous and malformed, since it contains two keys and may refer to a third one - one in the "jwk" element, one in the "jwe" element, and possibly a different one being referenced by the "kid" element.  I'll plan to add language saying that only a single confirmation key is intended to be communicated in the "cnf" claim and that uses in which multiple keys are communicated and/or referenced in the "cnf" value are syntactically invalid.

> Here is the relevant text:
> 
> "
> 3.1. Confirmation Claim
> 
> The "cnf" (confirmation) claim is used in the JWT to contain members used to
> identify the proof-of-possession key. Other members of the "cnf" object
> may be defined because a proof-of-possession key may not be the only
> means of confirming the authenticity of the token. This is analogous to the
> SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation element, in which a
> number of different subject confirmation methods can be included, including
> proof-of-possession key information. When a recipient receives a "cnf" claim
> with a member that it does not understand, it MUST ignore that member.
> 
> ...
> 
> Note that if an application needs to represent multiple proof-of- possession
> keys in the same JWT, one way for it to achieve this is to use other claim
> names, in addition to "cnf", to hold the additional proof-of-possession key
> information. These claims could use the same syntax and semantics as the
> "cnf" claim.
> "
> 
> ** Key ID
> 
> Lack of interoperability for the Key ID functionality described in Section 3.4.
> 
> The text says that
> 
> "The content of the "kid" value is application specific. For instance, some
> applications may choose to use a JWK Thumbprint [JWK.Thumbprint] value as
> the "kid" value."
> 
> I think we should settle for something and then allow other key id types to
> be used as well.

This is exactly the same as the "kid" usage in JWT [RFC 7519], by design.  It's up to the application what labels to use to identify the keys that it creates.  It can label them "1", "2", "3", ....  It can label them with the date created, such as "16-Nov-2015".  And yes, it could use an "x5t" or JWK Thumbprint value.  Normally, it doesn't matter what the key creator chooses as the Key ID value, since other users of the key just use the "kid" value created along with the key verbatim.  The fact that often both parties don't need to know how a key ID is created is described in paragraph 2 of http://tools.ietf.org/html/rfc7638#section-3.4.  In short, there's no reason to go beyond what JWT does in defining how "kid" values are used - and there are good reasons not to do so.

> ** Nonce Claim
> 
> This example in Section 3.3 uses a claim type, namely nonce, which has not
> been defined yet. I therefore suggest to remove it from this example since it
> does not fulfil a purpose.
> 
> Here is the example:
> 
> {
> "iss": "https://server.example.com",
> "sub": "24400320",
> "aud": "s6BhdRkqt3",
> "nonce": "n-0S6_WzA2Mj",
> "exp": 1311281970,
> "iat": 1311280970,
> "cnf":{
> "jwe":
> "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ.
> (remainder of JWE omitted for brevity)"
> }
> }

The "nonce" claim *is* defined and registered in the IANA JWT Claims Registry at http://www.iana.org/assignments/jwt/jwt.xhtml.

> Ciao
> Hannes

				Thanks again,
				-- Mike