I don't know that I agree with several of the statements below. I have
problems with the view that just doing a profile is sufficient for a very
simple reason. What if I am presented with a CWT that is from a different
profile?
In your example below, if an issuer was creating a "nbf" claim in an ID Token
profile then it is not conforming to the profile and I would not have a real
problem with the fact that the token could not be used by an entity that did
not understand the profile. What happens to the space when the ID Token
profile gets updated in five years and the "nbf" claim becomes a mandatory
field to be included and understood? All of a sudden there is going to be a
large number of entities in the system that are using the token without
enforcing all of the constraints that are considered to be of importance to the
issuer. This is a security problem.
There is nothing that is being placed in a CWT to identify the profile that is
being used. This means that if a token issuer is creating tokens that match
different profiles and it does not use different keys for each of those
profiles, then a token issued under one profile and with a specific set of
assumptions about what is in the token and what it can be used for, can be
provided to an application that is expecting the second profile and it might
allow operations which would otherwise not be permitted. This is a security
issue.
Identifying the profile in the token is one possible answer, but it is one with
lots of other problems. Who defines and identifies the profiles? How are they
uniquely identified? How do you do the configuration on a small device to deal
with company identified profiles?
A more generic way of allowing for identification of what is and what is not
so important might be one way to get around some of these issue
Jim
-Original Message-
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Tuesday, May 16, 2017 3:58 PM
To: Carsten Bormann
Cc: Jim Schaad ; Samuel Erdtman ;
ace
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token
Profiles of CWTs will vary in which claims must be present, which are optional,
and what the format of those claims are, when applicable. This is just like
JWT, where application profiles provide that information. To make this
concrete, OpenID Connect defines a profile of a JWT called an ID Token at
http://openid.net/specs/openid-connect-core-1_0.html#IDToken. Note that is
says which claims are REQUIRED and OPTIONAL. The profile also defines
additional ID Token validation rules at
http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation, which
go beyond those in the JWT spec itself. This is how application profiles work.
As a hypothetical example, it would be unhelpful for the ID Token profile if
the underlying JWT spec had said that the "nbf" (not before) claim must be
understood by all implementations, when this profile doesn't use it or contain
validation rules for it. Even if a producer included a "nbf" claim, the
consumer for this profile can safely ignore it, since no validation rules
accompany it for ID Tokens. The same is true of all other JWT-defined claims.
And the same needs to be true of the parallel CWT claims as well. For
instance, we shouldn't force all CWT applications to understand and process
"nbf" any more than we force all JWT applications to.
There's nothing insecure about this but there is something efficient it that we
must preserve - particularly for constrained implementations.
-- Mike
-Original Message-
From: Carsten Bormann [mailto:c...@tzi.org]
Sent: Tuesday, May 16, 2017 3:26 PM
To: Mike Jones
Cc: Jim Schaad ; Samuel Erdtman ;
ace
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token
On May 16, 2017, at 00:16, Mike Jones wrote:
>
> I disagree with the suggestion (tracked in
> https://github.com/erwah/ietf/issues/37) about claims that must be
> understood. We shouldn’t force implementations to understand claims not used
> by their application. See my comment in the issue.
Not sure what is the “implementation” and what is the “application” here.
If an application puts in a “must understand” claim key, I’m not sure who is
forcing what here.
If we don’t have “must understand” claim keys, then there is no way for an
application to signal that necessity.
Security issues with recipient applications that don’t correctly interpret the
CWT they received, follow. Not good.
Grüße, Carsten
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace