ace-wg / ace-dtls-profile

A DTLS profile for Authentication and Authorization for Constrained Environments
6 stars 5 forks source link

Inconsistency in Section 4.1 does not allow kid in psk_identity #7

Closed obgm closed 7 years ago

obgm commented 7 years ago

Ludwig pointed out that Section 4.1 first makes the AT in psk_identity optional, allowing this field to carry a key identifier (which is the intended behavior).

Later, it says that RS "MUST" check if the psk_identity contains a syntactically valid Access Token, and terminate the DTLS session otherwise.

To solve this, the following change is proposed:

OLD:

4.1.  DTLS Channel Setup Between C and RS
[...]
   If RS receives a ClientKeyExchange message that contains a
   "psk_identity" with a length greater zero, it MUST base64-decode its
   contents and process it in the same way as an Access Token that has
   been uploaded to its "/authz-info" resource.  If the contents of the
   "psk_identity" contained a syntactically valid Access Token, RS
   continues processing the ClientKeyExchange message.  Otherwise, the
   DTLS session setup is terminated with an "illegal_parameter" DTLS
   alert message.
[...]
   While C can retrieve the session key from the contents of the "cnf"
   parameter in the AS-to-Client response, RS uses the information
   contained in the "cnf" claim of the Access Token to determine the
   actual session key.  Usually, this is done by including a "COSE_Key"
   object carrying either a key that has been encrypted with a shared
   secret between AS and RS, or a key identifier that can be used by RS
   to lookup the session key.

NEW:

4.1.  DTLS Channel Setup Between C and RS
[...]
   If RS receives a ClientKeyExchange message that contains a
   "psk_identity" with a length greater zero, it MUST base64-decode its
   contents and check if the "psk_identity" field contains a key
   identifier or Access Token according to the following CDDL
   specification:

   psk_identity = {
     kid => bstr / access_token => bstr
   }

   The identifiers for the map keys "kid" and "access_token" are the
   same as in the ACE framework.  The identifier "kid" thus has the
   value 4 (see [I-D.ietf-cose-msg]), and the identifier "access_token"
   has the value 19, respectively (see [I-D.ietf-ace-oauth-authz]).

   If the "psk_identity" field contains a key identifier, the receiver
   MUST check if it has one or more Access Tokens that are associated
   with the specified key.  If no valid Access Token is available for
   this key, the DTLS session setup is terminated with an
   "illegal_parameter" DTLS alert message.

   If instead the "psk_identity" field contains an Access Token, it must
   processed in the same way as an Access Token that has been uploaded
   to its "/authz-info" resource.  In this case, RS continues processing
   the ClientKeyExchange message if the contents of the "psk_identity"
   contained a valid Access Token.  Otherwise, the DTLS session setup is
   terminated with an "illegal_parameter" DTLS alert message.
[...]
   While C can retrieve the session key from the contents of the "cnf"
   parameter in the AS-to-Client response, RS uses the information
   contained in the "cnf" claim of the Access Token to determine the
   actual session key when no explicit "kid" was provided in the
   "psk_identity" field.  Usually, this is done by including a
   "COSE_Key" object carrying either a key that has been encrypted with
   a shared secret between AS and RS, or a key identifier that can be
   used by RS to lookup the session key.
LudwigSeitz commented 7 years ago

Looks good.

obgm commented 7 years ago

I have put in the following change that has been suggested by email and close this issue:

Ludwig Seitz <ludwig.seitz@ri.se> writes:

> Ok I'd suggest the following rewording then:
>
> The identifiers for the map keys "kid" and "access_token" are used
> with the same meaning as in COSE [I-D.ietf-cose-msg] and the ACE
> framework [I-D.ietf-ace-oauth-authz] respectively. The identifier ...