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

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Nov 2015 15:55:29 +0100

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.

** 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?
What is the semantic of these two examples:

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

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

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.

** 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)"
}
}

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Mon, 16 Nov 2015 21:40:43 +0000

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

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

> "aud": "https://client.example.org",

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

> "aud": "https://client.example.org",

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.

> 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:
> 
> {

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

> Hannes

				Thanks again,
				-- Mike

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Nov 2015 02:09:36 +0000

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

				-- Mike

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

> draft-ietf-oauth- proof-of-possession document.
> 
> 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.
> 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.
> 
> requiring yet another key to be in place to allow this procedure to happen securely.
> 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 

> 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.
> 
> ...
> 
> "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.

> not been defined yet. I therefore suggest to remove it from this 
> example since it does not fulfil a purpose.
> 
> Here is the example:
> 
> {

				Thanks again,
				-- Mike

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