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

[Mike Jones <[e-mail]>]

Thanks again for your comments, Hannes.  I applied the responses described below in -07.

				-- Mike

-----Original Message-----
From: OAuth [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Monday, November 16, 2015 1:41 PM
To: Hannes Tschofenig <[e-mail]>; [e-mail]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-06 Glitches

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

> -----Original Message-----
> From: OAuth [mailto:[e-mail]] On Behalf Of Hannes 
> Tschofenig
> Sent: Monday, November 16, 2015 6:55 AM
> To: [e-mail]
> 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

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth