[Ace] WGLC for draft-ietf-dtl-authorize

[Jim Schaad]

The chairs believe that the set of documents dealing with the OAuth
framework for constrained environments is nearing the point that we should
be able to advance it to the IESG for publication.   We therefore want to
have a full list of issues that need to be dealt with at the Bangkok
meeting.

This starts a 2 week WGLC for draft-ietf-ace-dtls-authorize

We know that the following issues are outstanding:

draft-ietf-ace-dtls-authorize:
*  No current known issues


Jim & Roman


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] WGLC for draft-ietf-ace-oscore-profile

[Jim Schaad]

The chairs believe that the set of documents dealing with the OAuth
framework for constrained environments is nearing the point that we should
be able to advance it to the IESG for publication.   We therefore want to
have a full list of issues that need to be dealt with at the Bangkok
meeting.

This starts a 2 week WGLC for draft-ietf-ace-oscore-profile

We know that the following issues are outstanding:

draft-ietf-ace-oscore-profile:
*  No current known issues


Jim & Roman


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] WGLC for draft-ietf-ace-authz

[Jim Schaad]

The chairs believe that the set of documents dealing with the OAuth
framework for constrained environments is nearing the point that we should
be able to advance it to the IESG for publication.   We therefore want to
have a full list of issues that need to be dealt with at the Bangkok
meeting.

This starts a 2 week WGLC for draft-ietf-ace-authz

We know that the following issues are outstanding:

draft-ietf-ace-authz
*  There are a couple of esoteric issues around listing AS servers
associated with resources in a Resource Directory


Jim & Roman




___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] JWT + OAuth Request

[Jim Schaad]

> -Original Message-
> From: Michael Richardson 
> Sent: Thursday, October 4, 2018 6:45 AM
> To: Jim Schaad 
> Cc: ace@ietf.org
> Subject: Re: [Ace] JWT + OAuth Request
> 
> 
> Jim Schaad  wrote:
> > The OAuth group discovered a problem with some the names of our new
> > OAuth fields that was caused by the fact that they have an ID that
is
> > someplace between the IESG and the RFC Editor which introduced the
> 
> Took a moment to realize that ID = Internet Draft, rather than being a
> reference a hash key id :-) (Which document is this?)

This is JWT Secured Authorization Request (JAR)
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

Jim

> 
> > Why option 1 might be acceptable:
> 
> ...
> 
> > B. If a CWT version is this is really needed, perhaps we can get a
> > different design to be used.  Specifically, create two new CWT
claims:
> > "oauth_req", "oauth_resp" and then place the OAuth parameters in
those
> > fields and not make them CWT claims.  I am sure that there would be
> > complaints about this, but much as COSE fixed problems that it saw
as
> > being wrong, the WG could do the same thing.
> 
> I prefer this solution, but I feel unsufficiently informed about how the
above ID
> might come back to bite us.
> 
> (I can live with combining registries)
> 
> --
> Michael Richardson , Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
> 


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

[Jim Schaad]

> -Original Message-
> From: Ace  On Behalf Of Michael Richardson
> Sent: Monday, September 24, 2018 9:27 AM
> To: consulta...@vanderstok.org
> Cc: Esko Dijk ; Panos Kampanakis (pkampana)
> ; ace@ietf.org
> Subject: Re: [Ace] ace-coap-est: unclear definition of /.well-known/est
URI
> 
> 
> Peter van der Stok  wrote:
> > What do I read?  when you do GET coap://example.com/.well-known/core
> > The discovery is on port 5683.  When you do GET
> > coaps://example.com/.well-known/core the discovery port is 5684.
> 
> yes, the question is, when you ask:
> 
> coap://example.com/.well-known/core?rt=ace.est
> 
> do you expect to get back a pointer to:
> 
>coaps://example.com/est
> 
> > RFC 7030 does not ask a port number from IANA.  And a search through
> > IANA port numbers on "est" does not yield anything.
> 
> It does not.
> a) it doesn't do discovery, but just uses /.well-known directly.
> b) it assumes https://

Is there any reason to assume that you need a different port from the
default pair of coap ports?  Knowing what the protocol and host name will
point it to the correct location and you have the URI path to go to the
correct resource on that server.  

Jim

> 
> --
> ]   Never tell me the odds! | ipv6 mesh
networks [
> ]   Michael Richardson, Sandelman Software Works| network
architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
[


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Review draft-ietf-ace-coap-est

[Jim Schaad]

Yes I think that is correct.  I’ll need to review final text at some point but 
what you say below look right.

 

From: Panos Kampanakis (pkampana)  
Sent: Thursday, September 13, 2018 1:29 PM
To: Jim Schaad ; consulta...@vanderstok.org
Cc: draft-ietf-ace-coap-...@ietf.org; 'ace' 
Subject: RE: [Ace] Review draft-ietf-ace-coap-est

 

Hi Jim,

 

Trying to close on this one and update the draft if necessary.

> [JLS]  I do not believe that the wrapping of content with the CBOR binary 
> text wrapping is needed at this point.  If that is needed for the multi-part 
> wrapping, then it is the job of the multi-part wrapping to deal with this 
> problem.  Multipart needs to be able to say I have a multipart of  text, json> neither of which are CBOR objects.  Therefor there is no reason 
> for you to use a CBOR wrapper for this and not just use the binary value.

You are right. We don’t need the CBOR binary wrapping. Originally the multipart 
was not using CBOR either 
https://tools.ietf.org/html/draft-fossati-core-multipart-ct-03 It was just 
using the encoding the length and then included the encoded payload. The draft 
was updated https://tools.ietf.org/html/draft-ietf-core-multipart-ct and to be 
consistent with CBOR follow this new wrapping methodology that leverages CBOR. 
What you are saying is right, but we needed to point to a live draft. 

 

The key and the cert payloads in the multipart conveyed here will be ASN.1 as 
you suggested, binary encoded. The CT ID for the key and cert are defined in 
EST-coaps as 280 and 281. We need to make sure we spell them out in the text 
though to make them clearer. 

 

Does it make sense? 

 

Panos

 

 

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, July 04, 2018 9:30 AM
To: consulta...@vanderstok.org <mailto:consulta...@vanderstok.org> 
Cc: draft-ietf-ace-coap-...@ietf.org <mailto:draft-ietf-ace-coap-...@ietf.org> 
; 'ace' mailto:ace@ietf.org> >
Subject: Re: [Ace] Review draft-ietf-ace-coap-est

 

 

 

From: Peter van der Stok mailto:stokc...@bbhmail.nl> > 
Sent: Wednesday, July 4, 2018 1:53 AM
To: Jim Schaad mailto:i...@augustcellars.com> >
Cc: draft-ietf-ace-coap-...@ietf.org <mailto:draft-ietf-ace-coap-...@ietf.org> 
; 'ace' mailto:ace@ietf.org> >
Subject: Re: [Ace] Review draft-ietf-ace-coap-est

 

Hi Jim,

Many thanks for the review. See our answers below.

* In section 4.1 I have a question about what you are using for payload content 
encoding.  Part of this might just be a question of how you plan to move from 
ASN.1 to CBOR at some point in the future.  I think that it would necessitate 
doing new media-types in that event.  You appear to be doing a CBOR bstr 
wrapping on the ASN.1 encoding payload.  I don't believe that there is any 
reason for doing this.  I would expect that the payload would be the ASN.1 w/o 
any ASN.1.  It is highly possible that I am just mis-reading what the text says 
and this is what you say.



What I wanted to do, and did not express very well.

Keep the ASN.1 structure of the payload; (re-using code)

Use straight binary coding instead of the base64-encoded (30% payload reduction)

Wrap the binary in a CBOR major type 2 h’xxx’ notation. (compatibility with 
multipart)

Not sure if this needs a new media type, the http content-coding and 
transfer-coding registries were not very helpful.



[JLS]  I do not believe that the wrapping of content with the CBOR binary text 
wrapping is needed at this point.  If that is needed for the multi-part 
wrapping, then it is the job of the multi-part wrapping to deal with this 
problem.  Multipart needs to be able to say I have a multipart of  neither of which are CBOR objects.  Therefor there is no reason for you 
to use a CBOR wrapper for this and not just use the binary value.



* In section 5.0 - As written, the example of doing a query against 
/.well-known/core does not match my understanding of what would be return.
It should only return those resources which have the rt field set on them.
I do not understand why you believe that the following lines MAY be returned.  
Clarification of why you think this is true would be appreciated.



Thanks for your reaction, I hesitated between two choices.

*   Provide every line with another rt=ace.est.crts; rt=ace.est.sen; etc.
*   Make them all ace.est.

There are no structure guidelines on rt= value, which complicates things.

Looking forward to your (and others) opinion.



[JLS] This is probably a don’t ask me question because I am not a deployer of 
IoT objects.  I don’t know that there is a good answer for this.  This is 
probably a good question to toss at the CORE WG.


* Section 6 - Is there a need to have all of this description around 
TLS-unique?  Do you have a reason to believe that people are going get this 
implemented wrong?


This come from experience. The implementation we had done in the past did not 
implement

Re: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth-authz

[Jim Schaad]

We are doing all of this in response to a draft?  Why can you not fix the
draft and put the OAuth parameters in a sub map so there is no collisions?

Jim


> -Original Message-
> From: Mike Jones 
> Sent: Tuesday, August 28, 2018 9:45 AM
> To: Ludwig Seitz ; Samuel Erdtman ;
> Jim Schaad 
> Cc: ace@ietf.org
> Subject: RE: [Ace] Parameter abbreviation number ranges for
draft-ietf-ace-
> oauth-authz
> 
> Especially in light of the possibility of signed requests along the lines
of
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-16, I believe that all
the ACE
> OAuth parameters should be registered as CWT claims.  I'll repeat my
request,
> wearing my designated expert hat, that application-specific values not be
> requested for registration in the one-byte ranges.  The one-byte values
should
> be saved for claims that are likely to span multiple kinds of
applications.
> 
>   -- Mike
> 
> -Original Message-
> From: Ace  On Behalf Of Ludwig Seitz
> Sent: Monday, August 27, 2018 11:44 PM
> To: Samuel Erdtman ; Jim Schaad
> 
> Cc: ace@ietf.org
> Subject: Re: [Ace] Parameter abbreviation number ranges for
draft-ietf-ace-
> oauth-authz
> 
> On 2018-08-27 18:39, Samuel Erdtman wrote:
> > +1 on pushing up error_description and error_uri
> >
> > I think client_id might be worth keeping low since it is often used
> > even when in combination with client_secret. See OAuth Mtls as an
example.
> > On Mon, 27 Aug 2018 at 18:20, Jim Schaad  > <mailto:i...@augustcellars.com>> wrote:
> >
> 
> Note that the 1 byte range is 0-23
> 
> Currently in the 1 byte uint range we have 20-23 left unused
> 
> We could start assigning negative integer values in the 1 byte range if
needed.
> 
> 
> /Ludwig
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE SICS
> Phone +46(0)70-349 92 51
> 
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Parameter abbreviation number ranges for draft-ietf-ace-oauth-authz

[Jim Schaad]

> -Original Message-
> From: Ace  On Behalf Of Ludwig Seitz
> Sent: Monday, August 27, 2018 12:52 AM
> To: ace@ietf.org
> Subject: [Ace] Parameter abbreviation number ranges for
draft-ietf-ace-oauth-
> authz
> 
> Hello group,
> 
> at IETF 102 there was a discussion about the numerical abbreviations we
> introduced for both OAuth parameter names and access token claim names.
> 
> I have generated a proposal that makes better use of the number space, but
I'd
> like the OAuth specialists to have a look at it and see if I pushed any
important
> (= frequently used) OAuth parameter into the two byte number range.
> 
> 
> Background:
> 
> CBOR integers have a very compact representation (1 byte) for numbers from
> 0-23, from 24-255 (which is all we will ever need ;-) ) they use 2 bytes.
Thus
> we'd like to use abbreviations in the first number range for
parameters/claims
> that are frequently used.
> 
> My proposal follow below, please feel free to comment.
> 
> 
> /Ludwig
> 
> 
> 
> 
> Existing claim name abbreviations from RFC 8392 (CWT) :
>   iss  1
>   sub  2
>   aud  3
>   exp  4
>   nbf  5
>   iat  6
>   cti  7
> 
> New claim name abbreviation introduced by
> draft-ietf-ace-cwt-proof-of-possession:
> 
>   cnf  8
> 
> New claims introduced by draft-ietf-ace-oauth-authz (with proposed
> abbreviations):
> 
>   scope 9
>   profile 10
>   rs_cnf 11
> 
> Token endpoint parameters from RFC 6749 (OAuth 2.0) (with proposed
> abbreviations):
> 
> scope 9
> error 12
> grant_type 13
> access_token 14
> token_type 15
> 
> client_id  24
> client_secret  25
> response_type  26
> state 27
> redirect_uri 28
> error_description 29
> error_uri 30
> code 31
> expires_in 32
> username 33
> password 34
> refresh_token 35

[JLS] I would be willing to push error_description and error_uri up into the
two byte range I don't think they fall into the frequently used category in
a working system.  I don't know that we need to keep client_id,
client_secret, username and password in the low range at this time.   Do we
really think that we are going to be using this on small devices?

> 
> New token endpoint parameters introduced by draft-ietf-ace-oauth-authz
(with
> proposed abbreviations):
> 
> req_aud 16
> req_cnf 17
> used_cnf 18
> rs_cnf 19
> 
> (Note that req_* and used_cnf are not yet in the draft, but we came to the
> conclusion we will need them after the OAuth session at IETF 102.
> They will be in the next update)
> 
> Introspection endpoint paramenters from RFC  (OAuth 2.0 introspection)
(with
> proposed abbreviations):
> 
> iss 1
> sub 2
> aud 3
> exp 4
> iat 6
> nbf 5
> scope  9
> token_type 15
> active 20
> client_id 24
> username 33
> jti (no abbreviation, we have cti)
> 
> 
> 
> New introspection endpoint parameters introduced by
> draft-ietf-ace-oauth-authz:
> 
> cnf 8
> rs_cnf   19
> profile  10
> 
> 
> 
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE SICS
> Phone +46(0)70-349 92 51
> 
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Text for KID in POP

[Jim Schaad]

Should be circumscribed not circumcised although the first does echo my
personal feelings.

Jim


> -Original Message-
> From: Ace  On Behalf Of Jim Schaad
> Sent: Wednesday, July 18, 2018 6:13 PM
> To: ace@ietf.org
> Subject: [Ace] Text for KID in POP
> 
> Add the following text to section 3.4.
> 
> WARNING: The use of a Key ID in a POP CWT needs to be carefully
circumcised.
> Where the Key ID is not a cryptographic value derived from the key or
where
> all of the parties involved are not validating the cryptographic
derivation, it is
> possible to get into situations where the same Key ID is being used for
multiple
> keys.  The implication of this, is that an RS may have multiple keys
registered
> with it that have the same Key ID and thus it does not know which key the
new
> CWT is to be associated with
> 
> In the world of constrained IoT devices, there is frequently a restriction
on the
> size that a key id can be either because of table constraints or a desire
to keep
> message sizes small.  These restrictions are going to protocol dependent.
For
> example, DTLS can use a key id of any size.
> However, if the key is being used with COSE encrypted message then the
length
> of the key needs to be minimized and may have a limit as small as one
byte.
> The value of a key id is not always the same for both parties.  When
sending a
> COSE encrypted message with a shared key, the key id may be different on
> both sides of the conversation with the appropriate one being included in
the
> message based on the recipient of the message.
> 
> For symmetric keys, the key ID is normally going to be generated by the
CWT
> issuer.  This means that enforcing a rule that key ID values only match if
CWTs
> have the same issuer works for matching key ids between CWTs.  In this
case
> the issuer can ensure that there are no collisions between currently
active
> symmetric keys for all CWTs that it has issued.  This allows for an RS to
use the
> pair of issuer and key id for matching with existing keys.
> 
> For asymmetric keys, the key ID value is normally going to be generated by
the
> client and thus the possibility of collisions is going to greatly
increase.  It would
> be normal for all clients to start by assigning a key id of 0 given that
key ids are
> frequently only needed to be unique and meaningful to the client.  This
> problem can be addressed in a couple of different ways depending on how
the
> key id value is going to be used.
> 
> * The issuer can assign a new unique key id the first time it sees the
key,
> depending on the protocol being used the new value may then need to be
> transported to the presenter by the protocol used to issue CWTs.  In this
case
> the rule of requiring that the issuer, key id pair be used for matching
works.
> 
> *  The issuer can use a different confirmation method if a collision is
> unavoidable.
> 
> * Clients may decide not to use a CWT based on a created key identifier if
it
> does not fit the clients requirements.
> 
> * If an issuer is going to issue confirmations of Key ID and is not going
to
> guarantee that serial number uniqueness is going to be preserved, the
relying
> party needs to have that information configured into it so that
appropriate
> action is going to be taken.
> 
> 
> Jim
> 
> 
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Text for KID in POP

[Jim Schaad]

Add the following text to section 3.4.

WARNING: The use of a Key ID in a POP CWT needs to be carefully circumcised.
Where the Key ID is not a cryptographic value derived from the key or where
all of the parties involved are not validating the cryptographic derivation,
it is possible to get into situations where the same Key ID is being used
for multiple keys.  The implication of this, is that an RS may have multiple
keys registered with it that have the same Key ID and thus it does not know
which key the new CWT is to be associated with

In the world of constrained IoT devices, there is frequently a restriction
on the size that a key id can be either because of table constraints or a
desire to keep message sizes small.  These restrictions are going to
protocol dependent.  For example, DTLS can use a key id of any size.
However, if the key is being used with COSE encrypted message then the
length of the key needs to be minimized and may have a limit as small as one
byte.  The value of a key id is not always the same for both parties.  When
sending a COSE encrypted message with a shared key, the key id may be
different on both sides of the conversation with the appropriate one being
included in the message based on the recipient of the message.

For symmetric keys, the key ID is normally going to be generated by the CWT
issuer.  This means that enforcing a rule that key ID values only match if
CWTs have the same issuer works for matching key ids between CWTs.  In this
case the issuer can ensure that there are no collisions between currently
active symmetric keys for all CWTs that it has issued.  This allows for an
RS to use the pair of issuer and key id for matching with existing keys.

For asymmetric keys, the key ID value is normally going to be generated by
the client and thus the possibility of collisions is going to greatly
increase.  It would be normal for all clients to start by assigning a key id
of 0 given that key ids are frequently only needed to be unique and
meaningful to the client.  This problem can be addressed in a couple of
different ways depending on how the key id value is going to be used.  

* The issuer can assign a new unique key id the first time it sees the key,
depending on the protocol being used the new value may then need to be
transported to the presenter by the protocol used to issue CWTs.  In this
case the rule of requiring that the issuer, key id pair be used for matching
works.

*  The issuer can use a different confirmation method if a collision is
unavoidable.

* Clients may decide not to use a CWT based on a created key identifier if
it does not fit the clients requirements.

* If an issuer is going to issue confirmations of Key ID and is not going to
guarantee that serial number uniqueness is going to be preserved, the
relying party needs to have that information configured into it so that
appropriate action is going to be taken.


Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Review Comments on -03

[Jim Schaad]

In the event of an unauthorized, the RS has the ability to return a URL to the 
AS it knows about.  If it returns coaps://AS/token, then this might be thought 
of implying that one needs to use dtls to talk to the AS rather than using 
OSCORE.  The same might be true if you just returned coap://AS/token.  Once 
upon a time, I thought there was some work being done in the core group that 
would help clean this up.  It has not finished, nor have I seen much about it 
recently.

Jim
 

> -Original Message-
> From: Carsten Bormann 
> Sent: Monday, July 16, 2018 7:14 AM
> To: Jim Schaad 
> Cc: draft-ietf-ace-dtls-author...@ietf.org; ace 
> Subject: Re: Review Comments on -03
> 
> Hi Jim,
> 
> > On Jul 15, 2018, at 20:48, Jim Schaad  wrote:
> >
> > * It is too bad that we don't have the generic coap schemas defined
> > yet so that we can use that as part of the URL returned with an access
> > denied response.
> 
> Can you expand on that?  What should we have defined?
> 
> Grüße, Carsten


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Comments on ace key groupcomm -01

[Jim Schaad]

* Section 2 - client  - write rights and/or read rights.  Unless you think
that write implies read in which case you should state that

* Section 2 - KDC - should also say what it does in the later parts - 

* Section 2 - Dispatcher - If this is a bus, then you are not really
communicating with it securely.  Anybody can write on it, but people will
just ignore what comes out the other end.

* Section 3-  A brief description of all of the operations would be
appreciated.

* Section 3.1 - Can I get authorization for multiple items at a single time?

* Section 3.1 - Does it make sense to allow for multiple audiences to be on
a single KDC?  

* Section 4.x  - cnf - text does not allow for key identifier

* Section X.X - Define a new cnf method to hold the OSCORE context
parameters - should it be a normal COSE_Key or something new just to makes
sure that it is different.

* Section 3.X - I am not sure if write or POST is a better answer for what
the role being requested is.

* Section 4 - Should one talk about the ability to use OBSERVE as part of
key distribution?

* Section 4.x - I am having a hard time trying to figure out the difference
between a group and a topic.  The text does not always seem to distinguish
these well.

* Seciton 4.1 - POP on client key  esp if bound to an identity (Note using
it to access the KDC is one POP)

* Section 4.2 - why not use the exp field from OAUTH in the response

* Question - does somebody talk about doing key derivation for a new kid
showing up and by the way where is the gid

* Seciton 4.2 - if you are using profile, then you should return it

* Introduction - introduce the concept of a key management protocol and
point to some.  Give some basic properties expected from one.

* Section 5.2 - What is the message to leave - can I leave one scope but not
another?  Can I just give up a role?

* Seciton 6.1 - assumes scopes are unique across all audiences.  Or assumes
that I look up the correct token - should have an argument about why this is
possible so that people can implement it right

* Comment somewhere about getting strike zones setup correctly for a newly
seen sender of messages. Ptr to OSCORE?

Jim



___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Review draft-ietf-ace-coap-est

[Jim Schaad]

 

 

From: Peter van der Stok  
Sent: Monday, July 9, 2018 1:01 AM
To: Jim Schaad 
Cc: consulta...@vanderstok.org; draft-ietf-ace-coap-...@ietf.org; 'ace' 

Subject: Re: [Ace] Review draft-ietf-ace-coap-est

 

 

* In section 4.1 I have a question about what you are using for payload content 
encoding.  Part of this might just be a question of how you plan to move from 
ASN.1 to CBOR at some point in the future.  I think that it would necessitate 
doing new media-types in that event.  You appear to be doing a CBOR bstr 
wrapping on the ASN.1 encoding payload.  I don't believe that there is any 
reason for doing this.  I would expect that the payload would be the ASN.1 w/o 
any ASN.1.  It is highly possible that I am just mis-reading what the text says 
and this is what you say.



What I wanted to do, and did not express very well.

Keep the ASN.1 structure of the payload; (re-using code)

Use straight binary coding instead of the base64-encoded (30% payload reduction)

Wrap the binary in a CBOR major type 2 h'xxx' notation. (compatibility with 
multipart)

Not sure if this needs a new media type, the http content-coding and 
transfer-coding registries were not very helpful.



[JLS]  I do not believe that the wrapping of content with the CBOR binary text 
wrapping is needed at this point.  If that is needed for the multi-part 
wrapping, then it is the job of the multi-part wrapping to deal with this 
problem.  Multipart needs to be able to say I have a multipart of  neither of which are CBOR objects.  Therefor there is no reason for you 
to use a CBOR wrapper for this and not just use the binary value.

 



You are right of course, the CBOR wrapping is not needed outside the multipart 
media type.
However, CBOR wrapping for all payloads, reduces the choices when decoding the 
payload; They all start the same.
And it adds 2-3 bytes on many.


[JLS]  I don’t follow this at all.  How I read this statement is

I have a binary value and I need to look at the content type to figure out what 
ASN.1 structure it is and decode it.  This is very hard.  So I am going to 
change this to

I need to look at the content type to figure out that I have a CBOR bstring 
value.  It is easy to remove the CBOR bstring value.  I now have a binary value 
and I need to look at the content type to figure out what ASN.1 structure it is 
and decode it.  This is somehow easier.

 

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Review draft-ietf-ace-coap-est

[Jim Schaad]

 

 

From: Peter van der Stok  
Sent: Wednesday, July 4, 2018 1:53 AM
To: Jim Schaad 
Cc: draft-ietf-ace-coap-...@ietf.org; 'ace' 
Subject: Re: [Ace] Review draft-ietf-ace-coap-est

 

Hi Jim,

Many thanks for the review. See our answers below.

* In section 4.1 I have a question about what you are using for payload content 
encoding.  Part of this might just be a question of how you plan to move from 
ASN.1 to CBOR at some point in the future.  I think that it would necessitate 
doing new media-types in that event.  You appear to be doing a CBOR bstr 
wrapping on the ASN.1 encoding payload.  I don't believe that there is any 
reason for doing this.  I would expect that the payload would be the ASN.1 w/o 
any ASN.1.  It is highly possible that I am just mis-reading what the text says 
and this is what you say.



What I wanted to do, and did not express very well.

Keep the ASN.1 structure of the payload; (re-using code)

Use straight binary coding instead of the base64-encoded (30% payload reduction)

Wrap the binary in a CBOR major type 2 h’xxx’ notation. (compatibility with 
multipart)

Not sure if this needs a new media type, the http content-coding and 
transfer-coding registries were not very helpful.



[JLS]  I do not believe that the wrapping of content with the CBOR binary text 
wrapping is needed at this point.  If that is needed for the multi-part 
wrapping, then it is the job of the multi-part wrapping to deal with this 
problem.  Multipart needs to be able to say I have a multipart of  neither of which are CBOR objects.  Therefor there is no reason for you 
to use a CBOR wrapper for this and not just use the binary value.



* In section 5.0 - As written, the example of doing a query against 
/.well-known/core does not match my understanding of what would be return.
It should only return those resources which have the rt field set on them.
I do not understand why you believe that the following lines MAY be returned.  
Clarification of why you think this is true would be appreciated.



Thanks for your reaction, I hesitated between two choices.

*   Provide every line with another rt=ace.est.crts; rt=ace.est.sen; etc.
*   Make them all ace.est.

There are no structure guidelines on rt= value, which complicates things.

Looking forward to your (and others) opinion.



[JLS] This is probably a don’t ask me question because I am not a deployer of 
IoT objects.  I don’t know that there is a good answer for this.  This is 
probably a good question to toss at the CORE WG.


* Section 6 - Is there a need to have all of this description around 
TLS-unique?  Do you have a reason to believe that people are going get this 
implemented wrong?


This come from experience. The implementation we had done in the past did not 
implement it correctly, that is why we expanded on the TLS-unique. We will see 
about shrinking the text in the draft. 



* Section 7 - I think the figure has an error associated w/ it.  The CA should 
be tied to the EST Server and not to the Registrar


Thank you, we will fix that in the next iteration.



* Section 7 - Your language is a bit sloppy around the terms of POP and POP 
linking.  Unless it is really badly behaved, POP should never be broken by an 
RA.  The POP is the signature on the request and not tied to the TLS channel.  
The POP linking is tied to the TLS channel and is broken by the changing of the 
TLS sessions (client <-> RA,  RA <-> CA) 


Very good catch. We will tighten the language in the next iteration.



* Section 7 - It is not clear to me that the SHOULD on reassembly of 
fragmentation is not a MUST.  I doubt that any EST server is going to be able 
to deal with getting fragments of requests from a registrar in separate 
messages.  This would be compounded if the proxy is handling multiple sessions 
at the same time. 


I think that is reasonable. We will address it. 



* Section 7 - It should be possible that when doing key generation for the 
protection of the private key to be end-to-end and it should not be necessary 
for the Proxy to decrypt and then re-encrypt the private key.  It should not 
matter for this if one does either symmetric or asymmetric encryption of the 
private key.



Proxy: you mean Registrar.

[JLS] Yes I meant Registrar.

The wish is understood, we’ll look into it.



* Section 7 - It is very possible that the private key generation function 
would be hosted on the proxy and not at the CA.  I think that you might want to 
describe this as a normal configuration.  (Just spotted this in the Security 
considerations.  I think it should be here as well.)


Yes, right. We need to be crisper on the document that end to end or proxy can 
provide this functionality. We will make sure it is clear in the text. 



* Section 9.1 - application/multipart-core should not be in the table of items 
for IANA to register.  This is being done in a different document.  If you want 
this table as a whole then it needs to be moved

[Ace] Review draft-ietf-ace-coap-est

[Jim Schaad]

* In section 4.1 I have a question about what you are using for payload
content encoding.  Part of this might just be a question of how you plan to
move from ASN.1 to CBOR at some point in the future.  I think that it would
necessitate doing new media-types in that event.  You appear to be doing a
CBOR bstr wrapping on the ASN.1 encoding payload.  I don't believe that
there is any reason for doing this.  I would expect that the payload would
be the ASN.1 w/o any ASN.1.  It is highly possible that I am just
mis-reading what the text says and this is what you say.

* In section 5.0 - As written, the example of doing a query against
/.well-known/core does not match my understanding of what would be return.
It should only return those resources which have the rt field set on them.
I do not understand why you believe that the following lines MAY be
returned.  Clarification of why you think this is true would be appreciated.

* Section 6 - Is there a need to have all of this description around
TLS-unique?  Do you have a reason to believe that people are going get this
implemented wrong?

* Section 7 - I think the figure has an error associated w/ it.  The CA
should be tied to the EST Server and not to the Registrar

* Section 7 - Your language is a bit sloppy around the terms of POP and POP
linking.  Unless it is really badly behaved, POP should never be broken by
an RA.  The POP is the signature on the request and not tied to the TLS
channel.  The POP linking is tied to the TLS channel and is broken by the
changing of the TLS sessions (client <-> RA,  RA <-> CA) 

* Section 7 - It is not clear to me that the SHOULD on reassembly of
fragmentation is not a MUST.  I doubt that any EST server is going to be
able to deal with getting fragments of requests from a registrar in separate
messages.  This would be compounded if the proxy is handling multiple
sessions at the same time. 

* Section 7 - It should be possible that when doing key generation for the
protection of the private key to be end-to-end and it should not be
necessary for the Proxy to decrypt and then re-encrypt the private key.  It
should not matter for this if one does either symmetric or asymmetric
encryption of the private key.

* Section 7 - It is very possible that the private key generation function
would be hosted on the proxy and not at the CA.  I think that you might want
to describe this as a normal configuration.  (Just spotted this in the
Security considerations.  I think it should be here as well.)

* Section 9.1 - application/multipart-core should not be in the table of
items for IANA to register.  This is being done in a different document.  If
you want this table as a whole then it needs to be moved out of IANA
considerations.

* Section 9.2 - please expand this text some.  You might want to look at
https://tools.ietf.org/html/rfc7390#section-6.1 for a template.


Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

 

 

From: Samuel Erdtman  
Sent: Wednesday, June 27, 2018 8:18 AM
To: Jim Schaad 
Cc: Hannes Tschofenig ; Benjamin Kaduk 
; Mike Jones ; 
draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on 
draft-ietf-ace-cwt-proof-of-possession-02

 

Jim, are you saying that if the client can pick the key identifier and if it 
has seen a key identifier of another client it could request a PoP token with 
the observed key-id and the observed subject but with an new key. 
I guess this is a potential scenario that could be worth mentioning in security 
considerations.

[JLS] No I am not assuming that the observed subject is also chosen by the 
attacker, just the observed key-id.

If we look at ACE-OAuth there are as far as I can tell a few things that makes 
this a hard attack to do.

When the client makes the token request it is authenticated.

[JLS] Unclear why this is relevant.  I am asking for this new token as myself.

And with the subject being the authenticated client cannot control what goes 
into the cwt as subject

[JLS] You are making an assumption that a) the subject is actually going to be 
populated rather than be left empty and thus be anonymous and 2) that the 
resource server is going to make any enforcement based on the subject.  I 
expect it to be done based on audience and scope only.

Since the cwt with the PoP key is signed there is no way for the attacking 
client to retro-fit the token to suit its needs e.g. change subject or key-id.

[JLS] I am asking for a new token not trying to modify an existing token so 
this is not especially relevant.


Finally I think it is preferable if the server selects key identifier. 

[JLS] I would agree, however if you have two AS that are operating in the same 
authorization range and are not tightly linked then this is not easy for doing 
an additional privilege token where the POP is identified by the KID.  This is 
even harder if an RS is going to allow two different AS from different scopes 
to be authoritative as they would never coordinate together.



Best regards
//Samuel




On Tue, 26 Jun 2018 at 18:57, Jim Schaad mailto:i...@augustcellars.com> > wrote:

Hannes,

My worry is not about implementers getting this correct and picking random
key ids.  My worry is about an attacker seeing the key id of somebody and
trying to use it either with the same or a different AS and getting a key
and then getting permissions associated with the initial key that they
should not be doing.

This is about an attack not about getting things to generally work right.

Jim


> -Original Message-
> From: Hannes Tschofenig  <mailto:hannes.tschofe...@arm.com> >
> Sent: Tuesday, June 26, 2018 6:09 PM
> To: Jim Schaad mailto:i...@augustcellars.com> >; 
> 'Benjamin Kaduk'
> mailto:ka...@mit.edu> >; 'Mike Jones' 
> mailto:michael.jo...@microsoft.com> >
> Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org 
> <mailto:draft-ietf-ace-cwt-proof-of-possess...@ietf.org> ; ace@ietf.org 
> <mailto:ace@ietf.org> 
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hi Jim,
> 
> you are essentially proposing that we should not directly use the key id
that
> is in the CWT-PoP but rather use it as input in a key derivation function.
The
> details of that key derivation function are specified outside the CWT-POP
> document and most likely in the context of the various profiles.
> Your proposals below suggest to use, among other things, the session key
as
> input to that function. That sounds pretty straight forward but raises the
> question why we fail to trust the implementer to create random key ids but
> then still trust them to create random keys.
> 
> That's fine for me nevertheless.
> 
> Ciao
> Hannes
> 
> -Original Message-
> From: Jim Schaad [mailto:i...@augustcellars.com 
> <mailto:i...@augustcellars.com> ]
> Sent: 24 June 2018 10:15
> To: 'Benjamin Kaduk'; 'Mike Jones'
> Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possess...@ietf.org 
> <mailto:draft-ietf-ace-cwt-proof-of-possess...@ietf.org> ;
> ace@ietf.org <mailto:ace@ietf.org> 
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Thinking things through, I would be more comfortable with something like
> the
> following:
> 
> 1.  Create a confirmation called 'computed key id'.  This has two basic
> values:  What is the computation method?  What is the proof value?  You
can
> optionally have an unprotected KID value used to filter the set of keys on
the
> RS down to a reasonable set to enumerate (hopefully one).
> 
> 2.  For RPK and TLS:  Define a method called hash of SPKI which has a hash
> method as a parameter.  Given that this can be computed independently 

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

Hannes,

My worry is not about implementers getting this correct and picking random
key ids.  My worry is about an attacker seeing the key id of somebody and
trying to use it either with the same or a different AS and getting a key
and then getting permissions associated with the initial key that they
should not be doing.

This is about an attack not about getting things to generally work right.

Jim


> -Original Message-
> From: Hannes Tschofenig 
> Sent: Tuesday, June 26, 2018 6:09 PM
> To: Jim Schaad ; 'Benjamin Kaduk'
> ; 'Mike Jones' 
> Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hi Jim,
> 
> you are essentially proposing that we should not directly use the key id
that
> is in the CWT-PoP but rather use it as input in a key derivation function.
The
> details of that key derivation function are specified outside the CWT-POP
> document and most likely in the context of the various profiles.
> Your proposals below suggest to use, among other things, the session key
as
> input to that function. That sounds pretty straight forward but raises the
> question why we fail to trust the implementer to create random key ids but
> then still trust them to create random keys.
> 
> That's fine for me nevertheless.
> 
> Ciao
> Hannes
> 
> -Original Message-
> From: Jim Schaad [mailto:i...@augustcellars.com]
> Sent: 24 June 2018 10:15
> To: 'Benjamin Kaduk'; 'Mike Jones'
> Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> ace@ietf.org
> Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Thinking things through, I would be more comfortable with something like
> the
> following:
> 
> 1.  Create a confirmation called 'computed key id'.  This has two basic
> values:  What is the computation method?  What is the proof value?  You
can
> optionally have an unprotected KID value used to filter the set of keys on
the
> RS down to a reasonable set to enumerate (hopefully one).
> 
> 2.  For RPK and TLS:  Define a method called hash of SPKI which has a hash
> method as a parameter.  Given that this can be computed independently by
> all entities based on a Public Key value and it will be unique then you
have a
> key identifier that will not have collisions independent of who issues the
> CWT.
> 
> 3.  For PSK and TLS:  Define a method which takes some parameters
including
> the key value, the CWT issuer identity and perhaps some random string and
> compute a proof of possession value on the PSK.
> 
> 4.  For PSK and OSCORE: Define a similar method the question would be what
> the key value is to be used but that can be defined as part of OSCORE
> 
> When using the keys for TLS
> 
> For RPK the key is carried in the handshake and the server/client can
> generate the computed key id and compare it to what the AS distributed.
> The server can identify which CWTs are applicable by either comparison of
> the RPKs or the computed key id.  This means you have a high probability
> that you will not make a mistake and match to the wrong key.
> 
> For PSK the identifier is carried in the handshake which is used to look
up a
> key value and the handshake is performed.  By matching computed key ids
> with the secret value one can ensure to a high probably that only CWTs
that
> reference the same secret are going to be used for permissions even if
they
> come from different AS entities.
> 
> For OSCORE it is similar, the identifier is used to look up a key value
and by
> decrypting the CWT the key value is proofed.  You then match computed key
> ids in the same manner.
> 
> If you really want to have something that is not cryptographically
computed
> and point to something else, then it makes more sense to me to reference a
> CWT issued by the same entity and say "use the same conformation method
> as this CWT does".
> 
> jim
> 
> > -Original Message-
> > From: Benjamin Kaduk 
> > Sent: Saturday, June 23, 2018 11:30 PM
> > To: Mike Jones 
> > Cc: Hannes Tschofenig ; Jim Schaad
> > ;
> > draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> > ace@ietf.org
> > Subject: Re: [Ace] Key IDs ... RE: WGLC on
> > draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > On Fri, Jun 22, 2018 at 08:48:35PM +, Mike Jones wrote:
> > > See my note just now proposing this text to Jim:
> > >
> > > "Likewise, if PoP keys are used for multiple different kinds of CWTs
> > > in
> an
> > application and the PoP keys are identified by Key IDs, care must be
> > taken
> to
&g

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

No Ben, you are 100% correct.  This is about identifiers and not session
keys.

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Tuesday, June 26, 2018 5:14 PM
> To: Hannes Tschofenig 
> Cc: Mike Jones ; Jim Schaad
> ; draft-ietf-ace-cwt-proof-of-possess...@ietf.org;
> ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> I thought we were worried about collision of key *identifiers*, which were
> not necessarily raw keys or hashes thereof.  But it's possible I was not
paying
> enough attention and got confused.
> 
> -Ben
> 
> On Tue, Jun 26, 2018 at 03:12:52PM +, Hannes Tschofenig wrote:
> > It does answer my question, Ben.
> >
> > This begs the question why the collision of session keys is suddenly a
> problem in the ACE context when it wasn't a problem so far. Something must
> have changed.
> >
> > Ciao
> > Hannes
> >
> >
> > -Original Message-
> > From: Benjamin Kaduk [mailto:ka...@mit.edu]
> > Sent: 26 June 2018 17:00
> > To: Hannes Tschofenig
> > Cc: Mike Jones; Jim Schaad;
> > draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org
> > Subject: Re: [Ace] Key IDs ... RE: WGLC on
> > draft-ietf-ace-cwt-proof-of-possession-02
> >
> > On Tue, Jun 26, 2018 at 08:53:57AM +, Hannes Tschofenig wrote:
> > > Ben,
> > >
> > > I was wondering whether the situation is any different in Kerberos. If
the
> KDC creates tickets with a session key included then it needs to make sure
> that it does not create the same symmetric key for different usages.
> > > The key in the Kerberos ticket is similar to the PoP key in our
discussion.
> > >
> > > Are we aware of key collision in Kerberos?
> >
> > I don't believe key collision is an issue in Kerberos.  Long-term keys
> > (which are not what we're talking about here) are identified by a
> > principal name, encryption type, and version number.  Session keys
> > that are contained within tickets (and returned to the client in the
> > KDC-REP) are random, so even if we are only using the birthday bound
> > we're still in pretty good shape.  The modern enctypes tend to use
> > subsession keys generated by the client and/or server as well as the
> > KDC-generated session key, which provides further binding to the current
> session.
> >
> > Does that answer your question?
> >
> > -Ben
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
recipient,
> please notify the sender immediately and do not disclose the contents to
any
> other person, use it for any purpose, or store or copy the information in
any
> medium. Thank you.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Montreal IETF Agenda

[Jim Schaad]

If you want a spot on the agenda please let the chairs know.

Please include topic/draft, presenter and a time request.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Early registration of CoAP Media types for draft-ietf-ace-coap-est

[Jim Schaad]

We have received a request for early registration approval for the media
types in draft-ietf-ace-coap-est.  As part of the input to the decision to
do this we need to know if there are any people who object to proceeding.

If you object please respond either to the list or to the chairs and provide
the reasons why you believe that this early registration should not proceed.
The chairs will make the decision before the Montreal IETF.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

No not really, Hannes's language is much closer to what I am looking for.  I
don't care if they are different kinds of CWTs.  I care about impersonation.

> -Original Message-
> From: Mike Jones 
> Sent: Friday, June 22, 2018 10:44 PM
> To: Jim Schaad ; Hannes Tschofenig
> ; draft-ietf-ace-cwt-proof-of-
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> I think you're looking for language something along these lines, right
Jim?
> 
> "Likewise, if PoP keys are used for multiple different kinds of CWTs in an
> application and the PoP keys are identified by Key IDs, care must be taken
to
> keep the keys for the different kinds of CWTs segregated so that an
attacker
> cannot cause the wrong PoP key to be used by using a valid Key ID for the
> wrong kind of CWT."
> 
>       -- Mike
> 
> -Original Message-
> From: Jim Schaad 
> Sent: Friday, June 22, 2018 7:59 AM
> To: Hannes Tschofenig ; Mike Jones
> ; draft-ietf-ace-cwt-proof-of-
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> That language works if you assume that there is only one CWT that an RS
will
> look to.  If there are multiple CWTs then one needs coordination language
> between them.
> 
> > -Original Message-
> > From: Hannes Tschofenig 
> > Sent: Friday, June 22, 2018 6:36 AM
> > To: Jim Schaad ; 'Mike Jones'
> > ; draft-ietf-ace-cwt-proof-of-
> > possess...@ietf.org
> > Cc: ace@ietf.org
> > Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-
> > possession-02
> >
> > Hi Jim,
> >
> > I would like to comment on this issue.
> >
> > -
> > > > 14.  I have real problems w/ the use of a KID for POP
> > > > identification.  It
> > may
> > > identify the wrong key or, if used for granting access, may have
> > > problems
> > w/
> > > identity collisions.  These need to be spelt out someplace to help
> > > people tracking down questions of why can't I verify w/ this CWT, I
> > > know it's
> > right.
> > >
> > > The Key ID is a hint to help identify which PoP key to use.  Yes, if
> > > a Key
> > ID is
> > > sent that doesn't correspond to the right PoP key, failures may occur.
> > > I
> > view
> > > that as usage bug - not a protocol problem.  If keys aren't
> > > consistently
> > known
> > > and identified by both parties, there are lots of things that can go
> > wrong, and
> > > this is only one such instance.  That said, I can try to say
> > > something
> > about the
> > > need for keys to be consistently and known by both parties, if you
> > > think
> > that
> > > would help.
> >
> > > My problem is that if there are two different people with the same
> > > Key ID,
> > either intentionally or unintentionally, then using the key ID to
> > identify
> the
> > key may allow the other person to masquerade as the first person.  I
> > am unworried about the instance of a failure to get a key based on a key
id.
> > That is not the problem you are proposing to address.
> >
> > -
> >
> > I think we should document this issue. Here is some text proposal that
> could
> > go into a separate operational consideration section (or into the
> > security consideration section instead).
> >
> > "
> > - Operational Considerations
> >
> > The use of CWTs with proof-of-possession keys requires additional
> > information to be shared between the involved parties in order to
> > ensure correct processing. The recipient needs to be able to use
> > credentials to
> verify
> > the authenticity, integrity and potentially the confidentiality of the
> > CWT
> and
> > its content. This requires the recipient to know information about the
> issuer.
> > Like-wise there needs to be an upfront agreement between the issuer
> > and the recipient about the claims that need to be present and what
> > degree of trust can be put into those.
> >
> > When an issuer creates a CWT containing a key id claim, it needs to
> > make sure that it does not issue another CWT containing the same key
> > id with a different content, or for a different subject, within the
> > lifetime of the
> CWTs,
> > unless intentionally desired. Failure to do so may allow one party to
> > impersonate another party with the potential to gain additional
> privileges.
> > "
> >
> >
> > Ciao
> > Hannes
> >
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> > confidential and may also be privileged. If you are not the intended
> recipient,
> > please notify the sender immediately and do not disclose the contents
> > to
> any
> > other person, use it for any purpose, or store or copy the information
> > in
> any
> > medium. Thank you.


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Friday, June 22, 2018 10:44 PM
> To: Hannes Tschofenig 
> Cc: Jim Schaad ; 'Mike Jones'
> ; draft-ietf-ace-cwt-proof-of-
> possess...@ietf.org; ace@ietf.org
> Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> On Fri, Jun 22, 2018 at 01:36:16PM +, Hannes Tschofenig wrote:
> > Hi Jim,
> >
> >
> > > My problem is that if there are two different people with the same
> > > Key ID,
> > either intentionally or unintentionally, then using the key ID to
> > identify the key may allow the other person to masquerade as the first
> > person.  I am unworried about the instance of a failure to get a key
based
> on a key id.
> > That is not the problem you are proposing to address.
> >
> > -
> >
> > I think we should document this issue. Here is some text proposal that
> > could go into a separate operational consideration section (or into the
> security consideration section instead).
> >
> > "
> > - Operational Considerations
> >
> > The use of CWTs with proof-of-possession keys requires additional
> > information to be shared between the involved parties in order to
> > ensure correct processing. The recipient needs to be able to use
> > credentials to verify the authenticity, integrity and potentially the
> confidentiality of the CWT and its content. This requires the recipient to
> know information about the issuer.
> > Like-wise there needs to be an upfront agreement between the issuer
> > and the recipient about the claims that need to be present and what
> degree of trust can be put into those.
> >
> > When an issuer creates a CWT containing a key id claim, it needs to
> > make sure that it does not issue another CWT containing the same key
> > id with a different content, or for a different subject, within the
> > lifetime of the CWTs, unless intentionally desired. Failure to do so may
> allow one party to impersonate another party with the potential to gain
> additional privileges.
> > "
> 
> When would this be "intentionally desired"?  It seems like there would be
> better ways to share authorization between parties than to issue such
> duplicate CWTs.

One case where this is desired is if you issue a second CWT with additional
permissions for a client and you want to tie it to the same key.  You could
either duplicate the key or just reference it by ID.

Jim

> 
> -Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

That language works if you assume that there is only one CWT that an RS will
look to.  If there are multiple CWTs then one needs coordination language
between them.

> -Original Message-
> From: Hannes Tschofenig 
> Sent: Friday, June 22, 2018 6:36 AM
> To: Jim Schaad ; 'Mike Jones'
> ; draft-ietf-ace-cwt-proof-of-
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: Key IDs ... RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-
> possession-02
> 
> Hi Jim,
> 
> I would like to comment on this issue.
> 
> -
> > > 14.  I have real problems w/ the use of a KID for POP
> > > identification.  It
> may
> > identify the wrong key or, if used for granting access, may have
> > problems
> w/
> > identity collisions.  These need to be spelt out someplace to help
> > people tracking down questions of why can't I verify w/ this CWT, I
> > know it's
> right.
> >
> > The Key ID is a hint to help identify which PoP key to use.  Yes, if a
> > Key
> ID is
> > sent that doesn't correspond to the right PoP key, failures may occur.
> > I
> view
> > that as usage bug - not a protocol problem.  If keys aren't
> > consistently
> known
> > and identified by both parties, there are lots of things that can go
> wrong, and
> > this is only one such instance.  That said, I can try to say something
> about the
> > need for keys to be consistently and known by both parties, if you
> > think
> that
> > would help.
> 
> > My problem is that if there are two different people with the same Key
> > ID,
> either intentionally or unintentionally, then using the key ID to identify
the
> key may allow the other person to masquerade as the first person.  I am
> unworried about the instance of a failure to get a key based on a key id.
> That is not the problem you are proposing to address.
> 
> -
> 
> I think we should document this issue. Here is some text proposal that
could
> go into a separate operational consideration section (or into the security
> consideration section instead).
> 
> "
> - Operational Considerations
> 
> The use of CWTs with proof-of-possession keys requires additional
> information to be shared between the involved parties in order to ensure
> correct processing. The recipient needs to be able to use credentials to
verify
> the authenticity, integrity and potentially the confidentiality of the CWT
and
> its content. This requires the recipient to know information about the
issuer.
> Like-wise there needs to be an upfront agreement between the issuer and
> the recipient about the claims that need to be present and what degree of
> trust can be put into those.
> 
> When an issuer creates a CWT containing a key id claim, it needs to make
> sure that it does not issue another CWT containing the same key id with a
> different content, or for a different subject, within the lifetime of the
CWTs,
> unless intentionally desired. Failure to do so may allow one party to
> impersonate another party with the potential to gain additional
privileges.
> "
> 
> 
> Ciao
> Hannes
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
recipient,
> please notify the sender immediately and do not disclose the contents to
any
> other person, use it for any purpose, or store or copy the information in
any
> medium. Thank you.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Review of draft-ietf-ace-oauth-authz -12

[Jim Schaad]

I sent this review early by accident (I thought I was sending a different mail).

 

However a couple things below.

 

 

From: Samuel Erdtman  
Sent: Thursday, June 21, 2018 8:15 AM
To: Jim Schaad 
Cc: draft-ietf-ace-oauth-au...@ietf.org; ace 
Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz -12

 

Thanks for reviewing, some answers inline

 

On Tue, Jun 19, 2018 at 8:05 PM, Jim Schaad mailto:i...@augustcellars.com> > wrote:

Based on where I currently am, here is another review of the document.

1.  In section 4 for Figure one:  Is the term "RS Information" your term or
an OAuth term.  When I see this I think of it as information for not about
the RS which I do not believe is the intent.

 

No, the intent is information about the RS for the client. It is described in 
"2. Terminology".

Not sure if "client information" would be preferable. 

 

[JLS] Yeah I agree that ‘client information’ is not really any better.  I 
wonder if ‘Access Information’ might be a better term?

 

 


2.  In section 5.1 - I am unclear what the second paragraph is supposed to
be doing here.  I think that you want state this different.  Rather than
talking about the "desired resource" you may want to talk about the AS.
That would better match the title of the section.

 

The focus could maybe be different but the text is about how to find the AS but 
the method for that is quite RS focused.

 

[JLS] This is not clear to me from what is stated.  Does this mean that there 
is going to be AS pointers that are contained on the RD entry for the resource 
that one is interested in?  If that is the case then a pointer to where those 
fields are (going) to be defined would be useful.  I read this as searching the 
RD for an AS directly.

 


3.  In section 5.1 - There is a note in this section that does not seem to
be extremely useful.  Where is this discussion go on?  Is it still going on?
I am not even sure if the statement about a common understanding of time is
correct?  It seems that one can either add or not add the nonce as an RS
depending on if you think you understand a common time.

 

I have not heard anything on the time discussion for a while.

 


4.  In section 5.3 - There is a reference to I-D.erdtman-ace-rpcc.  Given
the use of POP tokens, what is the reason for this draft and the text about
client credential types?  (Put it this way.  I did not need to implement
this for anything yet.  Why is it here?)

 

Not sure what profile you have implemented.

I-D.erdtman-ace-rpcc defines how the client can use Raw Public Key or Pre 
Shared Key with (D)TLS to authenticate it self to the AS. It is not a strange 
operation so you might have implemented it without thinking about it (Ludwig 
kind of did). I-D.erdtman-ace-rpcc is similar to draft-ietf-oauth-mtls that 
defines what was already done in the wild when it comes to x509 certificates 
and client authentication.

Or you might have used default client credentials (client_id/username and 
client_secret/password).

 

I think writing about client credentials is needed since the ACE use cases so 
far has been client centric, i.e. the client is often described to authenticate 
as it self to get a token and not as is common i OAuth the user is 
authenticated and authorizes the client to get a token.

With that said the reference to I-D.erdtman-ace-rpcc should maybe be removed 
since interest in I-D.erdtman-ace-rpcc has been very limited.

 

[JLS] I am implementing all of my credentials as being something that is either 
a) cooked in to the device or b) as a COSE Key which is part of a database 
which is read up by the program.  As such I do not believe I am using anything 
from this draft.  Part of what I am trying to figure out here is what the 
status of this document is and what dependencies the Authz document has one it. 
 Is it really informational?  What does it do for the Authz document to have it 
referenced?  Should this document be pushed up to a WG document because it is 
really needed?   My understanding from RFC6749 is that these are client 
credentials that are being used in the HTTP authentication rather then the TLS 
client auth layer below HTTP.   On the other hand this is not completely clear.

 



[JLS] These are not finished questions – not surprised you did not respond.

 

Jim



Given 15 different introspection tokens, how do I decide which is the one to
present to the AS - enumerate them?

'authorization code' vs 'decode code' grants


___
Ace mailing list
Ace@ietf.org <mailto:Ace@ietf.org> 
https://www.ietf.org/mailman/listinfo/ace

 

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Early media-type registration for EST over CoAP

[Jim Schaad]

That sounds like a good plan forward.  Are you also going to need an early 
registration on the multipart-core draft as well?

 

Jim

 

 

From: Peter van der Stok  
Sent: Wednesday, June 20, 2018 3:07 AM
To: Carsten Bormann 
Cc: Hannes Tschofenig ; core ; 
ace@ietf.org; Jim Schaad ; r...@cert.org
Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP

 

HI Carsten, Jim

Just to get this clear.

We will update the the est-coaps draft by referring to 
draft-fossati-core-multipart-ct-05 
<https://datatracker.ietf.org/doc/draft-fossati-core-multipart-ct/>  for the 
wanted early registration of the content formats specified in est-coaps.
Once done, we direct a request for early registration of the content-format 
values to the ACE chairs.
Although the corresponding media formats have not been allocated yet for 
multipart-ct draft, the corresponding content-format numbers can be allocated 
already.

Is that the approved plan?

Please confirm or specify the conditions on multipart-ct draft.

Many thanks for your understanding,

Peter

Carsten Bormann schreef op 2018-06-19 14:22:

On Jun 19, 2018, at 14:11, Carsten Bormann mailto:c...@tzi.org> 
> wrote: 


Since the registry that we are registering into does not fulfill the 
preconditions of RFC 7120 Section 2 point (a),


(Sorry, wasn't awake enough.  If we go for the 256- space, of course it 
does.  And we probably do.)

So we'll have to follow the process according to Section 3 of RFC 7120.

Starting with point (1) of Section 3.1:

   1.  The authors (editors) of the document submit a request for early
   allocation to the Working Group chairs, specifying which code
   points require early allocation and to which document they should
   be assigned.

Grüße, Carsten

___
core mailing list
c...@ietf.org <mailto:c...@ietf.org> 
https://www.ietf.org/mailman/listinfo/core

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Review of draft-ietf-ace-oauth-authz -12

[Jim Schaad]

Based on where I currently am, here is another review of the document.

1.  In section 4 for Figure one:  Is the term "RS Information" your term or
an OAuth term.  When I see this I think of it as information for not about
the RS which I do not believe is the intent.

2.  In section 5.1 - I am unclear what the second paragraph is supposed to
be doing here.  I think that you want state this different.  Rather than
talking about the "desired resource" you may want to talk about the AS.
That would better match the title of the section.

3.  In section 5.1 - There is a note in this section that does not seem to
be extremely useful.  Where is this discussion go on?  Is it still going on?
I am not even sure if the statement about a common understanding of time is
correct?  It seems that one can either add or not add the nonce as an RS
depending on if you think you understand a common time.

4.  In section 5.3 - There is a reference to I-D.erdtman-ace-rpcc.  Given
the use of POP tokens, what is the reason for this draft and the text about
client credential types?  (Put it this way.  I did not need to implement
this for anything yet.  Why is it here?)




Given 15 different introspection tokens, how do I decide which is the one to
present to the AS - enumerate them?

'authorization code' vs 'decode code' grants


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Early media-type registration for EST over CoAP

[Jim Schaad]

> -Original Message-
> From: Ace  On Behalf Of Michael Richardson
> Sent: Tuesday, June 19, 2018 7:33 AM
> To: core ; ace@ietf.org
> Subject: Re: [Ace] [core] Early media-type registration for EST over CoAP
> 
> 
> Carsten Bormann  wrote:
> > On Jun 19, 2018, at 14:11, Carsten Bormann  wrote:
> >>
> >> Since the registry that we are registering into does not fulfill the
> >> preconditions of RFC 7120 Section 2 point (a),
> 
> > (Sorry, wasn’t awake enough.  If we go for the 256- space, of
> > course it does.  And we probably do.)
> 
> yes, we were perfectly happy with that space.
> 
> > So we’ll have to follow the process according to Section 3 of RFC 7120.
> 
> > Starting with point (1) of Section 3.1:
> 
> >1.  The authors (editors) of the document submit a request for early
> > allocation to the Working Group chairs, specifying which code points
> > require early allocation and to which document they should be assigned.
> 
> I thought ACE co-chairs already gave consent, but looking in the archives, I
> see that this isn't actually so.
> 
>Jim? Roman?  DO YOU CONSENT?

I do not believe that I have ever seen a formal request directed at me for this.

Jim

> 
> We have already had some round trips and document changes thanks to
> Klaus Hartke.
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Contact Info for ACE Interop Event tomorrow

[Jim Schaad]

We will go ahead and use a webex meeting for the interop event tomorrow



JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=m1e4d4e3b7a8f81354335d9be30dc3687
Meeting number (access code): 640 485 375 Host key: 770328 Meeting password:
DEGrDby3



JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)



Can't join the meeting? Contact support here:
https://ietf.webex.com/ietf/mc


IMPORTANT NOTICE: Please note that this WebEx service allows audio and other
information sent during the session to be recorded, which may be
discoverable in a legal matter. You should inform all meeting attendees
prior to recording if you intend to record the meeting.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

> -Original Message-
> From: Hannes Tschofenig <hannes.tschofe...@arm.com>
> Sent: Wednesday, May 23, 2018 12:55 PM
> To: Jim Schaad <i...@augustcellars.com>; draft-ietf-ace-cwt-proof-of-
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
> 
> Hi Jim,
> 
> A few remarks below.
> 
> -Original Message-
> From: Jim Schaad [mailto:i...@augustcellars.com]
> Sent: 09 May 2018 05:51
> To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
> 
> I'll pull out the list of comments that I wrote a month ago but didn't
start that
> computer up recently.
> 
> 1.  Are all of the authors necessary?  As a chair I need to justify a
count of
> more than 5 to the IESG.
> 
> [Hannes] As mentioned by Mike already, this was the result of a draft
> merger. The text initially came from an OAuth document (since this work
had
> its history in the OAuth WG).
> 
> 2.  Is the last sentence in section 1 necessary?  Are you actually
defining any
> strings that could be case-sensitive?
> 
> [Hannes] I think we could get rid of that sentence.
> 
> 3.  Terminology: In the definition of Issuer please make 'its' clearer.
It is not
> clear whose claims are being bound.
> 
> [Hannes] How about:
> 
>Issuer
>   Party that creates the CWT and binds the claims to the proof-of-
>   possession key.

It's better - 'binds claims about the subject' might be clearer

> 
> 
> 4.  Terminology: I still think this is 'Presenter' is a very strange term
to use for
> this definition.  I would really like to see it be made something that
makes
> sense and then say the term is the same as this in JWT.  The term has a
> model of use with it that I do not believe can be sustained even for the
ACE
> Oauth case but really not in other cases.
> 
> [Hannes] It is a strange term but we used it also in the OAuth JWT PoP
> document and hence it wouldn't make sense to change it now.

If you really cannot change the term, then it might make sense to add some
description of other terminology that others might be familiar with.

> 
> 5.  Terminology: Recipient matches presenter, and it matches the OAuth
> model
> and not a trust model world.   Relying party or service provider make far
> more sense to me.
> 
> [Hannes] Same comment as above. I prefer to be in alignment with the
> OAuth work here. I am wondering whether we should also copy the figures
> from Section 1 of https://tools.ietf.org/html/rfc7800 to make the
> architecture clearer.
> 
> 6.  Under what circumstances would a 'sub' claim be present and it is not
the
> presenter?  I can see that a holder of the key may be implicitly (or
> anonymously) named, but putting something in the subject field which is
not
> identifying the presenter is something that I would reject without a good
> presentation of why in the document.
> 
> [Hannes] Mike provided his perspective on this issue already. CWT is
similar
> to JWT a somewhat flexible building block. What claims should, must or may
> be included in a given deployment depends a bit on the use case. Not
> including the subject claim may be useful for privacy purposes, for
example.
> In other cases you definitely want to convey that information.

I completely agree with your last sentence.  The sub would be omitted
because of privacy or not needed.  However having the subject be present and
the subject not being the presenter seems to be a very strange concept.
Here is a token issued by A where the subject is B and the key is held by C.

> 
> 7.  I would disagree with the claim that if the 'sub' claim is missing
then it
> would normally be the issuer.  For the world of IoT, I would expect that
the
> subject would not be present because there is no need to identify the
> subject to the recipient.  I.e. it is an anonymous subject.
> 
> [Hannes] I am not sure that this is always the case in an IoT deployment.
For
> example, imagine if a technician accesses some industrial device then I
want
> to have the information about the person accessing those devices in my
> audit trail.

I could easily be wrong about the subject claim not being absent more often
that not.  However that still does not mean it would normally be about the
issuer rather than an anonymous subject.

> 
> 8.  It is not clear to me that either of the sub and iss claims would
normally be
> present.  They might be present but neither is needed.  The subject can be
> anonymous and the issuer is identified by the key used to validate the
> security on the CWT.
> 
> [Hannes] In many deployments they may well not be present. That's
> completely fin

Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Jim Schaad]

I have removed items where the proposed solution is probably sufficient.

> -Original Message-
> From: Mike Jones <michael.jo...@microsoft.com>
> Sent: Sunday, May 20, 2018 4:34 AM
> To: Jim Schaad <i...@augustcellars.com>; draft-ietf-ace-cwt-proof-of-
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
> 
> Thanks for your useful comments, Jim.  Replies are inline below.
> 
> -Original Message-
> From: Jim Schaad <i...@augustcellars.com>
> Sent: Wednesday, May 9, 2018 6:51 AM
> To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
> 
> I'll pull out the list of comments that I wrote a month ago but didn't
start that
> computer up recently.
> 
> 1.  Are all of the authors necessary?  As a chair I need to justify a
count of
> more than 5 to the IESG.
> 
> The authors are the union of the set of authors of draft-jones-ace-cwt-
> proof-of-possession-00 and draft-ietf-ace-oauth-authz-04, which both
> contained independently developed and largely parallel treatments of the
> CWT PoP confirmation subject.  Ludwig was the primary author of this text
in
> the second, so he should definitely be retained as an editor.  I'll leave
it up to
> the other authors of draft-ietf-ace-oauth-authz-04 to self-identify
whether
> they materially contributed to the CWT PoP confirmation text or not.
Maybe
> we can delete those who don't self-identify as contributors.
> 
> 4.  Terminology: I still think this is 'Presenter' is a very strange term
to use for
> this definition.  I would really like to see it be made something that
makes
> sense and then say the term is the same as this in JWT.  The term has a
> model of use with it that I do not believe can be sustained even for the
ACE
> Oauth case but really not in other cases.
> 
> This is the standard term for this role in the industry.  For instance,
Section
> 1.2 (Terminology) of "SAML V2.0 Holder-of-Key Assertion Profile Version
1.0"
> http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-of-key-
> cd-01.pdf defines "Presenter" with an equivalent meaning.
> 
> Also, for this reason, this is the same terminology used for this role in
RFC
> 7800.  It is used pervasively throughout both this document and RFC 7800 -
> including in the diagrams in the introduction of RFC 7800.  I believe we
would
> be doing a disservice to readers and implementers if we were to use a
> different term from that in RFC 7800 (and SAML) when the meaning is
> identical.
> 
> 5.  Terminology: Recipient matches presenter, and it matches the OAuth
> model
> and not a trust model world.   Relying party or service provider make far
> more sense to me.
> 
> Same response as to 4.  We owe it to readers and implementers to keep the
> terminology consistent with RFC 7800 and industry practice.
> 
> 6.  Under what circumstances would a 'sub' claim be present and it is not
the
> presenter?  I can see that a holder of the key may be implicitly (or
> anonymously) named, but putting something in the subject field which is
not
> identifying the presenter is something that I would reject without a good
> presentation of why in the document.
> 
> Just as in https://tools.ietf.org/html/draft-ietf-secevent-token-13 (which
is
> in the hands of the RFC Editor), it's dependent upon the profiling
> specification how the "sub" claim is used.  In some cases the subject
and/or
> presenter will be identified with some combination of "iss" and/or "sub".
In
> other profiles, different representations will be appropriate, such as the
use
> of the "subject_type" value in the RISC example in
> https://tools.ietf.org/html/draft-ietf-secevent-token-13#section-2.1.4.
> 
> Remember that in both JWT and CWT, the inclusion of *all* claims is left
up
> to the profile.  The same is true of RFC 7800 and this spec (other than
the use
> of the "cnf" claim).  We shouldn't tie the hands of profiles in a way that
> prevents them from using the representation of the presenter that is most
> natural for their use case.

I think you have done a good job of arguing my case that this is something
that should be removed.  If it is appropriate to a specific profile then
that should be stated in that profile and not in the general document.

> 
> 7.  I would disagree with the claim that if the 'sub' claim is missing
then it
> would normally be the issuer.  For the world of IoT, I would expect that
the
> subject would not be present because there is no need to identify the
> subject to the recipient.  I.e. it is an anonymous subject.
> 
> I'

Re: [Ace] OAuth-Authz Interop

[Jim Schaad]

We are going to go with

May 30  07:00 PDT  (14:00 UTC) 

If there is anyone who has an IPv6 only client, please let me know as I will
need to get tunneling setup for my server.  (An IPv6 only server is not a
problem.)

Ludwig, we made some changes to the document at the last F2F meeting.  It
would be nice to get those changes published.

Jim


> -Original Message-
> From: Ace <ace-boun...@ietf.org> On Behalf Of Ludwig Seitz
> Sent: Tuesday, May 15, 2018 6:47 AM
> To: ace@ietf.org
> Subject: Re: [Ace] OAuth-Authz Interop
> 
> On 2018-05-07 18:44, Jim Schaad wrote:
> > I have been meaning to get this out for a while and have failed.  A
> > doodle poll to setup an interop event for this work is at
> > https://doodle.com/poll/k27g9r26bghvnytu If you want to participate
> > and none of the times are good please let me know.
> >
> > Things for testing:
> > 1)  DTLS profile w/ shared secret
> > 2)  DTLS profile w/ RPK
> > 3)  OSCORE profile
> >
> 
> The dates Jim has proposed in the doodle are quite close already, and the
> poll is still quite empty. Is there any specific reason why the other
> implementers won't/cannot commit to this at this point in time?
> 
> /Ludwig
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE SICS
> Phone +46(0)70-349 92 51
> 
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] OAuth-Authz Interop

[Jim Schaad]

Given that we have already started doing interop work and were successful 
needing to address the number assignment issues does not seem to be a blocking 
problem.  As long as all of the people doing the interop testing are agreed on 
what numbers should be there do not seem to be any issues in testing.  The only 
problem would be if there was a decision to ship products before the 
assignments were finalized.  

 

In terms of what size of items to use, this is going to be an interesting 
argument and one that needs to be finalized at some point.  However, it would 
be just as easy to remove the sentence as to change the values so there are 
multiple ways of solving this issue.  I don’t know that I agree that 
application-specific claim keys should be pushed all of the way up to 256, 
there is always going to be a trade off at this point in terms of what size of 
key to use vs how often it is believed that the key is going to be used.  If we 
believe that a huge percentage of usage in the IoT world for CWT items is going 
to be for this type of authorization and we want to keep alignment to the 
extent possible then it still makes sense to use the 1 or 2 byte keys for this 
purpose.  (Side node, it is normal to include all of the bytes encoded in the 
length so 256 would be a 3 byte value).  This is a trade off that needs to be 
discussed, but is not currently blocking.

 

Jim

 

 

From: Ace <ace-boun...@ietf.org> On Behalf Of Mike Jones
Sent: Tuesday, May 8, 2018 10:40 AM
To: Ludwig Seitz <ludwig.se...@ri.se>; ace@ietf.org
Subject: Re: [Ace] OAuth-Authz Interop

 

Before any interop work is done, I suggest that it would be better to first 
address the significant CBOR number assignment issues I pointed out in my 
review on October 10, 2017 
https://www.ietf.org/mail-archive/web/ace/current/msg02364.html, so that the 
interop is more likely to occur using number assignments that are less likely 
to change.  I'm repeating the most important of these comments below, since it 
was apparently not acted upon.

 

5.5.5 Mapping parameters to CBOR

It looks to me like these values are intended to align with those registered in 
the CBOR Web Token (CWT) Claims registry initially populated by 
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08#section-9.1.2.  If 
so, the spec should make this relationship explicit.  However, it would be 
inappropriate to use the rare single-byte CBOR integer values for 
application-specific claim keys.  I would suggest that the claim identifiers 
for client_id through refresh_token and profile start at 256 (a two-byte CBOR 
value) and go up from there.  In that case, I suspect they could be 
successfully registered in the CWT Claims registry – which I think you want.  
(“cnf” will already be registered by draft-ietf-ace-cwt-proof-of-possession.)

 

Likewise, please search the review for all instances of the words “register” 
and “registry” and revised the spec accordingly before any interop work is 
started.

 

-- Mike

 

 

-Original Message-
From: Ace <ace-boun...@ietf.org <mailto:ace-boun...@ietf.org> > On Behalf Of 
Ludwig Seitz
Sent: Tuesday, May 8, 2018 3:54 AM
To: ace@ietf.org <mailto:ace@ietf.org> 
Subject: Re: [Ace] OAuth-Authz Interop

 

On 2018-05-08 08:57, Ludwig Seitz wrote:

> On 2018-05-07 18:44, Jim Schaad wrote:

>> I have been meaning to get this out for a while and have failed.  A 

>> doodle poll to setup an interop event for this work is at 

>>  <https://doodle.com/poll/k27g9r26bghvnytu> 
>> https://doodle.com/poll/k27g9r26bghvnytu If you want to participate 

>> and none of the times are good please let me know.

>> 

>> Things for testing:

>> 1)  DTLS profile w/ shared secret

>> 2)  DTLS profile w/ RPK

>> 3)  OSCORE profile

>> 

>> 

> 

> Note that I'm in the process of writing a test manual, I'll put it up 

> on the WG github as soon as it has some form and structure. Feel free 

> to contribute. I'm hoping to have it online by the end of the day.

> 

> /Ludwig

> 

> 

 

You can find my first draft of the interop manual here:

 

 <https://github.com/ace-wg/ace-oauth/blob/master/InteropTestPlan.txt> 
https://github.com/ace-wg/ace-oauth/blob/master/InteropTestPlan.txt

 

Note that large parts are still work in progress, but the test plan for the 
token endpoint should give you a hint as to how I was thinking it could work.

 

Feel free to propose changes and improvements.

 

 

/Ludwig

 

--

Ludwig Seitz, PhD

Security Lab, RISE SICS

Phone +46(0)70-349 92 51

 

___

Ace mailing list

 <mailto:Ace@ietf.org> Ace@ietf.org

 <https://www.ietf.org/mailman/listinfo/ace> 
https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] OAuth-Authz Interop

[Jim Schaad]

I have been meaning to get this out for a while and have failed.  A doodle
poll to setup an interop event for this work is at
https://doodle.com/poll/k27g9r26bghvnytu If you want to participate and none
of the times are good please let me know.

Things for testing:
1)  DTLS profile w/ shared secret
2)  DTLS profile w/ RPK
3)  OSCORE profile



___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] draft-ietf-ace-coap-est-00

[Jim Schaad]

I agree with Hannes, this version of the document is much cleaner and much
clearer.  I think that it has solved most of the problems that I initially
had with the draft.  It is not ready to progress as there are still sections
that are marked as TODO.  But it is much closer to finishing that it was.

I still have a couple of comments from a quick read through of the document.

In section 2 - There will be a problem in that the port format extension is
being eliminated in TLS 1.3 - We may want to divide this into a 1.2 and 1.3
section for clarity.

In section 3- Should we be looking at the use of COSE rather than CMS for
encryption of key services?

*  Do you have the option to additionally support the long name for the
service as well as the short name?  MUST have short name MAY have long name?

*  In section 6- All proxies are required by CoAP blocking to re-assemble
the entire message at the proxy.  It can re-block things going to the next
proxy.  While there is no requirement that the proxy get the entire message
before sending on pieces, this should be common practice and would be
required for a CoAP/HTTP proxy.

* Should probably add a note in section 6 that any proxy that terminates the
DTLS connection is going to be required to act as an RA.  RAs are required
to have the entire request for adding authentication as necessary.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-13: (with COMMENT)

[Jim Schaad]

It might make more sense to prefix the JWT versions as not being what is
here.

Jim


> -Original Message-
> From: Mike Jones [mailto:michael.jo...@microsoft.com]
> Sent: Wednesday, March 7, 2018 9:47 PM
> To: Benjamin Kaduk ; Adam Roach 
> Cc: The IESG ; draft-ietf-ace-cbor-web-to...@ietf.org; ace-
> cha...@ietf.org; ace@ietf.org
> Subject: RE: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-
> 13: (with COMMENT)
> 
> Thanks, Ben and Adam.  I've recoded a note to address the improvements
> below one the submission tool reopens.
> 
> For what it's worth, I independently noticed the unintended overlap
> between the Standards Action and Specification Required number ranges in
> a conversation today with IANA.
> 
> The point of including new CWT definitions for "StringOrURI" and
> "NumericDate" was so that we could use them directly.  Prefixing them with
> "CWT" isn't necessary for the meaning to be clear in context.
> 
> Thanks both for the attention to detail.
> 
>   -- Mike
> 
> -Original Message-
> From: Benjamin Kaduk 
> Sent: Wednesday, March 7, 2018 8:24 PM
> To: Adam Roach 
> Cc: The IESG ; draft-ietf-ace-cbor-web-to...@ietf.org; ace-
> cha...@ietf.org; ace@ietf.org
> Subject: Re: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token-
> 13: (with COMMENT)
> 
> Hi Adam,
> 
> With my shepherd hat...
> 
> On Wed, Mar 07, 2018 at 04:05:32PM -0800, Adam Roach wrote:
> >
> > Thanks to the WG, chairs, and
> >
> > §3.1.1:
> >
> > >  The "iss" (issuer) claim has the same meaning and processing rules
> > > as  the "iss" claim defined in Section 4.1.1 of [RFC7519], except
> > > that  the value is of type StringOrURI.  The Claim Key 1 is used to
> > > identify this claim.
> >
> >
> > 1) Given that RFC 7159 defines "iss" to contain a "StringOrURI" value,
it's
> >not clear what the "except" clause is attempting to convey.
> 
> I had to ask about this as well -- the crux is that the "StringOrURI" JWT
type is
> different from the CWT "StringOrURI"
> type.  IIRC there used to be an extra descriptor in here but it was
removed as
> redundant.
> 
> > 2) Given the many uses of the word "type" in this context (including
CBOR
> >types and the JWT 'typ' field), and given that RFC 7519 never refers
to
> >"StringOrURI" as a "type," I think that the use of the word "type"
here
> >is likely to lead to reader confusion.
> 
> In combination with the above, maybe we want "the value is a CWT
> StringOrURI value".  Authors?
> 
> > This comment -- or a congruent form of it involving "NumericDate"
> > rather than "StringOrURI" -- applies to §3.1.2 through §3.1.6.
> 
> (Right.)
> 
> > --
> > -
> >
> > §9.1:
> >
> > >  Criteria that should be applied by the Designated Experts includes
> > > determining whether the proposed registration duplicates existing
> > > functionality, whether it is likely to be of general applicability
> > > or  whether it is useful only for a single application, and whether
> > > the  registration description is clear.  Registrations for the
> > > limited set  of values between -256 and 255 and strings of length 1
> > > are to be  restricted to claims with general applicability.
> >
> > Use of the word "between" without qualifying it as inclusive or
> > exclusive of the endpoints is ambiguous. Suggest either "values from
> > -256 to 255" or "values between -256 and 255 inclusive".
> 
> Agreed, it should be qualified as inclusive.
> 
> > --
> > -
> >
> > §9.1.1:
> >
> > > CBOR map key for the claim.  Different ranges of values use
> > > different registration policies [RFC8126].  Integer values between
> > > -256 and 255 and strings of length 1 are designated as Standards
> > > Action.  Integer values from -65536 to 65535 and strings of length
> > > 2 are designated as Specification Required
> >
> > Same comment as above.
> >
> > Also, please replace "from -65536 to 65535" with "from -65536 to -257
> > and from
> > 256 to 65535".
> 
> Good catch!
> 
> Thanks,
> 
> Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-cbor-web-token-12: (with COMMENT)

[Jim Schaad]

> -Original Message-
> From: Alexey Melnikov [mailto:aamelni...@fastmail.fm]
> Sent: Sunday, March 4, 2018 1:01 PM
> To: Jim Schaad <i...@augustcellars.com>; The IESG <i...@ietf.org>
> Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org;
> ka...@mit.edu; ace@ietf.org
> Subject: Re: Alexey Melnikov's No Objection on draft-ietf-ace-cbor-web-
> token-12: (with COMMENT)
> 
> On Sun, Mar 4, 2018, at 7:39 PM, Jim Schaad wrote:
> > IANA does ask for the expert review as part of the processing it does
> > even for standards track documents.  This is because, in part, they
> > are responsible for doing the final number assignment.  That is which
> > number in the range is actually used.  The interesting question would
> > be what happens if the IESG and the DEs disagree about such things.
> 
> This is exactly why I am asking about this. It might also possible to game the
> system to ask IESG approval of a Proposed Standard that bypasses Expert
> Review.

Interesting.  The text that IANA and I finally agreed to for the COSE Algorithm 
registry is "Standards Action With Expert Review".

That would make sure that it cannot bypass the Expert Review.

Jim

> 
> >  I would
> > expect that this would result in a long discussion with some type of
> > final agreement between them.
> >
> > Jim
> >
> >
> > > -Original Message-
> > > From: Alexey Melnikov [mailto:aamelni...@fastmail.fm]
> > > Sent: Sunday, March 4, 2018 11:19 AM
> > > To: The IESG <i...@ietf.org>
> > > Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org;
> > > ka...@mit.edu; ace@ietf.org
> > > Subject: Alexey Melnikov's No Objection on
> > > draft-ietf-ace-cbor-web-token-
> > > 12: (with COMMENT)
> > >
> > > Alexey Melnikov has entered the following ballot position for
> > > draft-ietf-ace-cbor-web-token-12: No Objection
> > >
> > > When responding, please keep the subject line intact and reply to
> > > all email addresses included in the To and CC lines. (Feel free to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/
> > >
> > >
> > >
> > > 
> > > --
> > > COMMENT:
> > > 
> > > --
> > >
> > > Just to double check: a CWT claim registration from a Proposed
> > > Standard still needs to be submitted to the review mailing list, but
> > > it is not really subject to Expert Review, correct? You might want to make
> it clearer.
> >
> >

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-cbor-web-token-12: (with COMMENT)

[Jim Schaad]

IANA does ask for the expert review as part of the processing it does even for 
standards track documents.  This is because, in part, they are responsible for 
doing the final number assignment.  That is which number in the range is 
actually used.  The interesting question would be what happens if the IESG and 
the DEs disagree about such things.  I would expect that this would result in a 
long discussion with some type of final agreement between them.

Jim


> -Original Message-
> From: Alexey Melnikov [mailto:aamelni...@fastmail.fm]
> Sent: Sunday, March 4, 2018 11:19 AM
> To: The IESG 
> Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace-cha...@ietf.org;
> ka...@mit.edu; ace@ietf.org
> Subject: Alexey Melnikov's No Objection on draft-ietf-ace-cbor-web-token-
> 12: (with COMMENT)
> 
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-ace-cbor-web-token-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Just to double check: a CWT claim registration from a Proposed Standard still
> needs to be submitted to the review mailing list, but it is not really 
> subject to
> Expert Review, correct? You might want to make it clearer.


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Agenda Items for London

[Jim Schaad]

Please let the chairs know if you want a slot on the agenda for London.
Please give us an idea of what you think you need to cover, how long you
think it will take and who is doing the presentations.

For people doing the presentations, I would like to get slides during the
week of March 12th so that the chairs can do a fast review and get them
posted before the Monday morning meeting.  I really do not want to need to
do this first thing Monday morning.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Adoption of draft-vanderstok-ace-est

[Jim Schaad]

Looking at the mailing list, it appears that the working group thinks that
the document should be adopted.  Peter, please republish the document as an
ACE working group document and I will then approve it.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Jim Schaad]

 

 

From: Dan Romascanu [mailto:droma...@gmail.com] 
Sent: Tuesday, February 27, 2018 2:23 PM
To: Jim Schaad <i...@augustcellars.com>
Cc: Benjamin Kaduk <ka...@mit.edu>; gen-art <gen-...@ietf.org>; 
draft-ietf-ace-cbor-web-token@ietf.org; ietf <i...@ietf.org>; ace@ietf.org
Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

 

Hi Jim,

There are still a few problems: 

1. The policies and mapping to the values ranges are hidden in the Claim Key 
field in the template (the comment also made by Kathleen)

[JLS] True, but not an issue as far as I am concerned.  I am totally neutral 
about moving this up a level (I don’t really like duplication).

2. At least one incorrect policy name is used: Standards Track Required - do 
you mean Standards Action (?)

[JLS] Yes, I missed that although I assume IANA would have complained about it.

3. You describe a process that involves a mail list (cwt-reg-rev...@ietf.org 
<mailto:cwt-reg-rev...@ietf.org> ) and Experts Review. This description is not 
clear. Usually IANA approaches one DE for advice and expects the advice from 
the same DE in a reasonable period of time. If I understand correctly the 
process described in Section 9.1 one or more DEs make a recommendation and run 
it with the mail list. Who establishes the consensus on the mail list? Assuming 
the mail list disagrees with the DE recommendation, who decides?

[JLS] The process is not one that I would have described, but is the one that 
Mike has used for the documents that he has written.  The time period was a 
response to the time out issues that the IESG was trying to address at the 
time.  I have always assumed that the email list was intended to function in 
the same way as the announce list for media types would be done.  In practice 
IANA has sent requests to the list for JOSE with a request for review and a 
request about how the review is to be handled by the set of DEs on the list.   
My assumption is the set of DEs would define how the consensus is reached and 
it might change both over time and as the set of DEs changes.

Jim

Regards,

Dan

 

On Tue, Feb 27, 2018 at 7:53 PM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

Integer values between -256 and 255 and strings of length 1 are designated as 
Standards Track Required.

 

Integer values from -65536 to 65535 and strings of length 2 are designated as 
Specification Required.

 

Integer values of greater than 65535 and strings of length greater than 2 are 
designated as Expert Review.  

 

Integer values less than -65536 are marked as Private Use.

 

So that says what IANA policy is to be used for each of the different items.  
This defines the policies and the ranges for those policies.

 

There is not anything that is making a distinction on what the criteria to be 
used by the DE in the document which is separate, but I don’t think that is 
needed.  This is why they are DEs.

 

I still don’t see what you think is missing.

 

Jim

 

 

From: Dan Romascanu [mailto:droma...@gmail.com <mailto:droma...@gmail.com> ] 
Sent: Tuesday, February 27, 2018 2:00 AM
To: Benjamin Kaduk <ka...@mit.edu <mailto:ka...@mit.edu> >
Cc: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> >; 
gen-art <gen-...@ietf.org <mailto:gen-...@ietf.org> >; 
draft-ietf-ace-cbor-web-token@ietf.org 
<mailto:draft-ietf-ace-cbor-web-token@ietf.org> ; ietf <i...@ietf.org 
<mailto:i...@ietf.org> >; ace@ietf.org <mailto:ace@ietf.org> 
Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

 

Hi,

See also my other notes. 

I believe that what the document tries to say is: 

Register R is divided into four different ranges R1, R2, R3, R4 (defining the 
value limits may be useful)

Values in range R1 are allocated according to policy P1 in the case that ...
Values in range R2 are allocated according to policy P2 in the case that ...
Values in range R3 are allocated according to policy P3 in the case that ...
Values in range R4 are allocated according to policy P4 in the case that ...

But it doesn't say it. Mentioning four concurrent policies for the same 
registry without separation of values range, and without providing clear 
instructions when each policy is recommended to be used, seems confusing to me, 
and may be confusing for users of this document in the future. 

Regards,

Dan

 

On Tue, Feb 27, 2018 at 5:40 AM, Benjamin Kaduk <ka...@mit.edu 
<mailto:ka...@mit.edu> > wrote:

On Mon, Feb 26, 2018 at 11:19:04PM +0200, Dan Romascanu wrote:
> Hi Jim,
>
> Thank you for your answer and for addressing my comments.
>
> On item #2:
>
>
>
> On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad <i...@augustcellars.com 
> <mailto:i...@augustcellars.com> > wrote:
>
> >
> >
> > > -O

Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Jim Schaad]

Integer values between -256 and 255 and strings of length 1 are designated as 
Standards Track Required.

 

Integer values from -65536 to 65535 and strings of length 2 are designated as 
Specification Required.

 

Integer values of greater than 65535 and strings of length greater than 2 are 
designated as Expert Review.  

 

Integer values less than -65536 are marked as Private Use.

 

So that says what IANA policy is to be used for each of the different items.  
This defines the policies and the ranges for those policies.

 

There is not anything that is making a distinction on what the criteria to be 
used by the DE in the document which is separate, but I don’t think that is 
needed.  This is why they are DEs.

 

I still don’t see what you think is missing.

 

Jim

 

 

From: Dan Romascanu [mailto:droma...@gmail.com] 
Sent: Tuesday, February 27, 2018 2:00 AM
To: Benjamin Kaduk <ka...@mit.edu>
Cc: Jim Schaad <i...@augustcellars.com>; gen-art <gen-...@ietf.org>; 
draft-ietf-ace-cbor-web-token@ietf.org; ietf <i...@ietf.org>; ace@ietf.org
Subject: Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

 

Hi,

See also my other notes. 

I believe that what the document tries to say is: 

Register R is divided into four different ranges R1, R2, R3, R4 (defining the 
value limits may be useful)

Values in range R1 are allocated according to policy P1 in the case that ...
Values in range R2 are allocated according to policy P2 in the case that ...
Values in range R3 are allocated according to policy P3 in the case that ...
Values in range R4 are allocated according to policy P4 in the case that ...

But it doesn't say it. Mentioning four concurrent policies for the same 
registry without separation of values range, and without providing clear 
instructions when each policy is recommended to be used, seems confusing to me, 
and may be confusing for users of this document in the future. 

Regards,

Dan

 

On Tue, Feb 27, 2018 at 5:40 AM, Benjamin Kaduk <ka...@mit.edu 
<mailto:ka...@mit.edu> > wrote:

On Mon, Feb 26, 2018 at 11:19:04PM +0200, Dan Romascanu wrote:
> Hi Jim,
>
> Thank you for your answer and for addressing my comments.
>
> On item #2:
>
>
>
> On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad <i...@augustcellars.com 
> <mailto:i...@augustcellars.com> > wrote:
>
> >
> >
> > > -Original Message-
> > > From: Dan Romascanu [mailto:droma...@gmail.com 
> > > <mailto:droma...@gmail.com> ]
> > >
> >
> > ...
>
> > >
> > > 2. I am a little confused by the definition of policies in Section 9.1:
> > >
> > >Depending upon the values being requested, registration requests are
> > >evaluated on a Standards Track Required, Specification Required,
> > >Expert Review, or Private Use basis [RFC8126] after a three-week
> > >review period on the cwt-reg-rev...@ietf.org 
> > > <mailto:cwt-reg-rev...@ietf.org>  mailing list, on the
> > >advice of one or more Designated Experts.
> > >
> > > How does this work? The request is forwarded to the designated expert,
> > > he/she make a recommendation concerning the policy on the mail list, and
> > > depending on the feedback received a policy is selected? Who establishes
> > > consensus?
> > >
> > > Frankly, I wonder if this can work at all. Are there other examples of
> > four
> > > different policies for the same registry, applied on a case-to-case
> > basis?
> >
> > This is the same approach that is being used for the COSE registries.  As
> > an example, you can look at https://www.iana.org/
> > assignments/cose/cose.xhtml#algorithms.
> >
> > Part of the issue about this is that the JOSE/JWT registries do have the
> > same different policies, but that differences are hidden from the IANA
> > registry.  Since they allow for a URI to be used as the identifier of a
> > field, only the plain text versions are registered.  Thus I can use "
> > http://augustcellars.com/JWT/My_Tag; as an identifier.  Since for CBOR
> > the set of tag values is closed and does not have this escape (nor would
> > one want the length of the tag) it is necessary to have this break down of
> > tag fields.
> >
> >
> >
> >
> This does not seem to be exactly the same approach. The COSE RFC 8152
> defines the registry policy in a different manner. There is only one policy
> that is proposed 'Expert Review' and than the Expert Review Instructions
> are used to define the cases when a Standards Track specification is
> required. No such text exists in the current I-D. There is no separation of
> the values space in the re

Re: [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Jim Schaad]

 

 

From: Dan Romascanu [mailto:droma...@gmail.com] 
Sent: Monday, February 26, 2018 1:19 PM
To: Jim Schaad <i...@augustcellars.com>
Cc: gen-art <gen-...@ietf.org>; ace@ietf.org; ietf <i...@ietf.org>; 
draft-ietf-ace-cbor-web-token@ietf.org
Subject: Re: Genart telechat review of draft-ietf-ace-cbor-web-token-12

 

Hi Jim,

Thank you for your answer and for addressing my comments. 

On item #2: 



 

On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:



> -Original Message-
> From: Dan Romascanu [mailto:droma...@gmail.com <mailto:droma...@gmail.com> ]
>

 

... 

>
> 2. I am a little confused by the definition of policies in Section 9.1:
>
>Depending upon the values being requested, registration requests are
>evaluated on a Standards Track Required, Specification Required,
>Expert Review, or Private Use basis [RFC8126] after a three-week
>review period on the cwt-reg-rev...@ietf.org 
> <mailto:cwt-reg-rev...@ietf.org>  mailing list, on the
>advice of one or more Designated Experts.
>
> How does this work? The request is forwarded to the designated expert,
> he/she make a recommendation concerning the policy on the mail list, and
> depending on the feedback received a policy is selected? Who establishes
> consensus?
>
> Frankly, I wonder if this can work at all. Are there other examples of four
> different policies for the same registry, applied on a case-to-case basis?

This is the same approach that is being used for the COSE registries.  As an 
example, you can look at 
https://www.iana.org/assignments/cose/cose.xhtml#algorithms.

Part of the issue about this is that the JOSE/JWT registries do have the same 
different policies, but that differences are hidden from the IANA registry.  
Since they allow for a URI to be used as the identifier of a field, only the 
plain text versions are registered.  Thus I can use 
"http://augustcellars.com/JWT/My_Tag; as an identifier.  Since for CBOR the set 
of tag values is closed and does not have this escape (nor would one want the 
length of the tag) it is necessary to have this break down of tag fields.




 

This does not seem to be exactly the same approach. The COSE RFC 8152 defines 
the registry policy in a different manner. There is only one policy that is 
proposed 'Expert Review' and than the Expert Review Instructions are used to 
define the cases when a Standards Track specification is required. No such text 
exists in the current I-D. There is no separation of the values space in the 
registry according to the type of assignment here, as  in RFC 8152. 

 

[JLS] The policies look to be the same to me, but I may be missing something 
that you are seeing..  Remember that Specification Required implies Expert 
review.

Regards,

Dan

 

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Minutes for IETF 100

[Jim Schaad]

I have uploaded the minutes for the meeting.  Please feel free to look at
them and send me comments.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

[Jim Schaad]

Esko,

 

Whether a generic encode would automatically skip over tags is going to
depend on the data model presented to the user by the parser.  I have worked
with one where the tags are ignored by the data model unless the user
explicitly asks about them.  I have worked with another where the tags are
explicitly modeled in the result of the parser.   There is a node in the
resulting tree that is of node type tag with a value.

 

Consider the case of something that could be either a string or an url
encoded string.  In this case the only difference in the encoding is the tag
value.   In this case the tag is significant so should not be ignored.  

 

I agree with Mike that this additional requirement could be misleading.

 

Jim

 

 

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Esko Dijk
Sent: Monday, December 11, 2017 3:03 AM
To: Mike Jones ; Samuel Erdtman

Cc: Benjamin Kaduk ; ace@ietf.org
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

 

Hello Mike,

 

My intention was to have "no extra code in recipients that verifies absence
of tags".  I did not intend to propose modification to the CBOR decoder (a
generic decoder would skip over i.e. ignore any tags already - which is the
right behavior in my view).

 

I don't see how an additional sentence in the spec "MUST ignore tags" can
possibly lead to extra code? A generic CBOR decoder will already skip over
any tags. And besides these tags are not present because the spec states
they must not be used. So there's nothing a receiver would have to do extra
or different.

The benefit then seemingly comes for free; and this benefit is the potential
usage of tags attached to existing claims, for future versions of the spec. 

 

But given that a CBOR decoder would normally ignore tags already, I'm also
fine with not changing the text if it is confusing for developers. They
might think they need to implement something while the requirement actually
asks them *not* to implement something. Most developers would not bother to
implement such extra checks anyhow.

 

thanks

Esko

 

From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Friday, December 8, 2017 14:46
To: Esko Dijk  >;
Samuel Erdtman  >
Cc: Benjamin Kaduk  >; ace@ietf.org
 
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

 

Requiring extra code in recipients to ignore tags that already must not be
present would make them needlessly more complicated and hurt interop. It's
virtually certain that many implementations will not include this extra code
that should never be executed. We shouldn't put developers in the position
of deciding whether to add code for a case that already must not occur.

-- Mike

 

 

  _  

The information contained in this email may be confidential and/or legally
protected under applicable law. The message is intended solely for the
addressee(s). If you are not the intended recipient, you are hereby notified
that any use, forwarding, dissemination, or reproduction of this email is
strictly prohibited and may be unlawful. If you are not the intended
recipient, please contact the sender by return e-mail and destroy all copies
of the original email.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] CWT - Audience

[Jim Schaad]

This was done because, in CBOR, there is a way to distinguish between a string 
and a URL.  This is lacking in JSON.  I believe that the ability to not have to 
determine this heuristically is a good thing.

 

Jim

 

 

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Samuel Erdtman
Sent: Tuesday, October 31, 2017 2:42 AM
To: Hannes Tschofenig 
Cc: ace@ietf.org
Subject: Re: [Ace] CWT - Audience

 

My guess is that this is an early mistake that has not been noticed, it has 
been like this from the first draft.

I think the correct thing would be to change it so that CWT reflects JWT.

//Samuel

 

On Tue, Oct 31, 2017 at 10:27 AM, Hannes Tschofenig  > wrote:

Hi all, 

 

in https://datatracker.ietf.org/doc/rfc7519/?include_text=1 (section 4.1.3), 
“aud” is defined for JWT as being an array of case-sensitive strings, or a 
single string.

 

In 
https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/?include_text=1 
(section 3.1.3), “aud” is defined for CWT as being like in JWT, but “the value 
is of type StringOrURI”. 

 

I was wondering how we arrived at this point where the CWT and the JWT differ 
in this regard. 

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you. 


___
Ace mailing list
Ace@ietf.org  
https://www.ietf.org/mailman/listinfo/ace

 

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Review of draft-ietf-ace-cwt-proof-of-possession 00

[Jim Schaad]

> -Original Message-
> From: Mike Jones [mailto:michael.jo...@microsoft.com]
> Sent: Friday, October 27, 2017 7:43 PM
> To: Jim Schaad <i...@augustcellars.com>; draft-ietf-ace-cwt-proof-of-
> possess...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: Review of draft-ietf-ace-cwt-proof-of-possession 00
> 
> Thanks for the detailed review, Jim.  Replies inline...
> 
> -Original Message-
> From: Jim Schaad [mailto:i...@augustcellars.com]
> Sent: Sunday, October 22, 2017 5:21 PM
> To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org
> Cc: ace@ietf.org
> Subject: Review of draft-ietf-ace-cwt-proof-of-possession 00
> 
> 
> *  Section 2 - Issuer " Party that creates the CWT and binds the claims
with
> the POP key"
> 
> The proposed language suggests something that's not true - that the PoP
key
> is used to sign the CWT, or something like that.  It's the signing key
that binds
> the claims.

You are right - would be better as "bind the claims to the POP Key"

> 
> * Section 2 - The definition of "presenter" in this document is odd given
that
> we are looking at ways that a CWT can be transferred by a third part.
> A better term would be "Holder" or "Holder of Key"
> 
> I'm reluctant to undergo a wholesale change of terminology when this comes
> directly from the already-approved RFC 7800.  (I'm of course willing to
> entertain clarifications.)

I'll think about a response.

> * Section 3.1 para 4 - The thus in the first sentence does not follow from
the
> requirement.  There is nothing that says that the same key could not be in
> both the COSE_Key and Encrypted_COSE_Key fields.
> 
> I suppose that's true but why would an application do or want both
> unencrypted and encrypted representations of the same content?  Requiring
> them to be mutually exclusive simplifies applications, it seems to me.

I am not objecting to the mutual exclusivity of the field.  The rational
needs to be appropriate


> 
> * Section 3.2 and 3.3 should be written in terms of the fields COSE_Key
and
> Encrypted_COSE_Key rather than in terms of symmetric and asymmetric
> keys.
> Then you can properly talk about public and private keys in each of the
> sections and it is tied to the structure itself rather than inferred
> 
> Again, unless the text is wrong or unclear, we plan to leave most
descriptions
> parallel to those in RFC 7800.  Your suggestion would be a rewrite.

In my opinion, it is poorly written and confusing as to what is being
accomplished and what the fields are.  Reordering in this way would make it
clear where currently it is not.  Copying unclear text is generally not
useful.

> 
> * Section 3.4 - I would consider this to be an unusable item for doing POP
key
> identification in all cases where the kid is not computed in a
cryptographic
> manner and the method of computation is included as part of the kid.
> 
> If the key ID doesn't match, the worst that will happen is the PoP
verification
> will fail.  This is analogous to why it's ok for the Key ID to be in an
unprotected
> header in COSE.

In the case of COSE, if you identify the wrong key then it would not
validate.  In this case if you have two different keys that had been
presented to you with the same Key ID value and two different keys, when you
get the CWT you do not know which of two keys is the POP key and which is
not.  The cases are not analogous.


> 
> * Section 3.5 - Huh?  I don't know about typically for the demonstration.
> It could just as easily be done by doing an encryption/decryption
operation
> or a key derivation operation such as in TLS for PSK.  I don't know that
this
> section is providing any useful information.  If you think that it is
needed then
> a simple statement that you are not specifying how to do POP is
sufficient.
> 
> If you want to supply some additional text about these other methods, that
> would be welcomed.

I'll try and remember to look at this.  If I don't have anything by the F2F
remind me.

> 
> * Section 4 paragraph 2 - I can understand a reasoning for doing audience
> restrictions, but I cannot for the life of me figure out why it would be
of
> greater importance for POP statements than for any other set of claims.
> 
> It's not more important, nor does it say that it is.  But in the RFC 7800
last call
> process, several people wanted us to add this security consideration.

I'll re-read.

> 
> * Section 4 - I am surprised there is no statement about self-signed CWT
> statements esp. as that is given as an example of how additional naming
> claims would be understood
> 
> What would you like the statement to say?  

Something along the lines of it is only as good as the original trust in
that person.  Self-asserted statem

Re: [Ace] Question about the response to an unauthorized request

[Jim Schaad]

So you would be doing based on something like the address of the requestor or 
the content of the request.  I would complete understand the first half.  Is 
there any way to prevent a rouge requestor from asking for information – or are 
you just relying on a closed system?

 

From: Cigdem Sengul [mailto:cigdem.sen...@gmail.com] 
Sent: Wednesday, October 25, 2017 2:19 PM
To: Jim Schaad <i...@augustcellars.com>
Cc: Ludwig Seitz <ludwig.se...@ri.se>; ace@ietf.org
Subject: Re: [Ace] Question about the response to an unauthorized request

 

UMA assumes that  resource server knows “which authorization server to approach 
for the permission ticket and on which resource owner's behalf” deriving “the 
necessary information using cues provided by the structure of the API where the 
resource request was made, rather than by an access token. “

On Wednesday, October 25, 2017, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

How does the RS make an informed decision about who the client is given that it 
is a tokenless access request?

 

 

 

From: Ace [mailto:ace-boun...@ietf.org 
<javascript:_e(%7B%7D,'cvml','ace-boun...@ietf.org');> ] On Behalf Of Cigdem 
Sengul
Sent: Wednesday, October 25, 2017 7:28 AM
To: Ludwig Seitz <ludwig.se...@ri.se 
<javascript:_e(%7B%7D,'cvml','ludwig.se...@ri.se');> >
Cc: ace@ietf.org <javascript:_e(%7B%7D,'cvml','ace@ietf.org');> 
Subject: Re: [Ace] Question about the response to an unauthorized request

 

Hello,

 

To bring a different view, I wanted to mention Kantara UMA (User Managed 
Access) approach to this problem. (I participated in the UMA v2.0 development 
this year, so had the chance to be more familiar with the new drafts.)

 

In UMA,  the resource server must respond to a client's tokenless 
(unauthorized) access attempt by obtaining a permission ticket from the 
authorization server.

If RS is able to obtain a permission ticket from the AS, RS returns this ticket 
to the client also with  the AS uri to aid AS discovery. 

 

UMA handles resources (resource sets, permissions etc.) differently but the 
permission requests (from RS to AS)  can be considered as signaling to the AS 
what audience/scope RS expects.

 

In ACE, there are limitations of course - i.e., RS may not always reach AS etc. 
 Nevertheless, it may be useful to think how other groups approach similar 
problems. 

 

Best, 

--Cigdem 

 

 

On Mon, Oct 23, 2017 at 2:38 PM, Ludwig Seitz <ludwig.se...@ri.se 
<javascript:_e(%7B%7D,'cvml','ludwig.se...@ri.se');> > wrote:

Hello ACE,

Jim Schaad has brought up an interesting question [1] on 
draft-ietf-ace-oauth-authz [2]:

Currently when a client makes an unauthorized request to a resource server, it 
gets back the address of the authorization server and optionally a nonce (to 
prevent replay attacks).

Jim is suggesting to add hints to the audience and scope the resource server 
expects for accessing this resource.

I'm not sure whether that would not reveal too much information to a potential 
attacker.

What does the group think of this issue?

/Ludwig


[1] https://github.com/ace-wg/ace-oauth/issues/124
[2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2
-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51 <tel:%2B46%280%2970-349%2092%2051> 

___
Ace mailing list
Ace@ietf.org <javascript:_e(%7B%7D,'cvml','Ace@ietf.org');> 
https://www.ietf.org/mailman/listinfo/ace

 

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Question about the response to an unauthorized request

[Jim Schaad]

I don’t think that this is going to reveal any more information to an attacker 
than would be available to an attacker that just asks the resource server for a 
resource w/o a token.  Currently that is expected to return the same 
information.  

 

One approach that would be good to note is that it might be reasonable to hide 
this information behind a security wall so that it is required that the client 
gets secure access to the RD before any additional information about the 
resource can be obtained.

 

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Grace Lewis
Sent: Wednesday, October 25, 2017 8:26 AM
To: Cigdem Sengul <cigdem.sen...@gmail.com>; Ludwig Seitz <ludwig.se...@ri.se>
Cc: ace@ietf.org
Subject: Re: [Ace] Question about the response to an unauthorized request

 

Ludwig,

 

I do believe that this would reveal too much information to an attacker, 
especially if IoT devices are being deployed in “hostile environments.” While 
this may be appropriate in a home and potentially industry setting, it is 
certainly not appropriate in a more contested setting. 

 

The UMA approach presented by Cigdem is an option, given that the RS is able to 
verify with the AS that the request comes from a client that is currently 
paired to the AS. However, I do agree that reachability to the AS may not 
always be possible.

 

If this is included as an option, the security considerations would need to be 
clearly noted.

 

*   Grace

 

__

Grace A. Lewis, Ph.D.

Principal Researcher

Carnegie Mellon Software Engineering Institute

Software Solutions Division (SSD) 

Tactical Technologies Group (TTG)

 

4500 Fifth Ave. 

Pittsburgh, PA 15213   

Phone: (412) 268-5851

http://www.sei.cmu.edu/staff/glewis

 

From: Ace <ace-boun...@ietf.org <mailto:ace-boun...@ietf.org> > on behalf of 
Cigdem Sengul <cigdem.sen...@gmail.com <mailto:cigdem.sen...@gmail.com> >
Date: Wednesday, October 25, 2017 at 10:27 AM
To: Ludwig Seitz <ludwig.se...@ri.se <mailto:ludwig.se...@ri.se> >
Cc: "ace@ietf.org <mailto:ace@ietf.org> " <ace@ietf.org <mailto:ace@ietf.org> >
Subject: Re: [Ace] Question about the response to an unauthorized request

 

Hello, 

 

To bring a different view, I wanted to mention Kantara UMA (User Managed 
Access) approach to this problem. (I participated in the UMA v2.0 development 
this year, so had the chance to be more familiar with the new drafts.)

 

In UMA,  the resource server must respond to a client's tokenless 
(unauthorized) access attempt by obtaining a permission ticket from the 
authorization server.

If RS is able to obtain a permission ticket from the AS, RS returns this ticket 
to the client also with  the AS uri to aid AS discovery. 

 

UMA handles resources (resource sets, permissions etc.) differently but the 
permission requests (from RS to AS)  can be considered as signaling to the AS 
what audience/scope RS expects.

 

In ACE, there are limitations of course - i.e., RS may not always reach AS etc. 
 Nevertheless, it may be useful to think how other groups approach similar 
problems. 

 

Best, 

--Cigdem 

 

 

On Mon, Oct 23, 2017 at 2:38 PM, Ludwig Seitz <ludwig.se...@ri.se 
<mailto:ludwig.se...@ri.se> > wrote:

Hello ACE,

Jim Schaad has brought up an interesting question [1] on 
draft-ietf-ace-oauth-authz [2]:

Currently when a client makes an unauthorized request to a resource server, it 
gets back the address of the authorization server and optionally a nonce (to 
prevent replay attacks).

Jim is suggesting to add hints to the audience and scope the resource server 
expects for accessing this resource.

I'm not sure whether that would not reveal too much information to a potential 
attacker.

What does the group think of this issue?

/Ludwig


[1] https://github.com/ace-wg/ace-oauth/issues/124
[2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2
-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51 <tel:%2B46%280%2970-349%2092%2051> 

___
Ace mailing list
Ace@ietf.org <mailto:Ace@ietf.org> 
https://www.ietf.org/mailman/listinfo/ace

 

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Question about the response to an unauthorized request

[Jim Schaad]

How does the RS make an informed decision about who the client is given that it 
is a tokenless access request?

 

 

 

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Cigdem Sengul
Sent: Wednesday, October 25, 2017 7:28 AM
To: Ludwig Seitz <ludwig.se...@ri.se>
Cc: ace@ietf.org
Subject: Re: [Ace] Question about the response to an unauthorized request

 

Hello,

 

To bring a different view, I wanted to mention Kantara UMA (User Managed 
Access) approach to this problem. (I participated in the UMA v2.0 development 
this year, so had the chance to be more familiar with the new drafts.)

 

In UMA,  the resource server must respond to a client's tokenless 
(unauthorized) access attempt by obtaining a permission ticket from the 
authorization server.

If RS is able to obtain a permission ticket from the AS, RS returns this ticket 
to the client also with  the AS uri to aid AS discovery. 

 

UMA handles resources (resource sets, permissions etc.) differently but the 
permission requests (from RS to AS)  can be considered as signaling to the AS 
what audience/scope RS expects.

 

In ACE, there are limitations of course - i.e., RS may not always reach AS etc. 
 Nevertheless, it may be useful to think how other groups approach similar 
problems. 

 

Best, 

--Cigdem 

 

 

On Mon, Oct 23, 2017 at 2:38 PM, Ludwig Seitz <ludwig.se...@ri.se 
<mailto:ludwig.se...@ri.se> > wrote:

Hello ACE,

Jim Schaad has brought up an interesting question [1] on 
draft-ietf-ace-oauth-authz [2]:

Currently when a client makes an unauthorized request to a resource server, it 
gets back the address of the authorization server and optionally a nonce (to 
prevent replay attacks).

Jim is suggesting to add hints to the audience and scope the resource server 
expects for accessing this resource.

I'm not sure whether that would not reveal too much information to a potential 
attacker.

What does the group think of this issue?

/Ludwig


[1] https://github.com/ace-wg/ace-oauth/issues/124
[2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2
-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51 <tel:%2B46%280%2970-349%2092%2051> 

___
Ace mailing list
Ace@ietf.org <mailto:Ace@ietf.org> 
https://www.ietf.org/mailman/listinfo/ace

 

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Review of draft-ietf-ace-cwt-proof-of-possession 00

[Jim Schaad]

*  I dislike the statement of what the specification claims to do.  It will
be misread by many people who are not familiar with how you are defining the
word "presenter".  If I intercept a CWT and present it to a validator, it
does not make a claim that I possess a specific POP key.   Given what a CWT
is supposed to do, I believe that a much clearer statement of functionality
would be  "This specification describes how to associate a set of claims in
a CWT with a particular proof-of-possession key."  Among other things, this
would allow a third party to "present" a CWT on behalf of another party.
(See introspection.)

*  I dislike the way that the second sentence of the introduction is
written.  Please remove the text about the presenter, that is not relevant
to the holder-of-key assertion.

*  Section 2 - Issuer " Party that creates the CWT and binds the claims with
the POP key"

* Section 2 - The definition of "presenter" in this document is odd given
that we are looking at ways that a CWT can be transferred by a third part.
A better term would be "Holder" or "Holder of Key"

* Section 3 paragraph 1 - This paragraph is written with some things taken
for granted that I am not user exist.  1) How is the issuer doing the
declaration that a presenter possesses a key, is a POP of the key a
requirement to issue the CWT that I have not yet seen?  2) Again I don't
like the use of presenter as the key usage and transfer are not necessarily
done at the same time.

* Section 3 paragraph 2 - You need to be clearer about what you mean by
identified.  My reading would be that the presenter is identified by the POP
key.  If you want to talk about claims which contain other types of naming
material, then you need to be clear that is what you are doing.

* Section 3 paragraph 2 - I would skip most of the detail on the meanings of
the different claims and just identify the number of claims and refer to the
CWT document for details on what they mean.  The current text is not clear,
and hopefully, the CWT document is much clearer on what these mean.

* General - Where are you defining the types and contents of the claims that
are being registered in this document?  I cannot find it and I expected it
to be in section 3.1

* Section 3.1 para 1 - Based on the last sentence, I think that you need to
make some type of statement about the purpose of the "cnf" claim that
embodies both a POP key and the SAML stuff that you are adding.  What are
the requirements to be here?  What are the relationships between statements?


* Section 3.1 para 2 - It is fine to say that what the set of methods that
must be present is application dependent, however without the presence of
some type of profile identification, how is an application supposed to know
if the meanings and relationships are what are expected and not from some
other profile?

* Section 3.1 para 4 - The thus in the first sentence does not follow from
the requirement.  There is nothing that says that the same key could not be
in both the COSE_Key and Encrypted_COSE_Key fields.

* Section 3.1 para 4 - I don't understand the process defined in sentence #2
and why it is done this way.  It would make more sense to me to say that it
could be a new field with an array of cnf values.  Doing the "additional to
'cnf'" would seem to cause potential problems when this CWT is grabbed by
somebody which does not understand how these two fields are related.

*  Change the examples to use CBOR diagnostic notation.

* Section 3.2 and 3.3 should be written in terms of the fields COSE_Key and
Encrypted_COSE_Key rather than in terms of symmetric and asymmetric keys.
Then you can properly talk about public and private keys in each of the
sections and it is tied to the structure itself rather than inferred

* Section 3.4 - I would consider this to be an unusable item for doing POP
key identification in all cases where the kid is not computed in a
cryptographic manner and the method of computation is included as part of
the kid.

* Section 3.5 - Huh?  I don't know about typically for the demonstration.
It could just as easily be done by doing an encryption/decryption operation
or a key derivation operation such as in TLS for PSK.  I don't know that
this section is providing any useful information.  If you think that it is
needed then a simple statement that you are not specifying how to do POP is
sufficient.

* Section 4 paragraph 2 - I can understand a reasoning for doing audience
restrictions, but I cannot for the life of me figure out why it would be of
greater importance for POP statements than for any other set of claims.

* Section 4 para 4 - How does a signed nonce prevent a replay attack with
encrypted symmetric secrets?

* Section 4 - I am surprised there is no statement about self-signed CWT
statements esp. as that is given as an example of how additional naming
claims would be understood

* Section 5 - Need to make  a statement about the correlation information
that a CWT issuer would 

[Ace] FW: draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag

[Jim Schaad]

Just to highlight this and make it concrete.

COSE did the same thing in defining optional tags that can be used.  Looking at 
the CWT document, the tags are being used because without the tag one cannot 
tell what the security operation is that is being used.  However the 
OAuth-Authz draft is using the COSE_Encrypt object without a tag because there 
are other indications (the name in the map) such that which COSE object is 
being used is clearly defined. 

I expect similar usages to occur with CWT in the future.

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, October 19, 2017 2:14 PM
To: 'Carsten Bormann' <c...@tzi.org>; 'Hannes Tschofenig' 
<hannes.tschofe...@arm.com>
Cc: 'Mike Jones' <michael.jo...@microsoft.com>; ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag

The type of location where  it might show up is where one does a value that is 
placed in an array where it can be either an A or a B and you use the tag to 
distinguish between the two options.  This can be very useful in those cases.  



> -Original Message-
> From: Carsten Bormann [mailto:c...@tzi.org]
> Sent: Thursday, October 19, 2017 1:32 PM
> To: Hannes Tschofenig <hannes.tschofe...@arm.com>
> Cc: Mike Jones <michael.jo...@microsoft.com>; Jim Schaad 
> <i...@augustcellars.com>; ace@ietf.org
> Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag
> 
> On Oct 19, 2017, at 21:30, Hannes Tschofenig 
> <hannes.tschofe...@arm.com> wrote:
> >
> > For the cost  saving of one byte we are essentially introduction 
> > options
> here. I am wondering whether this byte is worth it.
> 
> Two bytes.
> 
> It’s not really an option, as in every context there will be a single 
> right way to do this.
> But yes, there are naked and tagged CWTs now.
> 
> (If we only define the tagged version, very quickly there will be 
> specs that define a “compressed CWT” that just leaves out those first 
> two bytes…)
> 
> Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Comments on draft-tiloca-ace-oscoap-joining

[Jim Schaad]

Francesca,

My first concern is that the messages being send around to do the group
communication setup should be, if not identical, highly coordinated in how
they are formatted.   I don't really want two different sets of messages.

I understand, and indeed noted, that the current model of how they are using
the authentication structure is different.  However, I believe that I could
easily map things so that the structures are going to be the same.  Consider
the following change of the join picture.

Kill the current AS entity from the system as not providing new
functionality.
Rename the current RS entity to be AS2 mapping to the same current
functionality as is provided in the pub-sub draft.
Create a new collective RS entity which consists of all of the entities
(other than me) which are listening to the multicast address.

If you do that then the picture of the multicast and pub-sub systems have a
great deal in common.  The one thing that gets lost is the ability to ask
the current RS where the AS lives, but this is the type of information that
Ludwig is saying should be able to be placed in the resource directory (see
the oauth-authz document).  This is where the question of what the resource
types and relationships between different elements in the RD would come into
focus.  It would also be possible that AS2 in the new module would just have
a directory of multicast items which it supports.

The pub-sub discovery of resources is currently designed to be done via the
resource directory, so there is no reason that the multicast ones should not
as well.

I think that this means that the structure between the two documents is far
closer to the same that either of you realize.

Jim


> -Original Message-
> From: Francesca Palombini [mailto:francesca.palomb...@ericsson.com]
> Sent: Friday, October 20, 2017 6:21 AM
> To: Jim Schaad <i...@augustcellars.com>; draft-tiloca-ace-oscoap-
> join...@ietf.org; draft-palombini-ace-coap-pubsub-prof...@ietf.org
> Cc: ace@ietf.org
> Subject: RE: Comments on draft-tiloca-ace-oscoap-joining
> 
> Hi Jim,
> 
> I don't think that your statement is correct: as far as I understood the
oscoap-
> joining document, the RS is the group manager, while in the pubsub
> document (even generalizing it and making a group communication profile as
> Carsten was suggesting) the entity that does group management is the AS2.
> 
> I consider these differences a reason to have separate documents, yes,
they
> could be described in the same draft, but I don't see how that simplifies
the
> specifications.
> 
> One more comment inline.
> 
> Thanks,
> Francesca
> 
> > -Original Message-
> > From: Jim Schaad [mailto:i...@augustcellars.com]
> > Sent: den 20 oktober 2017 07:42
> > To: draft-tiloca-ace-oscoap-join...@ietf.org;
> > draft-palombini-ace-coap- pubsub-prof...@ietf.org
> > Cc: ace@ietf.org
> > Subject: Comments on draft-tiloca-ace-oscoap-joining
> >
> > After the interim meeting, I read this document through in order to
> > produce a review.  Instead you are going to get a meta-review.
> >
> > I am having a hard to seeing why this document exists in its current
> > form and it is not some type of simple profile of the pub-sub security
draft.
> > While I am not sure that this document is a sub-set of that document,
> > it appears to be about 90-99% a sub set of that document.  Consider
> > the
> > following:
> >
> > You have both the publisher and subscriber roles as in the pub-sub
draft.
> >
> > You have an entity which is doing key distribution in the system.  For
> > the pub- sub draft this is AS2 for you it is the RS, but they are
> > performing the exact same set of tasks.
> >
> 
> Yes, they are performing the same set of tasks on a high level, but they
are
> using the ACE framework differently in practice. For example the publisher
> and subscriber acquire the keys without using the token.
> 
> > The pub-sub draft as and endpoint which holds the encrypted messages,
> > in its place you are using the multi-cast UDP channel.  In both cases
> > they are basically unprotected-untrusted entities to distribute the
content
> message.
> > The only difference is that in the pub-sub model the RS will also
> > provide restricted access to publishing which is not enforceable here.
> >
> > Both of these documents are missing what I would consider to be core
> > pieces.
> > The pub-sub document does initial key distribution, while this
> > document does not.  Neither document does any discussion of how
> > subsequent key distribution is done to deal with forward and backward
> security of messages.
> >
> >
> > This document probably needs to define a new re

[Ace] Comments on draft-tiloca-ace-oscoap-joining

[Jim Schaad]

After the interim meeting, I read this document through in order to produce
a review.  Instead you are going to get a meta-review.

I am having a hard to seeing why this document exists in its current form
and it is not some type of simple profile of the pub-sub security draft.
While I am not sure that this document is a sub-set of that document, it
appears to be about 90-99% a sub set of that document.  Consider the
following:

You have both the publisher and subscriber roles as in the pub-sub draft.

You have an entity which is doing key distribution in the system.  For the
pub-sub draft this is AS2 for you it is the RS, but they are performing the
exact same set of tasks.

The pub-sub draft as and endpoint which holds the encrypted messages, in its
place you are using the multi-cast UDP channel.  In both cases they are
basically unprotected-untrusted entities to distribute the content message.
The only difference is that in the pub-sub model the RS will also provide
restricted access to publishing which is not enforceable here.

Both of these documents are missing what I would consider to be core pieces.
The pub-sub document does initial key distribution, while this document does
not.  Neither document does any discussion of how subsequent key
distribution is done to deal with forward and backward security of messages.


This document probably needs to define a new relationship, which might be
more generally used, to say - this URL is where you get the security
information for this URL which is published in the directory - esp in the
case of multi-cast address URLs in the resource directory.  You might also
find that the correct answer is not to use a separate resource for each
channel, but to allow for the use of URI path elements to define the
security for a resource.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag

[Jim Schaad]

The type of location where  it might show up is where one does a value that is 
placed in an array where it can be either an A or a B and you use the tag to 
distinguish between the two options.  This can be very useful in those cases.  



> -Original Message-
> From: Carsten Bormann [mailto:c...@tzi.org]
> Sent: Thursday, October 19, 2017 1:32 PM
> To: Hannes Tschofenig <hannes.tschofe...@arm.com>
> Cc: Mike Jones <michael.jo...@microsoft.com>; Jim Schaad
> <i...@augustcellars.com>; ace@ietf.org
> Subject: Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag
> 
> On Oct 19, 2017, at 21:30, Hannes Tschofenig
> <hannes.tschofe...@arm.com> wrote:
> >
> > For the cost  saving of one byte we are essentially introduction options
> here. I am wondering whether this byte is worth it.
> 
> Two bytes.
> 
> It’s not really an option, as in every context there will be a single right 
> way to
> do this.
> But yes, there are naked and tagged CWTs now.
> 
> (If we only define the tagged version, very quickly there will be specs that
> define a “compressed CWT” that just leaves out those first two bytes…)
> 
> Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] draft-palombini-ace-coap-pubsub-profile

[Jim Schaad]

After doing some reading elsewhere, I think it would be reasonable to
outline the version of security when the pub/sub agent can be trusted.  This
makes a contrast with this model that people should understand.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Review - draft-seitz-ace-oscoap-profile-03

[Jim Schaad]

Here are some comments on the draft.

1.  Please change the title.  It would be more appropriate to say that you
are "OSCOAP profile of the Authentication and Authorization for Constrained
Environments Framework".  ( I will also be asking for a rename of that
document to add framework to highlight it is a structure not the final
document).

2. Expand ACE in the abstract.  Lookup on the RFC Editor page if you need to
expand OAuth as well.

3.  I think that you need to distinguish between a returned key used for
oscoap vs oscoap+edhoc so that the server can deal with the new key in a
correct manner.  (This links to a request for the profile to be in the CWT
for the framework.)

4.  In section 2.2.1 - this is not really a POP key, it is a shared secret
and not even a symmetric key.

5.  In section 2.2.1 - Is there a reason not to re-use kid for sid?

6. In Section 2.2.1 - I would change the text relating to how ids are
defined.  What is here is not really what we are looking for in this case as
smaller ids are much nicer esp if the AS can ensure uniqueness based on some
knowledge.

7. In Section 2.2.1 - Need to have some text some place to declare what to
do for collisions of the rid value.

8.  In Section 2.2.1 - Does it make more sense to say "client" and "server"
id instead.

9.  In Section 2.2.2 - This is incorrectly section numbered

10. In section 2.2.2 - Again the symmetric key is not a POP key.

11.  In section 2.2.2 - for asymmetric case need to the rs_cnf parameter.
<<< I need to double check this >>>

12. In section 2.2.2 - In the CWT, the specific asymmetric key used by the
server in the event it has multiple

13. In section 2.2.2 - Need to make a statement about the expires_in field.
Is this the expires for the original secret or for the EDHOC derived key.

14. In section 2.2.2 - I am not sure that I am thrilled by the idea of
running the EDHOC protocol on the authz-info resource point. 

15. In section 2.2.2 - Is there a reason for not supporting multiple edhoc
negotiations w/ the same secret - it seemed to be an original mode that was
supported.

Jim





___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Review of draft-jones-ace-cwt-proof-of-possession-00

[Jim Schaad]

Abstract - I am unclear how this is a profile of RFC 7800 rather than a
restatement of that document.   In what way does this qualify as a profile?

Introduction - I do not understand the second half of the first sentence in
the introduction.  It claims that the document is going to show how proof of
possession is done, however this seems to be explicitly declared as out of
scope in section 3.5.

Section 2 - Since this document is currently planned to come from the ACE
working group,  I would suggest that it would be reasonable to provide the
equivalent terminology to what is in this document. -- see actors

Section 3 - para 1 - missed  a s/JSON/CBOR/

Section 3 - para 2 - I am not sure of the following:
- Why this is included here and not a separate section
- Why the concept of an anonymous POP is not supported
- Why the concept of the issuer being inferred from the authentication key
on the CWT is not supported
- I will note that draft-ietf-ace-oauth-authz does not require either of
these fields to be present.

Section 3.1 - The first two sentences seems to be slightly contradictory -
the first says the cnf claim is used to identify the POP key.  The second
states that it may have something other than a POP key in it.

Section 3.1 - I am not a fan of MUST ignore statements at this level.  It
should be  profile statement if anything.

Section 3.1 - last paragraph - Does this mean that only one claim can be in
the cnf claim - or are some values of different levels?  For example -can I
have a COSE_Key and an Kid?  This might be considered to be multiple POP
keys.

Section 3.2 - Profiles can require that additional elements can be required
in the COSE_Key element - and example would be to require that the algorithm
identifier be present.

Section 3.2 - I do not understand why this paragraph is doing in this
section give the section title.  Why is it not in section 3.3 or in a
separate section.  I think it makes mores sense at the end of the next
section.

Section 3.3 - Why is title not symmetric with section 3.2 and the word
encrypted be absent?

Section 3.4 - This section just makes me uncomfortable.  Use a value that
was potentially chosen for collisions does not seem to be a good idea.  I
think this really needs some additional guidance about using.

Section 4 - Is there any reason to suppose that the use of asymmetric
secrets are immune from replay attacks?


Section 3.1 - para 1 -sentence #2  -  I do not understand the implication
that the POP key implies the authenticity of the token.  That statement
makes no sense to me.  This would look  like a self-signed certificate as
the authentication point. 

Jim



___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] draft-ietf-ace-cbor-web-token

[Jim Schaad]

Are the authors planning to do anything with the external data option that
is part of the COSE specification?  I realize that this is not part of JWT
and thus including it would lead to a difference between the specifications,
but as I was working to try and get my CWT implementation the question came
up.  The question also arose from my attempt to reproduce the examples in
the document.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Comments on draft-ietf-ace-oauth-authz

[Jim Schaad]

* Figure 7 makes no sense.  This appears to be mapping a string to a keyed
object.  I think however, that the error here is used as a value not a key.

* Is there a recommendation for behavior if a new item is posted to the
authz-info endpoint which has the same key id as a previous one?  I can
think of three answers, none of which I link
--- Just accept it - this leans to a problem because for DTLS the key ids
are single shot tries, that is one cannot try the first key and then the
second key.
--- Replace it - this means that the client associated with the current key
will suddenly be unable to access resources but knows only that the key no
longer works
--- Reject it - this may be the best option as it leaks only that the key id
is already in use, but if the key id is assigned by an AS then it may be
hard to get a different one assigned by the AS.

* We communicate the profile to be used to the client, however it is not
currently being communicated to the server.  If the server wants to keep the
OSCOAP and DTLS keys separate, this needs to be done.  Does it makes sense
to put this in the 'cnf' field?

* the dtls draft has the concept of a nonce in the AS information payload.
How is this propagated through the request (to the AS) and token back to the
RS?

* Per comments from other drafts.  How many of these points are supposed to
be under the .well-known arch?

* In section 5.7.1 - why is there a requirement that a created rather than a
changed response be returned.  I was not intending to create a new resource
in response to this POST operation.   If the 2.01 (created) response is
required.  Should the token be accessible using the location path in the
response?  --- Same questions apply to the Client--AS interaction.

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt

[Jim Schaad]

See below.

 

Jim

 

From: Samuel Erdtman [mailto:sam...@erdtman.se] 
Sent: Thursday, June 22, 2017 1:40 AM
To: Jim Schaad <i...@augustcellars.com>
Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace <ace@ietf.org>
Subject: Re: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt

 

Thanks Jim! 

Se comments inline

 

On Sun, Jun 18, 2017 at 9:21 PM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

Comments on this version of the draft.

Section 7 - Step 6 & 7 - I do not know if it is legal to have a CWT CBOR tag at 
this point

 

In section 7.1 step 6 describes how one can add the CWT CBOR Tag to the full 
CWT if transport layer cannot indicate that this is a CWT. In this case you 
would want first the COSE tag and then the CWT tag this is described in section 
6. We asked Carsten about this before we added the text so it should be okay.

In section 7.2 step 6 and 7 CWT CBOR tag is not mentioned as far as I can tell.

 

[JLS]  So if an intermediary adds a layer of wrapping (i.e. encrypts it to the 
end point) but the original entity who signed it put the CWT tag on it, it will 
be and invalid CWT if the tag was not removed? 

 


Appendix A.3 - I was unable to reproduce the example.  I assume that this means 
that a deterministic signature algorithm is not being used.  While a verifier 
cannot tell if one is being used, the COSE document does strongly suggest that 
one be used.  Additionally, it helps in testing if one is used so that a 
signature creator can be more easily tested.

 

Correct I have not used a deterministic signing algorithm. I have used 
COSE-JAVA to create the examples, is it possible to configure that 
implementation to generate deterministic ECDSA signatures? 
When working with my JS implementation I have noticed that support for 
deterministic ECDSA implementations are hard to find.

 

[JLS] With COSE-JAVA, if you are using anything remotely recent is 
deterministic, so that should not be a problem.  I put this change into the 
sources about 8 months ago.  The problem may be the same issue as for A.5 where 
something is different in the data to be signed.  

 

 


Appendix A.5 - I was unable to reproduce the example.  Specially the tag value 
does not match with the one that I compute.

 

That is bad. but apart from the tag it looks good?

 

[JLS] Yes apart from the tag I matched everything – including the encryption.  
This bothers me if you are using the COSE-JAVA to produce the examples.  I 
routinely run regression tests on both language libraries so they should 
produce the same output given the same inputs.  This triggers in my mind that 
you might have done something odd with the external data and thus we are 
generating different tags.   It would be something that is being done for 
signing and for encryption but not mac.

 



Minor:




In section 2:  Is there a reason not to define CWT claim value in this section

 

Sorry I´m not following, could you please explain a bit more`? 

 

[JLS] You thought it was reasonable to define a “CWT encoded claim key” in the 
terms.  I was just thinking that it would be symmetric to have the values have 
defined here at the same time.

 

 


-Original Message-
From: Ace [mailto:ace-boun...@ietf.org <mailto:ace-boun...@ietf.org> ] On 
Behalf Of internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> 
Sent: Monday, June 5, 2017 6:27 PM
To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> 
Cc: ace@ietf.org <mailto:ace@ietf.org> 
Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments of the IETF.

Title   : CBOR Web Token (CWT)
Authors : Michael B. Jones
  Erik Wahlström
  Samuel Erdtman
  Hannes Tschofenig
Filename: draft-ietf-ace-cbor-web-token-05.txt
Pages   : 23
Date: 2017-06-05

Abstract:
   CBOR Web Token (CWT) is a compact means of representing claims to be
   transferred between two parties.  The claims in a CWT are encoded in
   the Concise Binary Object Representation (CBOR) and CBOR Object
   Signing and Encryption (COSE) is used for added application layer
   security protection.  A claim is a piece of information asserted
   about a subject and is represented as a name/value pair consisting of
   a claim name and a claim value.  CWT is derived from JSON Web Token
   (JWT), but uses CBOR rather than JSON.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-05
https://datatracker.ietf.org/doc/html/draft-ietf-ace

[Ace] Review on draft-ietf-ace-dtls-authorize-00

[Jim Schaad]

I have some comments on this draft that I have gotten from implementation
attempts.

Major Issues:

Section 2 talks about looking things up in the resource directory, but it
does not say what one would be looking for.  Is this material which should
be in the generic document?

Section 2 - I see a potential interop problem w/ the MAY about transferring
the access token or PSK.  Does a client try it and if it does not work do it
the other way or is it always going to post unless it has some external
indicator that it can take the "shortcut" method?

Section 2.1 - I do not understand why this is not in the mail document
rather than in this profile.

Section 2.1 - The list of three items seems to be overly restrictive on what
is allowed.  I believe that you are missing the case of no token because no
token is needed (which would apply to /authz-info as well).  You have
previously stated that going to /.well-known/core may be something that is
desirable  - either that or I completely miss understood what was being said
above.

Section 2.2 - I do not see the AS_Info map defined anyplace.  Am I missing
something?

Section 2.1 - I am not sure - is the case of no valid access token supposed
to cover cases where the token has expired?   Are there other cases that one
needs to think about here?  Would it not be better to close the DTLS
connection in the event that the last valid token expires?

Section 2.1 - You do not state if an AS_Info map should be returned for all
three cases of failures.  I assume that it should be, but at the current
level of information it might not be totally useful.

Section 2.2 - You might want to differentiate on the setoff AS_info fields
that would be returned in an unsecured vs secured channel.  That is, if I
have a DTLS connection and try to do an operation that fails - then more
info could be returned as it is not generally available.

Section 2.2. - I have no idea how to use this nonce value so that it ends up
in the access token.

Section 2.3 - I have no idea what item #3 is supposed to be saying.  How can
an RS determine if it is the destination under normal circumstances?

Section 3 - I am not sure that the Note text really makes any sense.  If the
client implements Edwards rather than classic EC curves this makes no sense
to offer.  

Section 4.1 - the psk_identity field in TLS is a binary field - why do the
base64 encoding - need to justify this.  Also the current text means that I
suddenly have three different things that can be in this field.  This is not
the type of thing hat would make me happy.  Where you want me to do this is
not the easiest place to suddenly do the processing needed to validate a new
access token.

Section 4.1 - I don't understand what the text around COSE_Encrypt is
supposed to be doing.  It makes little sense to me but I have not tried to
think about it deeply.

Section 4.2 - I don't know that a reference to 5746 is going to be any good
long term.  

Section 4.2 - need to distinguish between cases where the permissions are
update vs where the key is updated.  The former SHOULD NOT require a new
session to be established.

Section 5.1 - I am not sure what this means.  I assume that this text should
say that a client should only deal with an AS for which it has a security
relationship.  Note that it might be an idea to be able to copy the AS from
the RS into the AS request in the event that they do not match so that four
corner authorization can be supported.

Minor Issues:

* I would stop the PSK and RPK paragraphs in the introduction so that they
are in the same order as in sections 3 and 4.

* In the introduction - clean up the last two paragraphs.  The reference #
is off as is the extra line in the Note

* Remove the mention of OSCOAP in section 4 - If you want to say another
profile exists, do it in the introduction.


Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt

[Jim Schaad]

Comments on this version of the draft.

Section 7 - Step 6 & 7 - I do not know if it is legal to have a CWT CBOR tag at 
this point

Section 7 - In Step 7 - it must be a valid CBOR map not just a valid CBOR 
object.

Appendix A.3 - I was unable to reproduce the example.  I assume that this means 
that a deterministic signature algorithm is not being used.  While a verifier 
cannot tell if one is being used, the COSE document does strongly suggest that 
one be used.  Additionally, it helps in testing if one is used so that a 
signature creator can be more easily tested.

Appendix A.5 - I was unable to reproduce the example.  Specially the tag value 
does not match with the one that I compute.

Appendix A.6 - I did not try to reproduce given that a) I would not generate 
the same signature and b) the example A.5 failed.


Minor:

In section 1.1 s/In COSE/In CBOR/ - this is a comment on CBOR not on COSE

In section 2:  s/CBOR encoded claim key/CBOR claim key/  
* I am unsure why you would think that encoded is needed here. 
* Should this be CWT rather than CBOR?
* Why is section 3.1 "Claim Names" rather than "Claim Keys"

In section 2:  Is there a reason not to define CWT claim value in this section

In section 3.1.1 and on - the following might be considered cleaner s/except 
that the format MUST be a/except that the value MUST be of type/

Section 9.1.2 - I would suggest assigning a name to the reserved entry

-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Monday, June 5, 2017 6:27 PM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments of the IETF.

Title   : CBOR Web Token (CWT)
Authors : Michael B. Jones
  Erik Wahlström
  Samuel Erdtman
  Hannes Tschofenig
Filename: draft-ietf-ace-cbor-web-token-05.txt
Pages   : 23
Date: 2017-06-05

Abstract:
   CBOR Web Token (CWT) is a compact means of representing claims to be
   transferred between two parties.  The claims in a CWT are encoded in
   the Concise Binary Object Representation (CBOR) and CBOR Object
   Signing and Encryption (COSE) is used for added application layer
   security protection.  A claim is a piece of information asserted
   about a subject and is represented as a name/value pair consisting of
   a claim name and a claim value.  CWT is derived from JSON Web Token
   (JWT), but uses CBOR rather than JSON.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-05
https://datatracker.ietf.org/doc/html/draft-ietf-ace-cbor-web-token-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cbor-web-token-05


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Jim Schaad]

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 <c...@tzi.org>
Cc: Jim Schaad <i...@augustcellars.com>; Samuel Erdtman <sam...@erdtman.se>; 
ace <Ace@ietf.org>
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 <michael.jo...@microsoft.com>
Cc: Jim Schaad <i...@augustcellars.com>; Samuel Erdtman <sam...@erdtman.se>; 
ace <Ace@ietf.org>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

On May 16, 2017, at 00:16, Mike Jones <michael.jo...@microsoft.com> 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

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Jim Schaad]

As things currently stand, I do not know that there is any way for an issuer to 
say that you must understand this claim to use this.  This is partly profile, 
but not entirely.

Jim


-Original Message-
From: Carsten Bormann [mailto:c...@tzi.org] 
Sent: Tuesday, May 16, 2017 3:26 PM
To: Mike Jones <michael.jo...@microsoft.com>
Cc: Jim Schaad <i...@augustcellars.com>; Samuel Erdtman <sam...@erdtman.se>; 
ace <Ace@ietf.org>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

On May 16, 2017, at 00:16, Mike Jones <michael.jo...@microsoft.com> 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

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Jim Schaad]

Actually, I think both of those were Carsten not me

 

From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Monday, May 15, 2017 3:17 PM
To: Jim Schaad <i...@augustcellars.com>; 'Samuel Erdtman' <sam...@erdtman.se>
Cc: 'ace' <Ace@ietf.org>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

I’ve gone through all the review feedback and agree with most of it.  There’s 
only two of the comments that I have issues with.

 

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.

 

I agree with the suggestion (tracked in 
https://github.com/erwah/ietf/issues/38) that we allow string-valued labels, 
but disagree that they should be restricted to non-production use.  Rather, per 
my comment in https://github.com/erwah/ietf/issues/40, I think we should use 
the same rules for allocating labels as COSE did.  That approach has already 
been widely reviewed and I believe is perfectly viable.  Note that this will 
also address the comment about the 1-65536 label range.

 

Thanks for your detailed review, as always, Jim.

 

-- Mike

 

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Monday, May 15, 2017 2:44 PM
To: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> >; 
'Samuel Erdtman' <sam...@erdtman.se <mailto:sam...@erdtman.se> >
Cc: 'ace' <Ace@ietf.org <mailto:Ace@ietf.org> >
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

Thanks for confirming this, Jim.  Since that’s the case, I’m fine with us going 
with requiring tags for the inner nested CWTs and dropping the use of the CWT 
content-type for this purpose.

 

        -- Mike

 

From: Jim Schaad [mailto:i...@augustcellars.com] 
Sent: Monday, May 15, 2017 2:31 PM
To: Mike Jones <michael.jo...@microsoft.com 
<mailto:michael.jo...@microsoft.com> >; 'Samuel Erdtman' <sam...@erdtman.se 
<mailto:sam...@erdtman.se> >
Cc: 'ace' <Ace@ietf.org <mailto:Ace@ietf.org> >
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

It is correct that the tag can be added and subtracted at will w/o changing 
anything.

 

 

 

From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Monday, May 15, 2017 2:17 PM
To: Samuel Erdtman <sam...@erdtman.se <mailto:sam...@erdtman.se> >; Jim Schaad 
<i...@augustcellars.com <mailto:i...@augustcellars.com> >
Cc: ace <Ace@ietf.org <mailto:Ace@ietf.org> >
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

I agree that for nested CWTs, it’s OK to mandate that the appropriate tags be 
prefixed to the inner CWT, if that’s the mechanism we decide to use to encode 
and detect nested JWTs.  That would then raise the question though, of whether 
we also would continue to mandate the use of the CWT content-type or whether we 
would drop this.  I think it’s better that we specify one mechanism for 
detecting nested CWTs, rather than having two.

 

Before we decide this, I’d like to confirm an assumption about COSE operations 
and COSE CBOR tags.  I believe that the COSE crypto operations *do not* cover 
the CBOR COSE tag, such as the COSE_Sign tag for signed objects.  If this is 
the case, it means that a COSE object without tags can have the appropriate tag 
prefixed to it without changing the crypto (and that similarly, a CWT tag could 
also be added without changing the crypto).  Is this correct?  If so, then 
using CBOR tags would be fine for the inner CWT in a nested CWT, since you 
could create the inner CWT without any tags and then later decide to put it in 
a nested CWT without re-signing, etc.  If this is the case, I’d be OK with 
always prefixing the inner CWT in a nested CWT with CWT and COSE CBOR tags.  
Whereas if adding the tags requires redoing the crypto, I’d rather stay with 
the current approach.

 

        -- Mike

 

From: Samuel Erdtman [mailto:sam...@erdtman.se] 
Sent: Monday, May 15, 2017 2:23 AM
To: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> >; Mike 
Jones <michael.jo...@microsoft.com <mailto:michael.jo...@microsoft.com> >
Cc: ace <Ace@ietf.org <mailto:Ace@ietf.org> >
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

Thanks for clarifications Jim, see my comments inline.

Mike, there is a question for you inlined too.

 

On Sun, May 14, 2017 at 10:12 PM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

 

 

From: Samuel Erdtman [mailto:sam...@erdtman.se <mailto:sam...@erdtman.se> ] 
Sent: Sunday, May 14, 2017 3:40 AM
To: Jim Schaad 

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Jim Schaad]

It is correct that the tag can be added and subtracted at will w/o changing 
anything.

 

 

 

From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Monday, May 15, 2017 2:17 PM
To: Samuel Erdtman <sam...@erdtman.se>; Jim Schaad <i...@augustcellars.com>
Cc: ace <Ace@ietf.org>
Subject: RE: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

I agree that for nested CWTs, it’s OK to mandate that the appropriate tags be 
prefixed to the inner CWT, if that’s the mechanism we decide to use to encode 
and detect nested JWTs.  That would then raise the question though, of whether 
we also would continue to mandate the use of the CWT content-type or whether we 
would drop this.  I think it’s better that we specify one mechanism for 
detecting nested CWTs, rather than having two.

 

Before we decide this, I’d like to confirm an assumption about COSE operations 
and COSE CBOR tags.  I believe that the COSE crypto operations *do not* cover 
the CBOR COSE tag, such as the COSE_Sign tag for signed objects.  If this is 
the case, it means that a COSE object without tags can have the appropriate tag 
prefixed to it without changing the crypto (and that similarly, a CWT tag could 
also be added without changing the crypto).  Is this correct?  If so, then 
using CBOR tags would be fine for the inner CWT in a nested CWT, since you 
could create the inner CWT without any tags and then later decide to put it in 
a nested CWT without re-signing, etc.  If this is the case, I’d be OK with 
always prefixing the inner CWT in a nested CWT with CWT and COSE CBOR tags.  
Whereas if adding the tags requires redoing the crypto, I’d rather stay with 
the current approach.

 

-- Mike

 

From: Samuel Erdtman [mailto:sam...@erdtman.se] 
Sent: Monday, May 15, 2017 2:23 AM
To: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> >; Mike 
Jones <michael.jo...@microsoft.com <mailto:michael.jo...@microsoft.com> >
Cc: ace <Ace@ietf.org <mailto:Ace@ietf.org> >
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

Thanks for clarifications Jim, see my comments inline.

Mike, there is a question for you inlined too.

 

On Sun, May 14, 2017 at 10:12 PM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

 

 

From: Samuel Erdtman [mailto:sam...@erdtman.se <mailto:sam...@erdtman.se> ] 
Sent: Sunday, May 14, 2017 3:40 AM
To: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> >
Cc: ace <Ace@ietf.org <mailto:Ace@ietf.org> >
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

Hi Jim,

Thanks for your review and comments, see some initial replies inline.

 

On Sat, Apr 22, 2017 at 8:47 PM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

Not ready to ship.


* I find the text for NumericDate confusing and would suggest this is a
cleaner wording.

The "NumericDate" term has the same meaning, syntax and
Processing rules as the "NumericDate" term defined in Section 2 of
JWT [RFC7519], except that the CBOR numeric representation
(Section 2.4.1 of [RC7049]) is used.  The encoding is modified so that
the leading tag (6.1 or 0xC1) MUST be omitted.



 

Could make sense, I created an issue in the issue tracker to look at this.

 


* What is a "CWT NumericDate" ?  Why is this not just a "NumericDate"?  You
should be consistent on how you are using this and the "StringOrURI" type
identifier.  Either use the CWT prefix or don't.


Makes sense to me, created an issue in the issue tracker to address this.
 


* s/except that a CWT StringOrURI/except that for a CWT, StringOrURI/


 Makes sense to me, created an issue in the issue tracker to address this.


* The algorithm for doing nesting detection is a gross abuse of the content
type parameter and can be far more easily done based on the already present
tagging of the COSE object.

 

Could you please explain a bit more, we are using the COSE tags but have made 
them optional if the application for example only uses one thyme then it would 
always know what to do and would not need to parse the tag saving a byte.

 

[JLS] The concept is pretty easy to explain.

 

If you are in a situation where the full description of the CWT – including 
nesting layering – is known from a profile, then there would be no need to have 
any COSE tags present on any layer of the CWT message.  I would however highly 
discourage using this situation for anything but a single layer CWT such as one 
that is based on the COSE_Encrypt0 message without any inner layering.  Doing 
otherwise is going to mean that libraries would be unable to automatically 
unwrap all of the layers on their own, but would need guidance on each layer as 
it was processed.

 

In the current document in step 5 of section 7.2,

Re: [Ace] New OAuth client credentials RPK and PSK

[Jim Schaad]

How is this draft supposed to interact with draft-gerdes-ace-dtls-authorize?

 

Jim

 

 

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Samuel Erdtman
Sent: Friday, May 12, 2017 1:03 AM
To:  ; ace 
Cc: Ludwig Seitz 
Subject: [Ace] New OAuth client credentials RPK and PSK

 

Hi ACE and OAuth WGs,

I and Ludwig submitted a new draft yesterday defining how to use Raw Public Key 
and Pre Shared Key with (D)TLS as OAuth client credentials, 
https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/.

 

We think this is valuable to the ACE work since the ACE framework is based on 
OAuth, but client credentials as defined in the OAuth framework are not the 
best match for embedded devices.

We think Raw Public Keys and Pre Shared Keys are more suitable credentials for 
embedded devices for the following reasons:

* Better security by binding to transport layer.

* If PSK DTLS is to be used a key need to be distributed any way, why not make 
use of it as credential.

* Client id and client secret accommodates for manual input by a humans. This 
does not scale well and requires some for of input device.

* Some/many devices will have crypto-hardware that can protect key material, to 
not use that possibility would be a waste.

* There are probably more reasons these was just the once on top of my head.

 

This is not the first resent initiative to create new client credential types, 
the OAuth WG adopted a similar draft for certificate based client credentials 
(https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html). That work is also 
valuable to ACE but not all devices will be able to work with certificates or 
even asymmetric cryptos .

Please review and comment.

Cheers

//Samuel

 

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Jim Schaad]

 

 

From: Samuel Erdtman [mailto:sam...@erdtman.se] 
Sent: Sunday, May 14, 2017 3:40 AM
To: Jim Schaad <i...@augustcellars.com>
Cc: ace <Ace@ietf.org>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

 

Hi Jim,

Thanks for your review and comments, see some initial replies inline.

 

On Sat, Apr 22, 2017 at 8:47 PM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

Not ready to ship.


* I find the text for NumericDate confusing and would suggest this is a
cleaner wording.

The "NumericDate" term has the same meaning, syntax and
Processing rules as the "NumericDate" term defined in Section 2 of
JWT [RFC7519], except that the CBOR numeric representation
(Section 2.4.1 of [RC7049]) is used.  The encoding is modified so that
the leading tag (6.1 or 0xC1) MUST be omitted.



 

Could make sense, I created an issue in the issue tracker to look at this.

 


* What is a "CWT NumericDate" ?  Why is this not just a "NumericDate"?  You
should be consistent on how you are using this and the "StringOrURI" type
identifier.  Either use the CWT prefix or don't.


Makes sense to me, created an issue in the issue tracker to address this.
 


* s/except that a CWT StringOrURI/except that for a CWT, StringOrURI/


 Makes sense to me, created an issue in the issue tracker to address this.


* The algorithm for doing nesting detection is a gross abuse of the content
type parameter and can be far more easily done based on the already present
tagging of the COSE object.

 

Could you please explain a bit more, we are using the COSE tags but have made 
them optional if the application for example only uses one thyme then it would 
always know what to do and would not need to parse the tag saving a byte.

 

[JLS] The concept is pretty easy to explain.

 

If you are in a situation where the full description of the CWT – including 
nesting layering – is known from a profile, then there would be no need to have 
any COSE tags present on any layer of the CWT message.  I would however highly 
discourage using this situation for anything but a single layer CWT such as one 
that is based on the COSE_Encrypt0 message without any inner layering.  Doing 
otherwise is going to mean that libraries would be unable to automatically 
unwrap all of the layers on their own, but would need guidance on each layer as 
it was processed.

 

In the current document in step 5 of section 7.2, there is an assumption that a 
COSE tag is going to exist in order to distinguish between the different types 
of COSE messages – I would not that these tags are not explicitly called for in 
section 7.1 – so the algorithm that I am going to suggest means that they are 
supposed to be present not implicit in any event.

 

In section 7.2 in step 7 the algorithm becomes:

If the payload starts with one the of COSE identification tags, then the 
message is recursive – go to step 1, wash rinse and repeat.

 


* Break section 8 into multiple paragraphs that deal with different types of
issues.


Might be reasonable I have created an issue in the issue tracker so that the 
comment is not lost.
 


* In section 8, the first sentence implies to me that you believe that COSE
is more of a problem that breaking of cryptographic algorithms, trust of
certificates/keys.  Not sure what needs to be done, but better clarity may
be a good idea.

 

Added this to the previously mentioned issue to address this to since it is in 
the same section 


* I have not done any validation of the examples.   You might want to have
an example which uses the real for one of the time types.

 

Sorry, but I don´t get it could you add some more context.

 

[JLS] Use the value of “1444064944.5” for one of the time values.  Although I 
doubt that less than second resolution is needed in almost any case, having an 
example where it is given is still a good idea.
 
Jim
 

 

 


Jim



-Original Message-
From: Ace [mailto:ace-boun...@ietf.org <mailto:ace-boun...@ietf.org> ] On 
Behalf Of Kepeng Li
Sent: Thursday, April 20, 2017 2:53 PM
To: ace@ietf.org <mailto:ace@ietf.org> 
Cc: Hannes Tschofenig <hannes.tschofe...@gmx.net 
<mailto:hannes.tschofe...@gmx.net> >
Subject: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

In Chicago, it was decided that we were going to WGLC the ACE CBOR Web Token
draft.

So this starts a working group last call for draft-ietf-ace-cbor-web-token
for submission as a Standards Track RFC, ending on 24:00 PDT on Tuesday, May
2, 2017.

The specification is available at:
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-04

An HTML-formatted version is also available at:
http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-04.html

Thanks,


Kind Regards
Kepeng & Hannes


___
Ace mailing list
Ace@ietf.org <mailto:Ace@ietf.org> 
https://www.ietf.org/mailman/list

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

[Jim Schaad]

Not ready to ship.


* I find the text for NumericDate confusing and would suggest this is a
cleaner wording.

The "NumericDate" term has the same meaning, syntax and
Processing rules as the "NumericDate" term defined in Section 2 of
JWT [RFC7519], except that the CBOR numeric representation
(Section 2.4.1 of [RC7049]) is used.  The encoding is modified so that
the leading tag (6.1 or 0xC1) MUST be omitted.



* What is a "CWT NumericDate" ?  Why is this not just a "NumericDate"?  You
should be consistent on how you are using this and the "StringOrURI" type
identifier.  Either use the CWT prefix or don't.

* s/except that a CWT StringOrURI/except that for a CWT, StringOrURI/

* The algorithm for doing nesting detection is a gross abuse of the content
type parameter and can be far more easily done based on the already present
tagging of the COSE object.

* Break section 8 into multiple paragraphs that deal with different types of
issues.

* In section 8, the first sentence implies to me that you believe that COSE
is more of a problem that breaking of cryptographic algorithms, trust of
certificates/keys.  Not sure what needs to be done, but better clarity may
be a good idea.

* I have not done any validation of the examples.   You might want to have
an example which uses the real for one of the time types.

Jim


-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Kepeng Li
Sent: Thursday, April 20, 2017 2:53 PM
To: ace@ietf.org
Cc: Hannes Tschofenig 
Subject: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

In Chicago, it was decided that we were going to WGLC the ACE CBOR Web Token
draft.

So this starts a working group last call for draft-ietf-ace-cbor-web-token
for submission as a Standards Track RFC, ending on 24:00 PDT on Tuesday, May
2, 2017.

The specification is available at:
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-04

An HTML-formatted version is also available at:
http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-04.html

Thanks,


Kind Regards
Kepeng & Hannes


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

[Jim Schaad]

 

 

From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Wednesday, April 5, 2017 6:02 PM
To: Samuel Erdtman <sam...@erdtman.se>; Jim Schaad <i...@augustcellars.com>
Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace <Ace@ietf.org>
Subject: RE: [Ace] Review of draft-ietf-ace-cbor-web-token-03

 

Let me second the thanks for the thorough review, Jim, and especially for 
validating the examples.  Replies to some of the points are inline…

 

-- Mike

 

From: Samuel Erdtman [mailto:sam...@erdtman.se] 
Sent: Sunday, April 2, 2017 10:58 PM
To: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> >
Cc: draft-ietf-ace-cbor-web-to...@ietf.org 
<mailto:draft-ietf-ace-cbor-web-to...@ietf.org> ; ace <Ace@ietf.org 
<mailto:Ace@ietf.org> >
Subject: Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

 

Thanks for the review Jim,

See inline comments

 

On Sat, Apr 1, 2017 at 5:03 AM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

Given that it was stated that the authors believe that the document was
ready for publication, I decided to do another review pass.

1.  Following the discussion in the SET WG meeting, I believe that it would
be reasonable to define some inputs for the external data fields to allow
for distinguishing between the different uses of JWT structures.  Language
about different applications extending this structure would also be
reasonable.

 

I was not part of that discussion, could you please link to some resource or 
notes from that meeting.

In the SecEvent WG, after I gave this invited presentation on JOSE/JWT security 
<https://www.ietf.org/proceedings/98/slides/slides-98-secevent-josejwt-security-update-00.pdf>
 , there was a discussion on whether it would be useful to document best 
practices on using JWTs.  After the repeating the same presentation in the 
OAuth working group, it was agreed that we would do that and I would write down 
some of the possible issues using JWTs and mitigations.  Some of this will be 
in the form of advice to implementers.  Some of it will be advice to protocol 
designers.  Given that CWTs are intentionally parallel to JWTs, I expect that 
much of the JWT BCP language will also apply to CWTs.  I’ll make a mental note 
to also be thinking about CWTs when writing about JWTs.

 

 

2.  I do not know if the authors looked at changing the Type3StringOrURI so
that it would explicitly tag URIs or not.  I do no remember seeing any
discussions on the list but have not gone back to search

 

We have no looked at changing this. Is there any good motivation for actually 
doing this change?

 

Having it just be a string as it is now is parallel with JWTs (which don’t have 
the tagging option available to them). My inclination is to keep it parallel.  
Alternatively, we could say that it’s also legal to tag the value as a URI if 
it is one.  What do others think?

 


3.  I find the description of Type6NumericDate to be slightly confusing as
it appears to imply that this is not using a numeric value when it does.

 

I think the idea is to say that it is not a JSON number but a CBOR number. I 
have added a ticket to look at the wording.
https://github.com/erwah/ietf/issues/28

I agree that clearer wording can be used, talking about a CBOR number tagged as 
a numeric date. 

 


4.  The authors need to look at their use of Type6NumericDate and determine
if this is what they really want to do.  All of the examples are incorrect
because of this tag usage.

 

Examples should be updated, see below

 


5.  After the discussions in the SET group, do the authors which to
re-consider the MUST ignore statement in the first paragraph of section 3?

 

I have not seen the SET group discussion could you please link to it.

 

Ignoring claims that are not understood is critical to extensibility.  It’s 
served JWTs well and will serve CWTs well in the same regard.  Without this, 
every system using a CWT would be brittle by design.

 


6.  The string "6 tag value 1" is normally written as "6.1" when looking at
pretty-printed CBOR diagnostics.   This would be clearer than what is
written.


Good input, I have create an issue to update this, 
https://github.com/erwah/ietf/issues/26
 


7.  The text should be altered to use a TBD for the CWT tag rather than
using a constant so this is highlighted.

 

Good input, I have create an issue to update this, 
https://github.com/erwah/ietf/issues/25

 

I disagree with this.  The values in the registry are already marked as “TBD 
(maybe 61)”.  It would just add clutter, detracting from the readability of the 
spec, to replicate this elsewhere.  Besides, the examples need a specific 
number.  If IANA changes the number, we will of course, update the spec 
accordingly, once a final assignment is determined.

 

 

[JLS] – This is the defin

Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

[Jim Schaad]

Some comments inline

 

 

From: Samuel Erdtman [mailto:sam...@erdtman.se] 
Sent: Sunday, April 2, 2017 10:58 PM
To: Jim Schaad <i...@augustcellars.com>
Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace <Ace@ietf.org>
Subject: Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

 

Thanks for the review Jim,

See inline comments

 

On Sat, Apr 1, 2017 at 5:03 AM, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

Given that it was stated that the authors believe that the document was
ready for publication, I decided to do another review pass.

1.  Following the discussion in the SET WG meeting, I believe that it would
be reasonable to define some inputs for the external data fields to allow
for distinguishing between the different uses of JWT structures.  Language
about different applications extending this structure would also be
reasonable.

 

I was not part of that discussion, could you please link to some resource or 
notes from that meeting.

 

[JLS] As noted in an earlier message, I got the name of the WG wrong.  The 
document is SET and the WG is secevent.  Given that Mike was doing the 
presentation, I would suggest talking to him about the issues presented.  The 
issues involved how to prevent a SET being used as a JWT as an access token.

 

 

2.  I do not know if the authors looked at changing the Type3StringOrURI so
that it would explicitly tag URIs or not.  I do no remember seeing any
discussions on the list but have not gone back to search

 

We have no looked at changing this. Is there any good motivation for actually 
doing this change?

 

[JLS] If you tagged URIs, which is presumably easy for the creator, then the 
recipient does not have to do any work to try and distinguish between a string 
and a URI.  The cost is that the token is going to be one byte longer per tag.  
This is not done for JWT and therefore code needs to exist on the user of a JWT 
to figure out if it is a URI.

 


3.  I find the description of Type6NumericDate to be slightly confusing as
it appears to imply that this is not using a numeric value when it does.

 

I think the idea is to say that it is not a JSON number but a CBOR number. I 
have added a ticket to look at the wording.
https://github.com/erwah/ietf/issues/28

 


4.  The authors need to look at their use of Type6NumericDate and determine
if this is what they really want to do.  All of the examples are incorrect
because of this tag usage.

 

Examples should be updated, see below

 


5.  After the discussions in the SET group, do the authors which to
re-consider the MUST ignore statement in the first paragraph of section 3?

 

I have not seen the SET group discussion could you please link to it.

 


6.  The string "6 tag value 1" is normally written as "6.1" when looking at
pretty-printed CBOR diagnostics.   This would be clearer than what is
written.


Good input, I have create an issue to update this, 
https://github.com/erwah/ietf/issues/26
 


7.  The text should be altered to use a TBD for the CWT tag rather than
using a constant so this is highlighted.

 

Good input, I have create an issue to update this, 
https://github.com/erwah/ietf/issues/25

 


8.  The note for step 5 in section 6.1 is problematic from a number of
things.  A) AEAD algorithms are required, so it is not clear that the
recommendation makes sense.  B) there is a big difference between signing
and MACing in terms of the amount and type of integrity provided.  Replacing
signing w/ AEAD loses a lot.

 

I think you are correct and I have considered removing it, I added in in an 
early attempt to be smart.

I have added a issue to evaluate the value of this statement and remove if 
considered useless.
https://github.com/erwah/ietf/issues/24


 


9.  Step 6 in section 6.1 does not agree w/ the language in section 5.  MUST
vs maybe.

 

I see your point. I have added a ticket to look over the create and verify 
steps to make sure they are consistent.
https://github.com/erwah/ietf/issues/27

 


10.  In starting to verify the examples I ran across the following two
issues:

a) The hex string and the diagnostic notation are equivalent, but they are
not the same.  Specifically, the order of claims is not the same.  CBOR.ME 
<http://CBOR.ME> 
gives

{2: "erikw", 3: "coap://light.example.com <http://light.example.com> ", 4: 
1444064944, 5: 1443944944, 6:
1443944944, 1: "coap://as.example.com <http://as.example.com> ", 7: h'0b71'}

 

I have create a issue to make them the same to make reading and testing easier, 
https://github.com/erwah/ietf/issues/23

 


b) The encoding of some of the claims is incorrect according to the
document.  It should be

 

You are correct, I have added an issue to update, 
https://github.com/erwah/ietf/issues/22

 

[JLS] You can find some candidate encodings in the examples github for COSE.

 

Jim

 


{ 1: "

Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

[Jim Schaad]

It has been pointed out to me that I was incorrect when I thought that the TLA 
for the WG was SET.  It should be secevent.

 

Jim

 

 

From: Samuel Erdtman [mailto:sam...@erdtman.se] 
Sent: Sunday, April 2, 2017 10:58 PM
To: Jim Schaad <i...@augustcellars.com>
Cc: draft-ietf-ace-cbor-web-to...@ietf.org; ace <Ace@ietf.org>
Subject: Re: [Ace] Review of draft-ietf-ace-cbor-web-token-03

 

Thanks for the review Jim,

See inline comments

 

On Sat, Apr 1, 2017 at 5:03 AM, Jim Schaad <i...@augustcellars.com> wrote:

Given that it was stated that the authors believe that the document was
ready for publication, I decided to do another review pass.

1.  Following the discussion in the SET WG meeting, I believe that it would
be reasonable to define some inputs for the external data fields to allow
for distinguishing between the different uses of JWT structures.  Language
about different applications extending this structure would also be
reasonable.

 

I was not part of that discussion, could you please link to some resource or 
notes from that meeting.
 

 

2.  I do not know if the authors looked at changing the Type3StringOrURI so
that it would explicitly tag URIs or not.  I do no remember seeing any
discussions on the list but have not gone back to search

 

We have no looked at changing this. Is there any good motivation for actually 
doing this change?

 


3.  I find the description of Type6NumericDate to be slightly confusing as
it appears to imply that this is not using a numeric value when it does.

 

I think the idea is to say that it is not a JSON number but a CBOR number. I 
have added a ticket to look at the wording.
https://github.com/erwah/ietf/issues/28

 


4.  The authors need to look at their use of Type6NumericDate and determine
if this is what they really want to do.  All of the examples are incorrect
because of this tag usage.

 

Examples should be updated, see below

 


5.  After the discussions in the SET group, do the authors which to
re-consider the MUST ignore statement in the first paragraph of section 3?

 

I have not seen the SET group discussion could you please link to it.

 


6.  The string "6 tag value 1" is normally written as "6.1" when looking at
pretty-printed CBOR diagnostics.   This would be clearer than what is
written.


Good input, I have create an issue to update this, 
https://github.com/erwah/ietf/issues/26
 


7.  The text should be altered to use a TBD for the CWT tag rather than
using a constant so this is highlighted.

 

Good input, I have create an issue to update this, 
https://github.com/erwah/ietf/issues/25

 


8.  The note for step 5 in section 6.1 is problematic from a number of
things.  A) AEAD algorithms are required, so it is not clear that the
recommendation makes sense.  B) there is a big difference between signing
and MACing in terms of the amount and type of integrity provided.  Replacing
signing w/ AEAD loses a lot.

 

I think you are correct and I have considered removing it, I added in in an 
early attempt to be smart.

I have added a issue to evaluate the value of this statement and remove if 
considered useless.
https://github.com/erwah/ietf/issues/24


 


9.  Step 6 in section 6.1 does not agree w/ the language in section 5.  MUST
vs maybe.

 

I see your point. I have added a ticket to look over the create and verify 
steps to make sure they are consistent.
https://github.com/erwah/ietf/issues/27

 


10.  In starting to verify the examples I ran across the following two
issues:

a) The hex string and the diagnostic notation are equivalent, but they are
not the same.  Specifically, the order of claims is not the same.  CBOR.ME 
<http://CBOR.ME> 
gives

{2: "erikw", 3: "coap://light.example.com <http://light.example.com> ", 4: 
1444064944, 5: 1443944944, 6:
1443944944, 1: "coap://as.example.com <http://as.example.com> ", 7: h'0b71'}

 

I have create a issue to make them the same to make reading and testing easier, 
https://github.com/erwah/ietf/issues/23

 


b) The encoding of some of the claims is incorrect according to the
document.  It should be

 

You are correct, I have added an issue to update, 
https://github.com/erwah/ietf/issues/22

 


{ 1: "coap://as.example.com <http://as.example.com> ", 2: "erikw", 3: 
"coap://light.example.com <http://light.example.com> ", 4:
1(1444064944), 5: 1(1443944944), 6: 1(1443944944),7: h'0b71'}

Or

a7  # map(7)
   01   # unsigned(1)
   75   # text(21)
  636f61703a2f2f61732e6578616d706c652e636f6d # "coap://as.example.com 
<http://as.example.com> "
   02   # unsigned(2)
   65   # text(5)
  6572696b77# "erikw"
   03

[Ace] Review of draft-ietf-ace-cbor-web-token-03

[Jim Schaad]

Given that it was stated that the authors believe that the document was
ready for publication, I decided to do another review pass.

1.  Following the discussion in the SET WG meeting, I believe that it would
be reasonable to define some inputs for the external data fields to allow
for distinguishing between the different uses of JWT structures.  Language
about different applications extending this structure would also be
reasonable.

2.  I do not know if the authors looked at changing the Type3StringOrURI so
that it would explicitly tag URIs or not.  I do no remember seeing any
discussions on the list but have not gone back to search

3.  I find the description of Type6NumericDate to be slightly confusing as
it appears to imply that this is not using a numeric value when it does.

4.  The authors need to look at their use of Type6NumericDate and determine
if this is what they really want to do.  All of the examples are incorrect
because of this tag usage.

5.  After the discussions in the SET group, do the authors which to
re-consider the MUST ignore statement in the first paragraph of section 3?

6.  The string "6 tag value 1" is normally written as "6.1" when looking at
pretty-printed CBOR diagnostics.   This would be clearer than what is
written.

7.  The text should be altered to use a TBD for the CWT tag rather than
using a constant so this is highlighted.

8.  The note for step 5 in section 6.1 is problematic from a number of
things.  A) AEAD algorithms are required, so it is not clear that the
recommendation makes sense.  B) there is a big difference between signing
and MACing in terms of the amount and type of integrity provided.  Replacing
signing w/ AEAD loses a lot.

9.  Step 6 in section 6.1 does not agree w/ the language in section 5.  MUST
vs maybe.

10.  In starting to verify the examples I ran across the following two
issues:

a) The hex string and the diagnostic notation are equivalent, but they are
not the same.  Specifically, the order of claims is not the same.  CBOR.ME
gives

{2: "erikw", 3: "coap://light.example.com", 4: 1444064944, 5: 1443944944, 6:
1443944944, 1: "coap://as.example.com", 7: h'0b71'}

b) The encoding of some of the claims is incorrect according to the
document.  It should be

{ 1: "coap://as.example.com", 2: "erikw", 3: "coap://light.example.com", 4:
1(1444064944), 5: 1(1443944944), 6: 1(1443944944),7: h'0b71'}

Or

a7  # map(7)
   01   # unsigned(1)
   75   # text(21)
  636f61703a2f2f61732e6578616d706c652e636f6d # "coap://as.example.com"
   02   # unsigned(2)
   65   # text(5)
  6572696b77# "erikw"
   03   # unsigned(3)
   78 18# text(24)
  636f61703a2f2f6c696768742e6578616d706c652e636f6d #
"coap://light.example.com"
   04   # unsigned(4)
   c1   # tag(1)
  1a 5612aeb0   # unsigned(1444064944)
   05   # unsigned(5)
   c1   # tag(1)
  1a 5610d9f0   # unsigned(1443944944)
   06   # unsigned(6)
   c1   # tag(1)
  1a 5610d9f0   # unsigned(1443944944)
   07   # unsigned(7)
   42   # bytes(2)
  0b71  # "\vq"

Note the additional tagging which is required.


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Call for adoption for draft-somaraju-ace-multicast-02

[Jim Schaad]

It might just take one more update for me to feel happy with this.  However,
an update of the document has not yet been forth coming since I asked for a
couple of different types of things for the security solutions and so forth.
I would hope that the authors are not waiting for the outcome of this
adoption call as a gating factor to produce such an update.

jim

> -Original Message-
> From: peter van der Stok [mailto:stokc...@xs4all.nl]
> Sent: Tuesday, March 7, 2017 12:33 AM
> To: Jim Schaad <i...@augustcellars.com>
> Cc: 'Kepeng Li' <kepeng@alibaba-inc.com>; Ace@ietf.org
> Subject: Re: [Ace] Call for adoption for draft-somaraju-ace-multicast-02
> 
> After reading Jim's statement, my position is a bit different.
> Multicast security is severely needed.
> Not making it a WG document augments the risk that the subject is frozen
> and no progress is made.
> To guarantee progress, adoption seems to me the right way forward.
> 
> Peter
> 
> Jim Schaad schreef op 2017-03-07 02:55:
> > After thinking about this for a long time, I will reluctantly state a
> > position.
> >
> > I do not believe that the WG should adopt this document at least until
> > such a time as a version has been released which does a substantially
> > better job of restricting the scope of the problem to be solved.  If
> > the WG then decides to relax that scope so be it.
> >
> > Jim
> >
> > FROM: Ace [mailto:ace-boun...@ietf.org] ON BEHALF OF Kepeng Li
> > SENT: Thursday, February 23, 2017 1:48 AM
> > TO: Ace@ietf.org
> > CC: Kathleen Moriarty <kathleen.moriarty.i...@gmail.com>; Hannes
> > Tschofenig <hannes.tschofe...@gmx.net>
> > SUBJECT: [Ace] Call for adoption for draft-somaraju-ace-multicast-02
> >
> > Hello all,
> >
> > This note begins a Call For Adoption for
> > draft-somaraju-ace-multicast-02 [1] to be adopted as an ACE working
> > group item, and added in the charter. The call ends on Mar 7, 2017.
> >
> > Keep in mind that adoption of a document does not mean the document
> > as-is is ready for publication. It is merely acceptance of the
> > document as a starting point for what will be the final product of the
> > ACE working group. The working group is free to make changes to the
> > document according to the normal consensus process.
> >
> > Please reply on this thread with expressions of support or opposition,
> > preferably with comments, regarding accepting this as a work item.
> >
> > Thanks,
> >
> > Kind Regards
> >
> > Kepeng (ACE co-chair)
> >
> > [1] https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/
> > ___
> > Ace mailing list
> > Ace@ietf.org
> > https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Call for adoption for draft-somaraju-ace-multicast-02

[Jim Schaad]

And of course, the asymmetric solution is not the one that is currently in
the document.

> -Original Message-
> From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
> Sent: Tuesday, March 7, 2017 11:14 AM
> To: Derek Atkins <de...@ihtfp.com>; peter van der Stok
> <stokc...@xs4all.nl>
> Cc: Jim Schaad <i...@augustcellars.com>; 'Kepeng Li' <kepeng.lkp@alibaba-
> inc.com>; consulta...@vanderstok.org; Ace@ietf.org
> Subject: Re: [Ace] Call for adoption for draft-somaraju-ace-multicast-02
> 
> Hi Derek
> 
> we discussed the requirements quite a bit in the group already and the
> conclusion of the discussion was that we provide two solutions, one based
> on symmetric keys and the other based on asymmetric keys.
> 
> The asymmetric key solution provides authentication of the individual
sender
> where the symmetric key solution demonstrates knowledge of the group
> key.
> 
> Ciao
> Hannes
> 
> 
> On 03/07/2017 06:23 PM, Derek Atkins wrote:
> > Peter,
> >
> > peter van der Stok <stokc...@xs4all.nl> writes:
> >
> >> After reading Jim's statement, my position is a bit different.
> >> Multicast security is severely needed.
> >> Not making it a WG document augments the risk that the subject is
> >> frozen and no progress is made.
> >> To guarantee progress, adoption seems to me the right way forward.
> >
> > Can you please define what you mean by "Multicast Security"?  Are you
> > just looking for Group Confidentiality?  Do you want Group Message
> > Integrity without Source Authentication?  Do you want Source
> > Authentication?  "multicast security" is too generic a term by itself
> > and as others have pointed out depending on which specific security
> > services you're talking about you will get a multitude of (potentially
> > conflicting) requirements.  For example, you cannot get source
> > authentication with a shared-key-only solution.
> >
> > I recommend that, before adoption, an explicit set of requirements be
> > defined and inserted into the scope.
> >
> >> Peter
> >>
> >> Jim Schaad schreef op 2017-03-07 02:55:
> >>> After thinking about this for a long time, I will reluctantly state
> >>> a position.
> >>>
> >>> I do not believe that the WG should adopt this document at least
> >>> until such a time as a version has been released which does a
> >>> substantially better job of restricting the scope of the problem to
> >>> be solved.  If the WG then decides to relax that scope so be it.
> >>>
> >>> Jim
> >
> > -derek
> >


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Call for adoption for draft-somaraju-ace-multicast-02

[Jim Schaad]

After thinking about this for a long time, I will reluctantly state a
position.

 

I do not believe that the WG should adopt this document at least until such
a time as a version has been released which does a substantially better job
of restricting the scope of the problem to be solved.  If the WG then
decides to relax that scope so be it.

 

Jim

 

 

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Kepeng Li
Sent: Thursday, February 23, 2017 1:48 AM
To: Ace@ietf.org
Cc: Kathleen Moriarty ; Hannes Tschofenig

Subject: [Ace] Call for adoption for draft-somaraju-ace-multicast-02

 

Hello all,

 
This note begins a Call For Adoption for draft-somaraju-ace-multicast-02 [1]
to be adopted as an ACE working group item, and added in the charter. The
call ends on Mar 7, 2017.

 

Keep in mind that adoption of a document does not mean the document as-is is
ready for publication. It is merely acceptance of the document as a starting
point for what will be the final product of the ACE working group. The
working group is free to make changes to the document according to the
normal consensus process.
 
Please reply on this thread with expressions of support or opposition,
preferably with comments, regarding accepting this as a work item.

 

Thanks,
 
Kind Regards
Kepeng (ACE co-chair)

 

[1] https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Questions on draft-ietf-ace-oauth-authz

[Jim Schaad]

In going through and starting to map out how an implementation would work, I
have started getting some questions.

1.  What is the difference between scope and audience, and is there an
expected way that these values would relate to a CoAP URI?  From OAuth, I
would have generally expected scope to identify one or more resources to be
accessed.  However, this document requires that an audience either be
explicit or implicit and thus identifying things just by scope would not
work.

My basic expectation is that the scope and audience would normally be copied
into the access token after doing grant evaluation.  This means that we are
looking at three different entities that need to be able to understand how
things fields interact.

>From my reading an audience could be anything from a host name to a full URI
or even a group name depending on the application being processed.  Is this
correct?

2.  When a cnf is sent as part of a request, are there any plans for the
ability to do a POP as part of this being thought about?  If not, is the
expectation that one would only offer an asymmetric key in a cnf if it had
already be provided to the AS?

Jim


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] draft-somaraju-ace-multicast

[Jim Schaad]

See Below

 

 

 

From: Somaraju Abhinav [mailto:abhinav.somar...@tridonic.com] 
Sent: Monday, February 6, 2017 12:01 PM
To: Jim Schaad <i...@augustcellars.com>;
draft-somaraju-ace-multic...@tools.ietf.org
Cc: 'ace' <ace@ietf.org>
Subject: Re: [Ace] draft-somaraju-ace-multicast

 

Jim, All,

 

please see a proposal for the Applicability statement that can be used as a
starting point for the Webex.

 

Abhinav

 

[JLS] Did you actually change anything from the current document.  At first
glance it looks like a cut and paste with absolutely no response to any of
the issues that have been raised on the list.

 

5.1 Applicability statement

 

[JLS] This should have a description of the criteria which should be used to
determine if any of the solutions here are needed.  Without this
information, it seems that the solution could be applied to anything.  Is
this really just a lighting solution or is it a more general solution?

 

This document describes two architectures based on symmetric group keys in
Section 3 and asymmetric keys in Section 4. 

[JLS] Based on the mails we have exchanged; this statement is either wrong
or insufficiently qualified.  You have stated that even the messages in
section 4 need to be encrypted and thus might have a group key.

 

The symmetric key solution is based on a group key that is shared between
all group members including senders and receivers.  As all members of the
group posses the same key, it is only possible to   authenticate group
membership for the source of a message. In   particular, it is not possible
to authenticate the unique source of a   message and consequently it is not
possible to authorize a single node to control a group. This implies in
particular that any hacked receiver in a group could then be used to control
all the receivers in the group. 

 

Moreover, because the group key is shared across multiple nodes, it may be
easier for an attacker to determine the group key by attacking any member of
the group (note that this group key is dynamically generated and is usually
stored in volatile memory which offers some additional protection). The
probability of a stolen key increases with the number of nodes that are in
possession of the key. Moreover, subsequent to such an attack, it is also
difficult to determine which of the group members was compromised and this
makes it difficult to return the system to normal operation after an attack.


[JLS] I have no idea why storing a key in volatile memory would offer
additional protections.

[JLS] Losing power is going to lead to potentially very long delays at power
and missed processing of messages if every recipient needs to individually
generate a new dynamic key and distribute it, not to mention the potential
problems with the question of who has good randomness for the generation of
new keys.

[JLS] Which group members are/were compromised.  You don't know that it has
gone away.

[JLS] This text does not address the questions of size and homogeneity of
groups.  One of the issues that has been brought up is about using the same
key for multiple types of devices such as lights and doors.

 

 

The asymmetric key solution distinguishes between a sender in the group and
the receivers. In particular, the sender is in possession of a private key
and the receivers are in possession of the corresponding public key.  This
allows the unique source of any group message to be authenticated. Moreover,
an attacker cannot compromise   the system by breaking into any of the
receiving nodes. However, for constrained devices, the asymmetric key
solution comes at a processing cost with cryptographic computations taking
rather long.   

[JLS] The last sentence does not belong here.  The term "rather long" is
extremely vague and is even worse than the term "low-latency" in terms of
what has been defined.

[JLS] Should also know that the sender that was compromised is immediately
known and can be dealt with.

 

 

Therefore, it is recommended that whenever possible, the architecture with
source authentication SHOULD be used to secure all multicast communication.
However, in less sensitive applications where low-latency group
communication is important (e.g. controlling luminaires in non-emergency
applications), the   architecture without source authentication MAY be used.
In sensitive applications such as health and safety, building security and
emergency applications the symmetric key based solution SHOULD not be used. 

[JLS] Personally, I would not know how to test this, so I don't believe that
RFC 2119 language is appropriate.

[JLS] Why should emergency applications be different?  Does this mean that
all devices need to implement both solutions and need to figure out which of
the solutions should be used at any given time?  What defines a sensitive
application?  The ability to monitor a sensor even if the state of the
lights is not?

 

 

When using the symmetric key solution two 

Re: [Ace] draft-somaraju-ace-multicast

[Jim Schaad]

See comments inline

 

 

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Somaraju Abhinav
Sent: 02 February 2017 03:48
To: Jim Schaad <i...@augustcellars.com>;
draft-somaraju-ace-multic...@tools.ietf.org
Cc: 'ace' <ace@ietf.org>
Subject: Re: [Ace] draft-somaraju-ace-multicast

 

Hi Jim,

thank you for the review and I apologise for the delayed response - I was on
sick leave due to a surgery. Please see comments inline from the authors. 

 

Why restriction on reading messages?  It is not like an external observer is
not going to be able to see the lights go on or off.
[AS] There are several situations where lights are not visible but
(multicast) network data is accessible. Moreover, sensors (e.g. presence
detectors) are continuously talking to actuators and controllers without
necessarily having a visible effect on the lights. For several customers
privacy is a very important concern and is almost a given. The statement
"anybody can listen to the traffic and tell when sensors detect presence in
a building without even being in the building" is a very difficult sell.
Having said that, it is true that simply encrypting the multicast traffic at
the application layer is only a prerequisite to provide the privacy needed
and additional work is required (e.g. generating random messages at
different times). In that sense the symmetric solution is probably not much
better than the asymmetric solution. But the demand for privacy from
customers is very clear and the perception among them is that unencrypted
data implies poor security.

[JLS] I am sensing a problem here.  You have stated that there is a
requirement that encryption is a requirement that people are going to say
must be me.  However, below you have stated that if authentication is a
requirement then encryption suddenly becomes a non-requirement?  You appear
to be stating that there are circumstances where it is fine not to have the
data encrypted if one needs to know where it came from.

 

Consider the following case   I have a sensor in a room.  When the sensor
sees movement, it broadcasts a lights one command.  The command is picked up
by both the lightbulbs and by the security system.  The security system must
know which sensor provided the command and therefore no encryption is going
be needed here?  That just seems wrong.

 

Additionally, the situation where things are "continuously" talking would
seem to be a good place where one would want to install a controller and not
have the sensor directly talking to the actuator.  You don't want to flood
the actuators with trying to constantly turn on the lights.  Also the use of
actuators in this sense makes one think that this is a solution for things
other than lighting systems which is what people are complaining about.

 


The solution in section 4 does not seem to meet the following requirement
"Only authorized members of the application group must be able to read and
process messages."
[AS] You are right, we cannot satisfy the privacy requirement in Section 4.
We could extend the current solution to include a group wide encryption key
to meet this requirement. However, this will add additional latency to the
asymmetric solution.



This document needs to have a solution for dealing with nonce space
allocation for the cases where more than one sender is going be able to use
the same key.  This is going to be part of the problems with replay
detection as well as security considerations.

[AS] Okay. Will add some text in the next version of the draft for better
clarification. The idea as written in 4.3 (Nonce value) is to use the Client
ID along with the sender's sequence number to create the complete nonce for
replay and CCM processing.


Should the algorithms be using high water detection of sequence numbers
rather than the case of not yet used?  Or is that an application specific
type thing?

[SK] This is tricky since it can create all kind of new issues. One way to
handle if the sequence number of a sender is about to roll over is that the
sender requests a new key issued for the group by the KDC. Tricky part is if
there are multiple senders who are not reaching the roll over of their
sequence number then have to be forced to use a new key or there needs to be
some overlap between the old key and new key before every sender in the
group starts using the new key.

[JLS] Lots of spinning in graves from the idea of having a sequence number
roll over given the harsh requirements that a nonce (built from the sequence
number) must never be re-used twice for many of the algorithms that are
going to be used here.

 

I do not think that the current security requirements is sufficiently
strident to reflect both the threat of breakage, cross-breakage and
restrictions on where it should be used to pass muster.

[AS] I thing this will be the main discussion item in the webex. We will
make a proposal for the security guidelines section after the interi

[Ace] Review of draft-selander-ace-cose-ecdhe-02

[Jim Schaad]

This may be a bit scatterbrained as I did this review in several sessions
and the thoughts might not be consistent.

1.  In section #1, I would put in the fact that the derived key would only
be used for a period of time, after which a new ECDH key exchange would be
run again.

2.  It is not clear, but based on how the value of kid_ev is defined, it
might be reasonable to state that there is an expectation that generally U
will be a client and V a server.

3.  I would like to see the PSK half of the world setup so that it is not
required that the same key/kid pair be used in both directions.  Using a
different key in each direction makes things cleaner for some issues.  Both
cases of the same and different pairs should be permitted.

4.  I see no reason to say that what one is negotiating is a hash function.
What you are negotiating is a "Key Agreement w/ KDF" algorithm.  I don't see
that you are using the hash function by itself anywhere.

5.  In section 2, you should give a reason for including or not including
the nonces in the protocol.  Since they are optional when would they be
useful?

6. In section 2, do you expect that TCA is restricted to CEK or would MAC
algorithms be usable as well?

7.  In section 2, I missed where the replay parameter was included in the
COSE_Header - it seems to be in the key for party U and non-existant for
party V.  The closest that one comes it the use of the message_1 signature
as AAD.

8.  In figure 3, I would prefer to see two different traffic keys being
derived.  It is not an issue in Figure 2 as that just says keying material.
Using different keying material in each direction prevents reflection
attacks.

9.  In section 2.1, you talk about authentication methods but do not discuss
authorization methods.  Does this need to be built into message_1 or are
there other methods that will be functional here.  May need to refer to how
some of them might work since this will also potentially affect how the
distribution of the keys in advance works.  For example, if an OAUTH token
is published to a well-known location that contains both authorization and
authentication information.

10.  In section 3.1, I am not sure that you really want to have only a
single algorithm in this specification.  I would make it more generation in
terms of how a COSE_Key is built and then have a statement elsewhere rather
than spread throughout the document about what algorithms are mandatory to
support.

11.  In section 3.4.2 - I think that you need to have a more comprehensive
external_AAD structure that what is here.  I am not sure that you should not
AAD information from the CoAP header as well in all of the messages.

12. Stupid question - Can you do a PSK in one direction and a signature in
the other?

13. Not sure that it matters, but you have the COSE_KDF_Context structure
wrong everywhere.  The partyU and partyV fields are not optional.

14.  Section 3.5, I don't believe in uniquely identified kids on any device
unless that device is going to enforce that as a true statement.  That means
that it will not allow for a key to be registered with it unless the kid is
unique.There is nothing wrong with doing an exhaustive search of all of
the keys with the same kid as long as the number of them is not too large.

15.  Section 3.5.3:  If you are sending along a certificate, it is not clear
to me that you need to have a kid as well.  The certificate is where you are
going to get the key from not the kid.

16. Section 4.1 - kid_eu - Does this really need to be a counter on a per
party V basis or can it just be a counter based on the use of the credential
that is being used to do the authentication? 

17.  Section 5 - what happens if N_U or N_V is longer than the size of the
hash function.  Also, what do you mean by the size of the hash function?  Is
this the barrel size or the output size?

18.  Identity of the Parties:  There is a question on what the identity
structure that is being used to grant access is for ACE.  For those who have
been in the IETF long enough, one answer would be to move back to the world
of SPKI (Simple Public Key Infrastructure) where the key is the entity that
is used for identifying an entity and not some other piece of information
like a text string or an address.  Doing a security analysis, one might find
that one wishes to do a binding of the identity information into the key
derivation process.  If keys are the marker of identity, then this is would
be including the keys as part of the context information thus tying the
signature and key into the resulting key.  The requirement to include
identity information is probably needed more if access control is being
based on a name rather than a key however.  In this case it is likely more
important that the binding processes is included in the KDF context in some
manner.

19.  Use of the signature/MAC for chaining of items:  I did a fast review of
how the fields of message_1 and message_2 are used in the final KDF