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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
