Re: [Ace] bringing draft-selander-ace-ake-authz to ACE?

[Jim Schaad]

-Original Message-
From: Ace  On Behalf Of Michael Richardson
Sent: Wednesday, September 9, 2020 8:32 AM
To: ace@ietf.org
Subject: Re: [Ace] bringing draft-selander-ace-ake-authz to ACE?


Göran Selander wrote:
> We have been working on lightweight procedures for an IoT device to
> join a network. The join process may include a number of components
> such as authentication, remote attestation, authorization, enrolment of
> locally significant certificate, etc. Much of current standards are
> based on doing things in sequence, one thing at a time. This may be a
> good idea but it introduces some redundancies. One way to reduce
> overhead is to reuse elements from the authentication protocol in the
> authorization or certificate enrolment processes. So, instead of
> passing public keys and signatures multiple times between the same
> endpoints over constrained links during different phases of the joining
> procedure, we try to make more use of the authentication protocol while
> ensuring that the security properties are as expected.

...

> The link: Generic Animation of BRSKI - Bootstrapping Remote Secure
> Key Infrastructure (ODP) (screencast) (enterprise/IoT screencast)
> points to: https://www.youtube.com/watch?v=Mtbh_GN0Ce4 which is only 5
> minutes long.

> I should redo this for ACE-AKE-AUTHZ, aka Ultra-Constrained
> enrollment.

Thinking a day later, I think that presenting a well animated view of 
ACE-AKE-AUTHZ at an ACE virtual interim and listening to feedback about what 
fits into ACE and what does not, would help out small design team clarify/debug 
our message, should we go to secdispatch, or whatever.
[Jim: does that answer your question better?] I mean, we could also just hold 
our own virtual meeting too :-)

[JLS] Yes this does a much better job of telling me what you are trying 
accomplishment.  Having an idea of what the document is trying to do and what 
the problem that you are trying to solve makes it easier to slot in time for 
this.   I am more than willing to have ACE sponsor a different time slot if you 
want to have a known amount of time up front for the presentation.  I am 
willing to schedule it into the next meeting.  But you never know how much time 
is going to get consumed dealing with adopted documents.  

[JLS] I still need to do a deep read on this document.

Jim


I am personally more interested in writing code than wrangling documents from 
WG to WG in the next ~4 months.  I think that some other things in the IETF 
will sort themselves out in that timeframe, and a path forward will become 
clear.
In the meantime, explaining things to others helps me get it right.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide

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

Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy

[Jim Schaad]

-Original Message-
From: Ace  On Behalf Of Stefanie Gerdes
Sent: Wednesday, September 9, 2020 4:12 AM
To: ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, 
DoS, and privacy

Hi John,

On 09/09/2020 11:36 AM, John Mattsson wrote:



>>> As currently specified in draft-ietf-ace-oauth-authz-35, the RS will 
>>> happily send the AS address to any node that asks. This causes two 
>>> problems.
>>>
>>> - If C acts on the unauthorized information, this is an attack 
>>> vector for DoS attacks as an attacker on the C-RS path can make C 
>>> contact a chosen node on the Internet.
>>
>> The important part here is the "If". A proper client MUST NOT act on 
>> unauthorized information at any time. The workaround is the list of 
>> known AS'es in the draft. (In the current architecture, a client 
>> would not and cannot communicate with an unknown AS anyway as it has 
>> no way to establish a secure communication.)
> 
> I cannot find anything in the draft stating that “A proper client MUST NOT 
> act on unauthorized information at any time”. This also raises the question 
> why the unauthorized information is needed in the first place.

Hm, section 6.5 already states "the client MUST be able to determine whether an 
AS has the authority to issue access tokens for a certain RS." We can add "The 
client must not interact with an AS if it cannot determine that AS has the 
authority for this RS."

We also should change section 6.4 because the attack described there is not 
possible as C must not interact with an AS that is not authorized for this RS. 
I think that paragraph is a relic.

How about:

old:
Initially, no secure channel exists to protect the communication between C and 
RS.  Thus, C cannot determine if the AS Request Creation Hints contained in an 
unprotected response from RS to an unauthorized request (see Section 5.1.2) are 
authentic.  It is therefore advisable to provide C with a (possibly hard-coded) 
list of trustworthy authorization servers, possibly including information used 
to authenticate the AS, such as a public key or certificate fingerprint.  AS 
Request Creation Hints referring to a URI not listed there would be ignored.

A compromised RS may use the hints to trick a client into contacting an AS that 
is not supposed to be in charge of that RS.  Since this AS must be in the 
hard-coded list of trusted AS no violation of privileges and or exposure of 
credentials should happen, since a trusted AS is expected to refuse requestes 
for which it is not applicable and render a corresponding error response.  
However a compromised RS may use this to perform a denial of service against a 
specific AS, by redirecting a large number of client requests to that AS.

new:
Initially, no secure channel exists to protect the communication between C and 
RS.  Thus, C cannot determine if the AS Request Creation Hints contained in an 
unprotected response from RS to an unauthorized request (see Section 5.1.2) are 
authentic. C therefore must be able to determine if an AS is authorized to 
provide access tokens for a certain RS.

A compromised RS may use the hints for attempting to trick a client into 
contacting an AS that is not supposed to be in charge of that RS.
Therefore, C must not communicate with an AS if it cannot determine that this 
AS has the authority to issue access tokens for this RS. Otherwise, a 
compromised RS may use this to perform a denial of service against a specific 
AS, by redirecting a large number of client requests to that AS.

[JLS] I do not know how C is supposed to be able to determine if AS has the 
authority to issue access tokens for a specific RS.  If it had the ability to 
do that then it can go directly to the AS in question without ever needing to 
use this mechanism.  This mechanism is designed to be used for the case where C 
does not have a priori knowledge about which AS it will talk to get the token 
for RS.

> 
>>> - That RS shares the AS address with anybody that asks can be a 
>>> severe privacy problem. If RS is a medical device, the AS address 
>>> can reveal sensitive information. If RS is a blood pressure sensor 
>>> it could e.g. be “AS address = 
>>> coaps://as.hopkinsmedicine.org/kimmel_cancer_center/”

[JLS] My first hope is that this RS would never return an AS address to a 
client.   Sending information which has secure privacy problems amounts to a 
case where the rule should be:  If C does not know what AS to talk to, it has 
no business talking to me (RS).

[JLS] This is the type of situation where that information itself is going to 
be information to which access is to be restricted and where you need to talk 
to an AS to get permissions to get that information.  In this type of situation 
I would expect that the information would only be available either throw an 
already secure channel or from a DS with the, not yet defined, AS attributes.

Jim


>>
>> This is a valid concern. However, I would argue th

Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35

[Jim Schaad]

In any event, if the AS is not one that the client believes that it has some
type of security context to, then it does not seem to be a huge issue.   If
C does not trust AS, then it should not be talking to it however it makes
that decision. We currently do not support the four corner model in the ACE
protocol, although I think that is a candidate for an extension draft in the
future.

-Original Message-
From: Ace  On Behalf Of Stefanie Gerdes
Sent: Tuesday, September 8, 2020 2:33 AM
To: ace@ietf.org
Subject: Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35

Hi John,

the hard-coded list of authorized AS' is only one possibility for
authorization on the client side. I think we agreed that it is not a very
good one. The client may also dynamically obtain if a certain AS is
authorized. In this case, it is useful for the client to know for which AS
it must search.

The unauthorized resource request mechanism also allows the server to
provide a nonce (the cnonce) to the client, that must afterwards be present
in the access token. A constrained server without wall clock time and time
synchronization mechanism can use it to determine if the access token is
fresh.

Viele Grüße
Steffi

On 09/08/2020 10:37 AM, John Mattsson wrote:
> Hi Stephanie,
> 
> Regarding the section that you quoted: "the client MUST be able to
determine whether an AS has the authority to issue access tokens for a
certain RS. This can for example be done through pre-configured lists, or
through an online lookup mechanism that in turn also must be secured."
> 
> Assuming C has access to a function M letting it determine whether an AS
has the authority to issue access tokens for a certain RS, this would
certainly partly mitigate DoS attacks. The attack would be a DoS attack on C
and M, but the attacker could not choose M.
> 
> The problem is that:
> - if C has access to such a function M that can provide a link between AS
and RS, the whole mechanism with sending the AS address in an error message
seems completely redundant.
> - If C does not have access to such a function M, the mechanism with
sending an address in a spoofable error message seems like a very dangerous
attack vector for DDoS attacks.
> 
> The only implementation of M that would make use of an error message would
be if the error message contained something like sign(AS, RS), but this is
something that is not discussed in the draft.
> 
> Cheers,
> John
> 
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
> 

-- 
Stefanie Gerdes Tel: +49 421 218 63906
TZI Universität Bremen  E-Mail: ger...@tzi.de
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany

___
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] Assignment of OSCORE Sender and Recipient IDS - was RE: Review of draft-ietf-ace-oscore-profile

[Jim Schaad]

Hey John, comments in line commented with JLS2

-Original Message-
From: John Mattsson  
Sent: Tuesday, September 8, 2020 12:34 AM
To: Jim Schaad ; ace@ietf.org
Subject: Re: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] 
Review of draft-ietf-ace-oscore-profile

Hi Jim,

I agree with most of what you say. Below are some additional comments on some 
of the bullets.

[JLS]  I'll start with what I said on the mailing list - this problem was 
discussed previously on the mailing list and in person and it was decided that 
it did not need to be fixed.

[JM] My understanding from Francesca and Göran is that neither migration path 
to e.g. EDHOC nor systems where the nodes change roles have been discussed 
before. Both have additional collision probems. How important the use cases are 
and how bad the collision problem would be can be discussed.

[JLS2] This may be a case of people not hearing things that they don't think 
are of immediate importance.  I spent a couple of years arguing about much of 
this.  I did not deal with the reversing situation because I am not sure that 
this really makes a great deal of sense for ACE in general.  The one exception 
would be things like revocation, but that is always going to be a single RS.

[JLS] 1) The use of the same token on multiple RS has security problems on its 
own that cannot be overlooked.  It is possible that we need to say that this 
just should not be done.  If you are using symmetric keys all around, then RS1 
an impersonate C to RS2 because it has all of the necessary keying material to 
post the token and setup a security context.  RS1 can go farther and 
potentially impersonate the AS to RS2 gaining additional privileges when it 
impersonates C if the AS is using symmetric keys to validate tokens to RS1 and 
RS2.  This indicates that generally one does not want to use the same token 
with multiple devices.

[JM] Yes, using symmetric keys for authentication in groups is in general a 
very bad idea. Forbidding use of the token to several servers would forbid the 
use of multiple resource servers for redundancy. Alternatively several RS 
accepting the same token could be allowed in certain circumstances.

[JLS2] I agree that this is true, and it is one of the things that I was 
arguing with Ludwig about it being a reasonable thing to do.  It is also 
something that one wants to have for things like anycast where you don't know 
which of the servers you are going to end up with.  This however does not 
change the security problems with it.

[JLS] 3) You seem to be ignoring the most practical solution to the problem, 
use the context identifier for name space separation.  If you have five 
different ASs, then simply assign a one byte context to each of them and you 
now have no problems with name collisions unless somebody is going to be 
knowingly difficult.  Similarly, you  assign each of the group key managers a 
one byte value which is used as the prefix to the contexts assigned by that key 
manager for all of the groups it manages.  I would have to look to see if one 
can specify a context for LAKE, but being able to do so would provide a 
separation for that space as well.

[JM] Yes, that is definitely a solution, but I don't think it matters if you 
use ID context or longer Sender IDs, it's the sum of the lengths that matter 
for the collision probability. I agree that you can definitely solve the 
collision problem by randomly assigning longer ID Context + Sender ID, 
potentially combined with a mechanism (as you mentioned during the interim) 
where the client rejects tokens that lead to collisions. This solves collision 
problems on with the cost of additional roundtrips and/or larger OSCORE message 
sizes. Both could be acceptable, but unfortunate as collision free and optimal 
(in terms of message size) are well-known and there seems to be no benefits of 
the AS dictating Sender and Recipient IDs. Both RFC 7252 and RFC 8613 is very 
careful to not waste a single byte.

[JLS2] Please re-read what I outlined.  I was suggesting the use of very short 
ID contexts which are assigned in a non-random method.  This means that the 
collision probability can be highly controlled and you are not using longer 
sender IDs that you would otherwise.  

[JLS2] One of the big advantages of the AS assigning client ids is that updated 
tokens will have the same client IDs so that you don't end up with having to 
change these because you do not recognize that it should be the same security 
conversation.  There are also advantages because neither party needs to make 
decisions about how long an ID should be good for.  The server can make those 
decisions for you.  

/John

-----Original Message-
From: Jim Schaad 
Date: Monday, 7 September 2020 at 22:14
To: John Mattsson , "ace@ietf.org" 
Subject: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] Review 
of draft-ietf-ace-oscore-profile

Re: [Ace] Review of draft-ietf-ace-oscore-profile

[Jim Schaad]

John,

I am wondering if this is really the document that should be dealing with this 
collision problem.   A number of the collisions that might occur are going to 
be out of the ACE scope and a more general discussion of the problem should 
probably occur in a BIS version of the CoRE OSCORE document itself.   Memory 
says that the document does not claim to deal with how names are assigned to 
contexts, but I think that having a centralized location that LAKE, ACE (AS, 
Groupcomm and pub-sub) and perhaps other methods that we don’t currently have 
in our radar.  Collisions are going to be a common problem across all of these 
different ways of getting OSCORE contexts established.

Jim


-Original Message-
From: Ace  On Behalf Of John Mattsson
Sent: Tuesday, September 8, 2020 12:40 AM
To: Göran Selander ; ace@ietf.org
Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile

Hi,

Just want to say that I don't have any strong opinions on how to proceed. I 
just wanted to point out the collision problems with the draft are more severe 
that the group have discussed. Ignoring collisions seems like a mistake, and to 
my understanding there seems to be no benefits of the AS dictating Sender and 
Recipient IDs.

I think Jim has a good point in that the solution with symmetric key 
authentication comes with a lot of limitations anyway.

/John 

-Original Message-
From: Göran Selander 
Date: Monday, 7 September 2020 at 17:05
To: John Mattsson , "ace@ietf.org" 
Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile

Hi,

Just want to acknowledge, as was discussed in the WG meeting today, that the 
major comment below is alternatively a possible -bis update. I think this is 
good functionality, and even though related problem statements have been 
discussed before, this solution has not. And although the change is small it 
comes at a late stage. But if it doesn't make it for this version then let's 
make it in an update soon. 

Göran


On 2020-09-05, 14:51, "Ace on behalf of John Mattsson"  wrote:

Hi,

I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile

https://protect2.fireeye.com/v1/url?k=cd0dd5df-93bc0ebf-cd0d9544-86e2237f51fb-51fc8fb4bf065a0f&q=1&e=5ecc1a37-faa1-4082-857b-150aa2dc3b9a&u=https%3A%2F%2Face-wg.github.io%2Face-oscore-profile%2Fdraft-ietf-ace-oscore-profile.html

In general this draft looks very good. I have one major comments, and 
several more minor comments.

Major comment
---

- Asignment of OSCORE Sender and Recipient IDs

I think the specified mechanism where the AS dictates the OSCORE connection 
parameters is unfortunate. It introduces several current and future 
limitations. The current assignment mechanisms only works without problems in 
close systems where the RS does not have any other non-AS OSCORE connections, 
where the CoAP client and CoAP server roles are fixed and cannot be switched, 
and where only draft-ietf-ace-oscore-profile is used. In systems where the 
OSCORE nodes can switch between CoAP client and CoAP server (a feature 
explicitly supported by OSCORE) the current mechanism is likely to lead to 
RecipientID collisions. Also in future systems where the AS also supports a 
more modern key management with PFS using e.g. a future 
draft-ace-edhoc-oscore-profile, the mechanism would not work together in an 
efficient way. My understanding is that the authors would like the solution to 
work with both role switching and EDHOC.

How to negotiate these type of connection identifiers (in this case OSCORE 
Sender and Recipient IDs) have been studied and specified several times in e.g. 
draft-selander-lake-edhoc, draft-ietf-tls-dtls-connection-id. A solution where 
each party choses its OSCORE recipient ID for the connection always work 
without collisions. Such a negotiation could quite easily be added to the 
roundtrip with the nonces N1 and N2. My feeling is that it would be worthwhile 
to do such a change. This would also require a new identifier for the 
OSCORE_Security_Context Object, either a new objectID or a hash of the object 
could be used. I think this would be a good change as the current "hack" of 
using the ACE client sender Id and and ID context to identify the object might 
lead to other future limitations.

The suggested changes would lead quite equal message sizes and storage 
requirements, they might even lead to some small improvements.

Minor comments
---

- "server authentication"

My understanding is that server authentication with this draft requires two 
additional things. That C trusts AS and that RS sends an OSCORE response back. 
The draft should point this out similarly to the way it points out that a 
OSCORE request is required for proof-of-possession. As C trust in AS, and RS 
sending an OSCORE response back are both optional, I would recommend to maybe 
remove "server authentication" from the abstract and intro.

  

[Ace] Assignment of OSCORE Sender and Recipient IDS - was RE: Review of draft-ietf-ace-oscore-profile

[Jim Schaad]

-Original Message-
From: Ace  On Behalf Of John Mattsson
Sent: Saturday, September 5, 2020 5:51 AM
To: ace@ietf.org
Subject: [Ace] Review of draft-ietf-ace-oscore-profile


Major comment
---

- Asignment of OSCORE Sender and Recipient IDs

I think the specified mechanism where the AS dictates the OSCORE connection 
parameters is unfortunate. It introduces several current and future 
limitations. The current assignment mechanisms only works without problems in 
close systems where the RS does not have any other non-AS OSCORE connections, 
where the CoAP client and CoAP server roles are fixed and cannot be switched, 
and where only draft-ietf-ace-oscore-profile is used. In systems where the 
OSCORE nodes can switch between CoAP client and CoAP server (a feature 
explicitly supported by OSCORE) the current mechanism is likely to lead to 
RecipientID collisions. Also in future systems where the AS also supports a 
more modern key management with PFS using e.g. a future 
draft-ace-edhoc-oscore-profile, the mechanism would not work together in an 
efficient way. My understanding is that the authors would like the solution to 
work with both role switching and EDHOC.

How to negotiate these type of connection identifiers (in this case OSCORE 
Sender and Recipient IDs) have been studied and specified several times in e.g. 
draft-selander-lake-edhoc, draft-ietf-tls-dtls-connection-id. A solution where 
each party choses its OSCORE recipient ID for the connection always work 
without collisions. Such a negotiation could quite easily be added to the 
roundtrip with the nonces N1 and N2. My feeling is that it would be worthwhile 
to do such a change. This would also require a new identifier for the 
OSCORE_Security_Context Object, either a new objectID or a hash of the object 
could be used. I think this would be a good change as the current "hack" of 
using the ACE client sender Id and and ID context to identify the object might 
lead to other future limitations.

The suggested changes would lead quite equal message sizes and storage 
requirements, they might even lead to some small improvements.

[JLS]  I'll start with what I said on the mailing list - this problem was 
discussed previously on the mailing list and in person and it was decided that 
it did not need to be fixed.

1) The use of the same token on multiple RS has security problems on its own 
that cannot be overlooked.  It is possible that we need to say that this just 
should not be done.  If you are using symmetric keys all around, then RS1 an 
impersonate C to RS2 because it has all of the necessary keying material to 
post the token and setup a security context.  RS1 can go farther and 
potentially impersonate the AS to RS2 gaining additional privileges when it 
impersonates C if the AS is using symmetric keys to validate tokens to RS1 and 
RS2.  This indicates that generally one does not want to use the same token 
with multiple devices.

2) I mentioned that one could use trial decryption to distinguish between 
multiple RS senders.  This is normally only going to require one trial due to 
the fact that one can use the source IP address for sorting the different 
security contexts for trial.  As long as you do not have address collisions or 
changing addresses this makes things much easier to distinguish them.

3) You seem to be ignoring the most practical solution to the problem, use the 
context identifier for name space separation.  If you have five different ASs, 
then simply assign a one byte context to each of them and you now have no 
problems with name collisions unless somebody is going to be knowingly 
difficult.  Similarly, you  assign each of the group key managers a one byte 
value which is used as the prefix to the contexts assigned by that key manager 
for all of the groups it manages.  I would have to look to see if one can 
specify a context for LAKE, but being able to do so would provide a separation 
for that space as well.

4) I am not clear why Francesca thinks that doing the bis would make this a 
difficult thing to add.  You add two new items and then you get following  
cases:
a) The client does not use the new item:  The ids in the token are 
going to be used
b) The client sends the item:  
The server errors back because it does not support it and is 
strict - client goes to a)
The server does not return a new item because it does not 
support it and is lax, the ids in the token are going to be used
The server does return it's new item, the ids in the messages 
are going to be used.

5) I don't understand the case you are trying to make about reversing roles.  
First see point 1 above as the RS is not going to know who it is talking to, it 
could be C or it could be RS2 acting as an on-path attacker.  

[/JLS]

Cheers,
John

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

[Ace] Agenda for next monday

[Jim Schaad]

The chairs need to start building the agenda for next Monday.  If you want
to be on it then you need to let us know.  We are more interested in seeing
items which need to have decisions made than summaries of what has been
done.

Topic
Presenter
Expected Time

Jim


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

Re: [Ace] OSCORE Profile IANA questions

[Jim Schaad]

-Original Message-
From: Francesca Palombini  
Sent: Monday, August 31, 2020 5:53 AM
To: Ace Wg 
Cc: ace-cha...@ietf.org
Subject: OSCORE Profile IANA questions

Hi all,

I have two quick questions concerning IANA actions to be done for the OSCORE 
profile:

1) The framework (-params) and the profile are currently conflicting on the 
registration of parameters, and we need to fix that.
In the framework, parameters that are sent from Client to AS (such as req_cnf) 
are registered in the OAuth Parameters Registry as having "Parameter Usage 
Location: token request". The OSCORE profile registers parameters sent from 
Client to RS (such as nonce1) with "Parameter Usage Location: token request". 
The possible "Parameter Usage Location" are "token request" "token response" 
"authorization request" "authorization response" (see 
https://tools.ietf.org/html/rfc6749#section-11.2.1 ). It seems that 
"authorization request/response" are to the Resource Owner, and "token 
request/response" are to the Authorization Server. I think the framework is 
using the right names, but I am not sure what other location to put there, I 
think there is no name for Client-to-RS and RS-to-Client in the registry right 
now.

[JLS] Look at the OAuth registries - they have some "standardized" names for 
these interactions as well as the RS-AS pair.
Jim


2) The OSCORE profile defines a new registry, the OSCORE Security Context 
Parameters registry. The question is where to put this registry? My proposal is 
to put it under 
https://www.iana.org/assignments/core-parameters/core-parameters.xhtml . Any 
objections?

Thanks,
Francesca


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

Re: [Ace] [COSE] Gap in registration of application/cwt?

[Jim Schaad]

 

 

From: Laurence Lundblade  
Sent: Thursday, August 27, 2020 1:06 PM
To: Jim Schaad 
Cc: Ace Wg ; cose 
Subject: Re: [Ace] [COSE] Gap in registration of application/cwt?

 

In a CBOR thread it became clear (to me anyway) that in the context of CBOR a 
“tag" is not a prefix, badge, identifier or such. It is the combination of the 
identifier and the content. In the CBOR context when you say “tag 1” or 
“epoch-based date tag” you mean the major type 6 and the number content.  The 
encoded CBOR for a tag 1 with value for Jan 1, 1970 would be 0xc1 0x00.

 

RFC 8392 uses the terminology incorrectly in section 5 
<https://tools.ietf.org/html/rfc8392#section-5> . It refers to the tag as a 
prefix. Maybe errata should be filed on this?

 

[JLS] I would be fine with you filing an errata to this effect.  It would get 
marked, probably, as editorial not technical but that should be fine.

 

Jim

 

 

 

Going back to the identification of a CWT and/or COSE, my understanding is that 
a “CWT” is a protocol message. A “CWT Tag” is a type 6 item value 61 and the 
CWT protocol message.  The definition of the CWT protocol message stands apart 
from the definition of tag 61. (This is not true of a tag 1 epoch date; the 
definition of the date is intwined with the definition of tag 1).

 

I believe the definition of the CWT protocol message allows the type of COSE 
used to secure it to be identified in many ways. You can do it with CBOR tags 
or you can do with externally such as my Application/CWT; cose-type=COSE_Sign1 
content type example.

 

Further, I think nesting of COSE works as follows. It doesn’t have to be 
identified with COSE tags. Several levels of COSE can be required by some top 
level media type or even by some CBOR tag that is not a COSE defined tag. For 
example, I could define application/very-secure-string as follows.

  - Start with string of bytes

  - Encrypt it with COSE_Encrypt (the string of bytes is the payload) (note 
that this is not COSE_Encrypt_Tagged)

  - Sign it COSE_Sign1 (the COSE_Encrypt is the payload) (note that this is not 
COSE_Sign1_Tagged

  - Mac it with COSE_Mac0 (the COSE_Sign1 is the payload) (note that this is 
not COSE_Mac0_Tagged)

 

I could make the payload at some level in this example some newly defined tag 
that requires a COSE_Sign1 with EdDSA and indicates something about its payload 
format.

 

LL

 

 

 

 





On Aug 15, 2020, at 11:42 AM, Jim Schaad mailto:i...@augustcellars.com> > wrote:

 

 

 

From: Laurence Lundblade mailto:l...@island-resort.com> > 
Sent: Saturday, August 15, 2020 10:58 AM
To: Jim Schaad mailto:i...@augustcellars.com> >
Cc: cose mailto:c...@ietf.org> >; Ace Wg mailto:ace@ietf.org> >
Subject: Re: [Ace] [COSE] Gap in registration of application/cwt?

 

 






On Aug 14, 2020, at 3:35 PM, Jim Schaad mailto:i...@augustcellars.com> > wrote:

 

 

 

From: Laurence Lundblade mailto:l...@island-resort.com> > 
Sent: Friday, August 14, 2020 1:59 PM
To: Jim Schaad mailto:i...@augustcellars.com> >
Cc: Ace Wg mailto:ace@ietf.org> >; cose mailto:c...@ietf.org> >
Subject: Re: [COSE] Gap in registration of application/cwt?

 

Here’s a series of scenarios that I think are legal CWT. These are allowed by 
RFC 8392, right?

 

1) Explicitly tagged, no external type info needed

- Has CWT tag

- Has COSE type tag

[JLS] Yes

 

2) CWT identification by label, COSE type tagged

- The CWT is a CBOR data item with a label. The definition of the label says 
the contents of the label are always CWT

- No CWT tag necessary as it is implied by the label

- Has a COSE type tag

[JLS] Yes, the label could be internal to the CBOR object or external such as 
an media-type

 

I was being very specific with the term label, meaning a label/key identifying 
an item in a CBOR map.






 

3) CWT and COSE by label

- The CWT is an item with a label. The definition of the label says the 
contents of the label are always CWT and of a specific COSE type

- No tags necessary

[JLS] Yes that would be fine

 

4) Application/CWT identifies content as CWT, tagging for COSE type

- No CWT tag

- Has a COSE tag

[JLS] This is the same as 2?  I don’t think that it would be restricted to just 
that media type.

 

You mean there could be other media types that also identify the content as CWT?

[JLS] Yes this could be done in the future.   One would normally expect this to 
be an application specific profile, but funny things happen.

 

5) Application/CWT identifies content as CWT

- Has CWT tag even though it is redundant 

- Has a COSE tag

[JLS] Yes

 

Additionally, one might interpret CBORbis 4.2.2 to say the the CWT tag should 
not be present.

[JLS] For deterministic encoding, but not  for general encoding.

 

6) Application/CWT; cose-type=COSE_Sign1 (or Mac0 or …)

- No tags are used

- Identification is completely by the MIME type header

- (I understand that the cose-type MIME paramet

Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

[Jim Schaad]

 

 

From: Cigdem Sengul  
Sent: Monday, August 17, 2020 2:25 PM
To: Jim Schaad 
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

 

Hello Jim, 

 

I understand that it's an optimization to improve message delay. I wonder also 
if a client then can do CONNECT - PUBLISH - DISCONNECT before receiving a 
CONNACK as a best-effort publish? assuming CONNECT succeeds...

Should we just not cater to those cases?

 

What about stating in 2.2.6.1 - after "the Broker MUST

   send a CONNACK message to the Client." (or maybe somewhere higher up):

 

-> The client MUST NOT send any packets other than DISCONNECT or an AUTH in 
response to the broker AUTH's message until it has received a CONNACK.

-> The server MUST NOT process any packets other than DISCONNECT or an AUTH in 
response to its AUTH message before it has sent a CONNACK.

 

--Cigdem

 

 

[JLS] I think that not catering to these cases is just fine.  People who really 
expect them to work probably shouldn’t.

 

Jim

 

 

 

 

 

 

 

On Mon, Aug 17, 2020 at 7:16 PM Jim Schaad mailto:i...@augustcellars.com> > wrote:

 

 

From: Cigdem Sengul mailto:cigdem.sen...@gmail.com> > 
Sent: Monday, August 17, 2020 10:45 AM
To: Jim Schaad mailto:i...@augustcellars.com> >
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org 
<mailto:draft-ietf-ace-mqtt-tls-prof...@ietf.org> ; Ace Wg mailto:ace@ietf.org> >
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

 

 

 

I've got that from MQTT v5 spec:

If a Client sets an Authentication Method in the CONNECT, the Client MUST NOT 
send any packets other than AUTH or DISCONNECT packets until it has received a 
CONNACK packet [MQTT-3.1.2-30].

 and:

If the Server rejects the CONNECT, it MUST NOT process any data sent by the 
Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6]. 

 

[JLS] I read this as the following would not do the publish

CONNECT -->

PUBLISH -->

<-- AUTH

AUTH -->

<-- CONNACK fail

The PUBLISH can be received but is not processed unless the CONNACK is going to 
be a success.

[/JLS]

 

[CS] I think this sequence should not happen, as Client MUST NOT send PUBLISH 
before CONNACK.

I did not know what brokers do if they receive PUBLISH (and still processing a 
CONNECT) - drop or buffer until process. I quickly browsed mosquitto src. 

It looks like the broker sets a context flag to mark the session active after 
CONNECT is processed and accepted. 

If this flag is not set when processing publish,  it goes to an error state and 
doesn't look like it keeps the packet. 

 

[JLS] No, Clients are allowed to send further MQTT Control Packets immediately 
after sending a CONNECT packet; Clients need not wait for a CONNACK packet to 
arrive from the Server. – this is the preceding two sentences to requirement 
MQTT-3.1.4-6.  I would agree that this is going to be server specific.  The 
following paragraph suggests that clients SHOULD wait for the CONNACK but it is 
non-normative.  I think that I would write my client code to wait.  I would 
have to work really hard to figure out what my code base would do for this as I 
know it does queue packets for later processing but I am not sure what it would 
do for this case.

 

 

[CS] Ok, this is confusing.  I assumed that sentence regarding clients about 
not having to wait was when no Authentication Method set. 

Because there is: If a Client sets an Authentication Method in the CONNECT, the 
Client MUST NOT send any packets other than AUTH or DISCONNECT packets until it 
has received a CONNACK packet [MQTT-3.1.2-30].

 In the profile, we do set an authentication method in connect to "ace". 

 

[JLS] Looks like there might be some conflicting statements here.  I don’t know 
the best way to resolve it.

Jim

 

 

--Cigdem  

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

Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

[Jim Schaad]

 

 

From: Cigdem Sengul  
Sent: Monday, August 17, 2020 10:45 AM
To: Jim Schaad 
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

 

 

 

I've got that from MQTT v5 spec:

If a Client sets an Authentication Method in the CONNECT, the Client MUST NOT 
send any packets other than AUTH or DISCONNECT packets until it has received a 
CONNACK packet [MQTT-3.1.2-30].

 and:

If the Server rejects the CONNECT, it MUST NOT process any data sent by the 
Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6]. 

 

[JLS] I read this as the following would not do the publish

CONNECT -->

PUBLISH -->

<-- AUTH

AUTH -->

<-- CONNACK fail

The PUBLISH can be received but is not processed unless the CONNACK is going to 
be a success.

[/JLS]

 

[CS] I think this sequence should not happen, as Client MUST NOT send PUBLISH 
before CONNACK.

I did not know what brokers do if they receive PUBLISH (and still processing a 
CONNECT) - drop or buffer until process. I quickly browsed mosquitto src. 

It looks like the broker sets a context flag to mark the session active after 
CONNECT is processed and accepted. 

If this flag is not set when processing publish,  it goes to an error state and 
doesn't look like it keeps the packet. 

 

[JLS] No, Clients are allowed to send further MQTT Control Packets immediately 
after sending a CONNECT packet; Clients need not wait for a CONNACK packet to 
arrive from the Server. – this is the preceding two sentences to requirement 
MQTT-3.1.4-6.  I would agree that this is going to be server specific.  The 
following paragraph suggests that clients SHOULD wait for the CONNACK but it is 
non-normative.  I think that I would write my client code to wait.  I would 
have to work really hard to figure out what my code base would do for this as I 
know it does queue packets for later processing but I am not sure what it would 
do for this case.

 

 

[CS] Ok, this is confusing.  I assumed that sentence regarding clients about 
not having to wait was when no Authentication Method set. 

Because there is: If a Client sets an Authentication Method in the CONNECT, the 
Client MUST NOT send any packets other than AUTH or DISCONNECT packets until it 
has received a CONNACK packet [MQTT-3.1.2-30].

 In the profile, we do set an authentication method in connect to "ace". 

 

[JLS] Looks like there might be some conflicting statements here.  I don’t know 
the best way to resolve it.

Jim

 

 

--Cigdem  

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

Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

[Jim Schaad]

 

 

From: Cigdem Sengul  
Sent: Monday, August 17, 2020 8:50 AM
To: Jim Schaad 
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

 

Hello Jim, 

Responses inside.

 

 

 

On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad mailto:i...@augustcellars.com> > wrote:

Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous
session number/  - I think it should be stated that the session number is
provided, which is what the state is associated with.

 

To the best of my knowledge, and from what I read from the MQTT v5 spec:

The ClientID MUST be used by Clients and by Servers to identify state that they 
hold relating to this MQTT Session between the Client and the Server. 

I do not think the server uses anything other than the Client ID to look up the 
state.  

[JLS] I got the name wrong, the need for the identifier remains.

[CS] I see - I realise I did a shortcut to say MQTT broker keep session state. 

Actually, I think I should give examples of session state as I need to explain 
what could be problematic by identifying state only with client-id as discussed 
in the last IETF meeting. 

(i.e., 

The Session State in the Client consists of:

* QoS 1 and QoS 2 messages which have been sent to the Server, but have 
not been completely acknowledged.

* QoS 2 messages which have been received from the Server, but have not 
been completely acknowledged.

 

The Session State in the Server consists of:

* The existence of a Session, even if the rest of the Session State is 
empty.

* The Clients subscriptions, including any Subscription Identifiers.

* QoS 1 and QoS 2 messages which have been sent to the Client, but have 
not been completely acknowledged.

* QoS 1 and QoS 2 messages pending transmission to the Client and 
OPTIONALLY QoS 0 messages pending transmission to the Client.

* QoS 2 messages which have been received from the Client, but have not 
been completely acknowledged.The Will Message and the Will Delay Interval

* If the Session is currently not connected, the time at which the 
Session will end and Session State will be discarded.

)

 

 

Section 2.2.4 - Last sentence.  There is a difference between the connect
and re-auth flows in that the first and last messages are going to be AUTH
'25', AUTH '0' not CONNECT/CONNACK.  Everything else does stay the same. -
Might just want to say a similar flow and point forward.

Will clarify that this is only for CONNECT as it is under section 2- 
Authorizing Connection Requests. 

Will direct to section 4 for re-authentication.

 

Section 2.2.6.1 - I am not sure where you got this from: "Note that this is
different in MQTT v5.0, the Broker is allowed to process AUTH packets even
if the Broker rejects the CONNECT)."  I think that if the broker rejects the
connect it must CONNACK and disconnect.  

 

I've got that from MQTT v5 spec:

If a Client sets an Authentication Method in the CONNECT, the Client MUST NOT 
send any packets other than AUTH or DISCONNECT packets until it has received a 
CONNACK packet [MQTT-3.1.2-30].

 and:

If the Server rejects the CONNECT, it MUST NOT process any data sent by the 
Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6]. 

 

[JLS] I read this as the following would not do the publish

CONNECT -->

PUBLISH -->

<-- AUTH

AUTH -->

<-- CONNACK fail

The PUBLISH can be received but is not processed unless the CONNACK is going to 
be a success.

[/JLS]

 

[CS] I think this sequence should not happen, as Client MUST NOT send PUBLISH 
before CONNACK.

I did not know what brokers do if they receive PUBLISH (and still processing a 
CONNECT) - drop or buffer until process. I quickly browsed mosquitto src. 

It looks like the broker sets a context flag to mark the session active after 
CONNECT is processed and accepted. 

If this flag is not set when processing publish,  it goes to an error state and 
doesn't look like it keeps the packet. 

 

[JLS] No, Clients are allowed to send further MQTT Control Packets immediately 
after sending a CONNECT packet; Clients need not wait for a CONNACK packet to 
arrive from the Server. – this is the preceding two sentences to requirement 
MQTT-3.1.4-6.  I would agree that this is going to be server specific.  The 
following paragraph suggests that clients SHOULD wait for the CONNACK but it is 
non-normative.  I think that I would write my client code to wait.  I would 
have to work really hard to figure out what my code base would do for this as I 
know it does queue packets for later processing but I am not sure what it would 
do for this case.

 

 

So, the spec allows clients to send AUTH after CONNECT before CONNACK, and 
servers to process AUTH after CONNECT (before CONNACK I suppose). 

 

I agree the wording may  be confusing:

Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

[Jim Schaad]

 

 

From: Cigdem Sengul  
Sent: Sunday, August 16, 2020 12:14 PM
To: Jim Schaad 
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

 

Hello Jim, 

Responses inside. 

 

On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad mailto:i...@augustcellars.com> > wrote:

Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous
session number/  - I think it should be stated that the session number is
provided, which is what the state is associated with.

 

To the best of my knowledge, and from what I read from the MQTT v5 spec:

The ClientID MUST be used by Clients and by Servers to identify state that they 
hold relating to this MQTT Session between the Client and the Server. 

I do not think the server uses anything other than the Client ID to look up the 
state.  

[JLS] I got the name wrong, the need for the identifier remains.

 

Section 2.2.4 - Last sentence.  There is a difference between the connect
and re-auth flows in that the first and last messages are going to be AUTH
'25', AUTH '0' not CONNECT/CONNACK.  Everything else does stay the same. -
Might just want to say a similar flow and point forward.

Will clarify that this is only for CONNECT as it is under section 2- 
Authorizing Connection Requests. 

Will direct to section 4 for re-authentication.

 

Section 2.2.6.1 - I am not sure where you got this from: "Note that this is
different in MQTT v5.0, the Broker is allowed to process AUTH packets even
if the Broker rejects the CONNECT)."  I think that if the broker rejects the
connect it must CONNACK and disconnect.  

 

I've got that from MQTT v5 spec:

If a Client sets an Authentication Method in the CONNECT, the Client MUST NOT 
send any packets other than AUTH or DISCONNECT packets until it has received a 
CONNACK packet [MQTT-3.1.2-30].

 and:

If the Server rejects the CONNECT, it MUST NOT process any data sent by the 
Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6]. 

 

[JLS] I read this as the following would not do the publish

CONNECT -->

PUBLISH -->

<-- AUTH

AUTH -->

<-- CONNACK fail

The PUBLISH can be received but is not processed unless the CONNACK is going to 
be a success.

[/JLS]

 

So, the spec allows clients to send AUTH after CONNECT before CONNACK, and 
servers to process AUTH after CONNECT (before CONNACK I suppose). 

 

I agree the wording may  be confusing:

What I want to say is that: the servers in our profile do not process anything 
after CONNECT before CONNACK. 

So, the AUTH flow is strictly initiated by the server during the connection 
handshake.

After that, the client may do AUTH first, for re-authentication. 

[JLS] Given that a client may only send an AUTH in response to an AUTH, I don’t 
know how much this is needed.

 

[JLS]  I think if you just delete the aside (in parens) then it says what needs 
to be said and is not confusing.

 

 


Section 3.1 - Missed a case of "publish_+/topic3"

Yes, in previous version, example was for publish only for topic3.

I thought I should give a pub/sub, pub only, and sub only examples. 

Is that OK?

 

Yes, I was just pointing out that this was using the old syntax.  Nothing more.

 

Jim

 

 

Thanks,

--Cigdem 

 

 


Jim


___
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-mqtt-tls-profile-06

[Jim Schaad]

Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous
session number/  - I think it should be stated that the session number is
provided, which is what the state is associated with.

Section 2.2.4 - Last sentence.  There is a difference between the connect
and re-auth flows in that the first and last messages are going to be AUTH
'25', AUTH '0' not CONNECT/CONNACK.  Everything else does stay the same. -
Might just want to say a similar flow and point forward.

Section 2.2.6.1 - I am not sure where you got this from: "Note that this is
different in MQTT v5.0, the Broker is allowed to process AUTH packets even
if the Broker rejects the CONNECT)."  I think that if the broker rejects the
connect it must CONNACK and disconnect.  

Section 3.1 - Missed a case of "publish_+/topic3"

Jim


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

Re: [Ace] [COSE] Gap in registration of application/cwt?

[Jim Schaad]

 

 

From: Laurence Lundblade  
Sent: Saturday, August 15, 2020 10:58 AM
To: Jim Schaad 
Cc: cose ; Ace Wg 
Subject: Re: [Ace] [COSE] Gap in registration of application/cwt?

 

 





On Aug 14, 2020, at 3:35 PM, Jim Schaad mailto:i...@augustcellars.com> > wrote:

 

 

 

From: Laurence Lundblade mailto:l...@island-resort.com> > 
Sent: Friday, August 14, 2020 1:59 PM
To: Jim Schaad mailto:i...@augustcellars.com> >
Cc: Ace Wg mailto:ace@ietf.org> >; cose mailto:c...@ietf.org> >
Subject: Re: [COSE] Gap in registration of application/cwt?

 

Here’s a series of scenarios that I think are legal CWT. These are allowed by 
RFC 8392, right?

 

1) Explicitly tagged, no external type info needed

- Has CWT tag

- Has COSE type tag

[JLS] Yes

 

2) CWT identification by label, COSE type tagged

- The CWT is a CBOR data item with a label. The definition of the label says 
the contents of the label are always CWT

- No CWT tag necessary as it is implied by the label

- Has a COSE type tag

[JLS] Yes, the label could be internal to the CBOR object or external such as 
an media-type

 

I was being very specific with the term label, meaning a label/key identifying 
an item in a CBOR map.





 

3) CWT and COSE by label

- The CWT is an item with a label. The definition of the label says the 
contents of the label are always CWT and of a specific COSE type

- No tags necessary

[JLS] Yes that would be fine

 

4) Application/CWT identifies content as CWT, tagging for COSE type

- No CWT tag

- Has a COSE tag

[JLS] This is the same as 2?  I don’t think that it would be restricted to just 
that media type.

 

You mean there could be other media types that also identify the content as CWT?

[JLS] Yes this could be done in the future.   One would normally expect this to 
be an application specific profile, but funny things happen.

 

5) Application/CWT identifies content as CWT

- Has CWT tag even though it is redundant 

- Has a COSE tag

[JLS] Yes

 

Additionally, one might interpret CBORbis 4.2.2 to say the the CWT tag should 
not be present.

[JLS] For deterministic encoding, but not  for general encoding.

 

6) Application/CWT; cose-type=COSE_Sign1 (or Mac0 or …)

- No tags are used

- Identification is completely by the MIME type header

- (I understand that the cose-type MIME parameter is not defined, but it could 
be. 8392 doesn’t forbid it)

[JLS] Yes you could do that, and as I stated in a previous mail this is not a 
good idea for the CoAP world.

 

7) A protocol like FIDO identifies a protocol element that is an attention type 
the type of which is CWT with COSE_Sign1

- No tags are used

[JLS] yes

 

8) A protocol like FIDO identifies a protocol element that is an attention type 
the type of which is CWT; the COSE type is determined by tag

- No CWT tag

- Has a COSE tag

[JLS] yes

 

The one thing you can’t do is have a CWT tag without a COSE type tag. 8392 
section 6 forbids this.

 

[JLS] There however is a set of nested cases that you might need to look at.  
That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign ))  You would also need to 
think about the requirements for nested COSE layers.

 

All but the most outer COSE type are always identified by a tag, per 7.1 step 5 
and 7.2 step 6, right?

[JLS] Yes I guess that is true.  I think my code is more generous that this in 
terms of what is accepted.

Jim

 

 

LL

 





 

Jim

 

 

LL

 

 

 

 






On Aug 11, 2020, at 12:20 PM, Laurence Lundblade mailto:l...@island-resort.com> > wrote:

 

 






On Aug 10, 2020, at 5:49 PM, Jim Schaad mailto:i...@augustcellars.com> > wrote:

 

This is all based on my understanding that the surrounding protocol for must 
specify exactly when CBOR tags are to be used and when they are not to be used 
and that the surrounding protocol must not leave it as an optional 
implementation choice. In this case application/cwt is the supporting protocol.

 

[JLS] What is the text that says that this is true.  This would be a surprising 
statement for me.

 

Here’s three things that lead me to this.

 

CBORbis

The sentence of the first paragraph in 4.2.2 
<https://tools.ietf.org/html/draft-ietf-cbor-7049bis-14#section-4.2.2>  very 
clearly states this, though this is only for deterministic encoding.

 

Typical CDDL

Most CDDL that describes tagged data describes it only as tagged or untagged, 
not as optionally tagged.  COSE is one example of this. 

 

Email threads

This thread 
<https://mailarchive.ietf.org/arch/browse/cbor/?gbt=1&index=Hz7VjeBab9DxPas9E5_KfOmZwN0>
  and this thread 
<https://mailarchive.ietf.org/arch/browse/cbor/?gbt=1&index=y1EZ-IylFpJ3_MndQGADSbKhx0s>
 .

 

I summarized this behavior in this email 
<https://mailarchive.ietf.org/arch/msg/cbor/Hz7VjeBab9DxPas9E5_KfOmZwN0/>  and 
no where in the rest of the thread was it indicated differently.

 

So, it is not a hard requirement because 4.2.2 is only for determi

Re: [Ace] [COSE] Gap in registration of application/cwt?

[Jim Schaad]

 

 

From: Laurence Lundblade  
Sent: Friday, August 14, 2020 1:59 PM
To: Jim Schaad 
Cc: Ace Wg ; cose 
Subject: Re: [COSE] Gap in registration of application/cwt?

 

Here’s a series of scenarios that I think are legal CWT. These are allowed by 
RFC 8392, right?

 

1) Explicitly tagged, no external type info needed

- Has CWT tag

- Has COSE type tag

[JLS] Yes

 

2) CWT identification by label, COSE type tagged

- The CWT is a CBOR data item with a label. The definition of the label says 
the contents of the label are always CWT

- No CWT tag necessary as it is implied by the label

- Has a COSE type tag

[JLS] Yes, the label could be internal to the CBOR object or external such as 
an media-type

 

3) CWT and COSE by label

- The CWT is an item with a label. The definition of the label says the 
contents of the label are always CWT and of a specific COSE type

- No tags necessary

[JLS] Yes that would be fine

 

4) Application/CWT identifies content as CWT, tagging for COSE type

- No CWT tag

- Has a COSE tag

[JLS] This is the same as 2?  I don’t think that it would be restricted to just 
that media type.

 

5) Application/CWT identifies content as CWT

- Has CWT tag even though it is redundant 

- Has a COSE tag

[JLS] Yes

 

6) Application/CWT; cose-type=COSE_Sign1 (or Mac0 or …)

- No tags are used

- Identification is completely by the MIME type header

- (I understand that the cose-type MIME parameter is not defined, but it could 
be. 8392 doesn’t forbid it)

[JLS] Yes you could do that, and as I stated in a previous mail this is not a 
good idea for the CoAP world.

 

7) A protocol like FIDO identifies a protocol element that is an attention type 
the type of which is CWT with COSE_Sign1

- No tags are used

[JLS] yes

 

8) A protocol like FIDO identifies a protocol element that is an attention type 
the type of which is CWT; the COSE type is determined by tag

- No CWT tag

- Has a COSE tag

[JLS] yes

 

The one thing you can’t do is have a CWT tag without a COSE type tag. 8392 
section 6 forbids this.

 

[JLS] There however is a set of nested cases that you might need to look at.  
That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign ))  You would also need to 
think about the requirements for nested COSE layers.

 

Jim

 

 

LL

 

 

 

 





On Aug 11, 2020, at 12:20 PM, Laurence Lundblade mailto:l...@island-resort.com> > wrote:

 

 





On Aug 10, 2020, at 5:49 PM, Jim Schaad mailto:i...@augustcellars.com> > wrote:

 

This is all based on my understanding that the surrounding protocol for must 
specify exactly when CBOR tags are to be used and when they are not to be used 
and that the surrounding protocol must not leave it as an optional 
implementation choice. In this case application/cwt is the supporting protocol.

 

[JLS] What is the text that says that this is true.  This would be a surprising 
statement for me.

 

Here’s three things that lead me to this.

 

CBORbis

The sentence of the first paragraph in 4.2.2 
<https://tools.ietf.org/html/draft-ietf-cbor-7049bis-14#section-4.2.2>  very 
clearly states this, though this is only for deterministic encoding.

 

Typical CDDL

Most CDDL that describes tagged data describes it only as tagged or untagged, 
not as optionally tagged.  COSE is one example of this. 

 

Email threads

This thread 
<https://mailarchive.ietf.org/arch/browse/cbor/?gbt=1&index=Hz7VjeBab9DxPas9E5_KfOmZwN0>
  and this thread 
<https://mailarchive.ietf.org/arch/browse/cbor/?gbt=1&index=y1EZ-IylFpJ3_MndQGADSbKhx0s>
 .

 

I summarized this behavior in this email 
<https://mailarchive.ietf.org/arch/msg/cbor/Hz7VjeBab9DxPas9E5_KfOmZwN0/>  and 
no where in the rest of the thread was it indicated differently.

 

So, it is not a hard requirement because 4.2.2 is only for deterministic 
encoding, but seems like a “should" in spirit. It is the preferred way to 
design a CBOR protocol.

 

However you slice it, I think it is up to the surrounding protocol to say 
whether a tag is always required, never required or optionally required. If the 
protocol doesn’t say, then it defaults to optionally required.

 

Defaulting or explicitly allowing optional tagging means the receiver has to 
allow for all the tagging scenarios and makes possible the error case where the 
surrounding protocol says the data is of one type and the tag conflicts with 
it. (e.g. an application/cwt that contains a tagged CoSWID).

 

I don’t think optional tagging is of any advantage in a protocol design. It 
doesn’t enable anything.

 

It has some disadvantage because it introduces error conditions and potential 
confusion.

 

I think there are several scenarios with section 6 and application/cwt that 
could be more clear.

 

Can you use tag 61 or not? I think the current answer is that in 
application/cwt, tag 61 is optional.

 

How do you know what the COSE type is? It is somewhat obvious that COSE tags 
will work, but there i

Re: [Ace] [COSE] Gap in registration of application/cwt?

[Jim Schaad]

 

 

From: COSE  On Behalf Of Laurence Lundblade
Sent: Monday, August 10, 2020 1:25 PM
To: Ace Wg ; cose 
Subject: [COSE] Gap in registration of application/cwt?

 

It doesn’t seem clear what the CBOR tagging requirements are when 
application/cwt is used to indicate a message is a CWT.

 

This is the text that I think it missing:

 

The CBOR CWT tag (61) must NOT be used. It is unnecessary because the media 
type already indicates it is a CWT.

 

The COSE type indicating tag MUST be present. It is necessary to determine 
whether what the COSE type is, whether it is COSE_Sign1, COSE_Mac0...

 

Another solution could be a MIME parameter added to the application/cwt 
indicating the COSE type.

 

[JLS] Yes that would have been an alternative that would work – However this 
option would require either that you use text content types for CoAP or you 
allocate N different integer content types one for each possible set of options 
that could be placed there.  The current solution is cleaner and smaller.

 

Step 3 in section 7.2 also seems wrong. It doesn’t make it an error for the 
COSE type tag to be absent when the CBOR CWT tag is present.

 

 

This is all based on my understanding that the surrounding protocol for must 
specify exactly when CBOR tags are to be used and when they are not to be used 
and that the surrounding protocol must not leave it as an optional 
implementation choice. In this case application/cwt is the supporting protocol.

 

[JLS] What is the text that says that this is true.  This would be a surprising 
statement for me.

 

Jim

 

 

LL

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

Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault)

[Jim Schaad]

> -Original Message-
> From: Ace  On Behalf Of Panos Kampanakis
> (pkampana)
> Sent: Friday, July 24, 2020 7:05 AM
> To: Brockhaus, Hendrik ; Benjamin Kaduk
> ; Michael Richardson 
> Cc: Mohit Sahni ; steffen.fr...@siemens.com;
> ace@ietf.org
> Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel
Migault)
> 
> Hi Hendrik,
> 
> Thank you. Understood about the end-to-end protection of CMP and POP.
> 
> I would argue that establishing the end-to-end keys to offer the
application
> level protection functionality in a scalable way does not come easily. On
the
> other hand, even CMP allows for an RA trust model instead of end-to-end
POP
> like EST-coaps does.

[JLS] EST-coaps does allow for an RA trust model for POP as well.  The RA is
the terminator for the coaps connection.

Jim

> 
> > I am uncertain if I understand your question correctly. Est-over-coaps
> described EST transport and not CMP transport on top of CoAP.
> 
> I meant why do we need two enrollment protocols to run over COAP?
> est-over-coaps took a long time and a lot of work. The reason we pursued
it is
> because we were getting requests from vendors that wanted to enroll certs
in
> constrained environments in the energy sector and industrial automation
and
> EST was standardized in IEC 62351. Is the cmp-over-coap argument that you
> could run it over plan UDP and use out-of-band established, end-to-end
> protection the sole motivating reason?
> 
> Rgs,
> Panos
> 
> 
> -Original Message-
> From: Ace  On Behalf Of Brockhaus, Hendrik
> Sent: Wednesday, July 22, 2020 9:42 AM
> To: Panos Kampanakis (pkampana) ; Benjamin Kaduk
> ; Michael Richardson 
> Cc: Mohit Sahni ; steffen.fr...@siemens.com;
> ace@ietf.org
> Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel
> Migault)
> 
> Hi Panos,
> 
> thnaks for you feedback.
> 
> > Von: Panos Kampanakis (pkampana) 
> >
> > Hi,
> >
> > > Looking into Mohits draft, cmp-over-coap is much simpler than
> > est-over-coaps, as CMP does not need any binding to an underlying
> > (D)TLS handshake.
> >
> > Not sure that is accurate. And EST does not bind to the tunnel
> > protocol either unless proof of possession is used. For now the
> > cmp-over-coap draft says
> >
> >When the end to end secrecy is desired for CoAP transport, CoAP over
> >DTLS [RFC6347] as a transport medium SHOULD be used.
> >
> > COAP can run over DTLS or plain UDP and in rare cases TCP, TLS and
> > maybe Websockets. I am not sure someone would run cmp-over-coap over
> > TCP because then he could just run CMP natively without COAP in the
> > middle. Any application layer protocol (CMP etc) can run over any
> > transport but I am
> not
> > sure there are more transports than the usual ones for cmp-over-coap
> anyway.
> 
> It is not needed to run CMP over CoAP over TCP. UDP as transport protocol
is
> fine. Actually CMP over CoAP also does not need DTLS underneath. But it
also
> does not hinder to have a second line of defense.
> As I understand EST, proof-of-possession is purely provided by the
> self-signature in PKCS#10. But EST provides the proof-of-identity of the
> requesting party by the (D)TLS client authentication bound to the PKCS#10
> (tls-unique copied in the P10 password filed). Is this correct?
> Such binding is not required for CMP. CMP does not have any requirements
in
> this regard and provides prove-of-identity by signing the CMP messages.
The
> advantage is that this prove-of-identity can be end-to-end and not only on
> the first hop to the (D)TLS server, like with EST.
> 
> >
> >
> > I agree that if this gets picked up it should be by ACE.
> >
> > I would like to understand what gaps it is filling compared to
> > est-over-coaps which took a lot of work and where it will be used and
> > implemented in.
> 
> I am uncertain if I understand your question correctly. Est-over-coaps
> described EST transport and not CMP transport on top of CoAP.
> One prototypic implementation can be found on
> github.com/siemens/embeddedCMP.
> 
> - Hendrik

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

Re: [Ace] Review of ietf-ace-key-groupcomm-07

[Jim Schaad]

 

 

From: Francesca Palombini  
Sent: Thursday, July 23, 2020 4:59 AM
To: Jim Schaad ; draft-ietf-ace-key-groupc...@ietf.org
Cc: Ace@ietf.org
Subject: RE: Review of ietf-ace-key-groupcomm-07

 

Hi Jim, 

 

Thanks for your reply! Comments inline.

 

Francesca







On 16 July 2020 at 23:01:47 CEST, Jim Schaad mailto:i...@augustcellars.com> > wrote:



> -Original Message-
> From: Francesca Palombini  <mailto:francesca.palomb...@ericsson.com> >
> Sent: Tuesday, July 14, 2020 2:25 PM
> To: Jim Schaad mailto:i...@augustcellars.com> >; 
> draft-ietf-ace-key-
> groupc...@ietf.org <mailto:groupc...@ietf.org> 
> Cc: ace@ietf.org <mailto:ace@ietf.org> 
> Subject: Re: Review of ietf-ace-key-groupcomm-07
> 
> Hi Jim,
> 
> Thank you so much for another extensive review! We have submitted v-08 of
> the draft to answer it.
> Comments inline. If there is any answer/update that does not satisfy you,
> hopefully we can continue the discussion by mail and figure out the major
> points to discuss during IETF108.
> 
> Thanks,
> Francesca and Marco
> 
> On 26/06/2020, 06:02, "Jim Schaad"  <mailto:i...@augustcellars.com> > wrote:
> 
> 
> * Section 2 - update DTLS reference
> 
> FP: The Ace profile of DTLS is defined to set up DTLS 1.2, there is no profile
> defined to set up DTLS 1.3, so I don’t think we should update to 1.3 here.

[JLS] Fine - but be prepared for pushback from the IESG on this.

FP: A possible alternative is to rephrase to mention the profiles rather than 
the protocols. For example:

OLD:
“Possible ways to provide a secure communication association are DTLS [RFC6347] 
and OSCORE [RFC8613].”

NEW:
“Possible ways to provide a secure communication association are described in 
the DTLS transport profile [I-D.ietf-ace-dtls-authorize] and OSCORE transport 
profile [I-D.ietf-ace-oscore-profile] of ACE.”

Would that be better?

 

[JLS] Yes – just pointing to the profile with out specifying the details of 
which version of DTLS seems just fine.



> 
> * Section 3 - The content format application/ace+cbor is not defined by 
> the
> transport profiles but by the framework.
> 
> FP: The point is that the profiles might change the content format, so even if
> this specific one ace+cbor is defined in Ace, profiles might define and use 
> other
> ones. Rephrased to clarify.

[JLS] No, the profile can dictate the media type between C and RS, but between 
C and AS is set by the framework.

FP: Ah, I see what you mean. I checked again in the framework, and to be 
nitpicking it does says “Profiles that use CBOR encoding of protocol message 
parameters at the
outermost encoding layer MUST use the media format 'application/
ace+cbor'. So in some sense the content-format depends on if the profile uses 
CBOR or not. That does not change the fact that we need to rephrase our text 
here to be completely correct.

OLD:
The Content-Format
used in the message is the one indicated by the used transport
profile of ACE. For example, ...
NEW:
The Content-Format
used in the message depends on the used transport
profile of ACE. For example, ...



[JLS] Yes you are right that it depends on the encoding, I have 
application/ace+json defined and running in my AS for the MQTT code. 



> 
> * Section 3.1 - Given that a role is defined as a tstr, that format is not
> usable if one wishes to assign an integer abbreviation per OPT7.
> 
> FP: I tried to reformulate here that the aif is the default encoding, and 
> specify
> that the other format defined is an example. In the end it is up to the
> application profile to specify the format of scope.

Sure, but why not express figure 4 in terms of AIF rather than as something 
that looks like a new structure?

 

FP: We can do that, we will port the example from the OSCORE application 
profile (the one in section 3 of 
https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-08 ).


> 
> * Section 3.1 - Is there a reason that a gid is a bstr and not a tstr.  I
> assume that this is the same as GROUPNAME which much be a text string to
> be
> in a url-path.
> 
> FP: We have modified that to be tstr to be consistent with ace key groupcomm
> oscore, but please note this is only an example.

[JLS] Yes I know it is an example, but the gname cannot be anything other than 
a tstr unless you are going to completely break the connection between this 
value and the name in the URI.

 

FP: This is a good point, we might want to specify that if it’s not a tstr 
there needs to be something in place to make the translation between the group 
name and GROUPNAME used in the URI (ex: bstr gets translated into tstr 0x0123 
becomes “0123”)


> * Section 3.2 - the def of scope seems odd because it is not well defined 
> if
> 

Re: [Ace] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12

[Jim Schaad]

> -Original Message-
> From: Paul Kyzivat 
> Sent: Sunday, July 19, 2020 1:24 PM
> To: draft-ietf-ace-dtls-authorize@ietf.org
> Cc: General Area Review Team 
> Subject: Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ace-dtls-authorize-12
> Reviewer: Paul Kyzivat
> Review Date: 2020-07-19
> IETF LC End Date: 2020-07-20
> IESG Telechat date: ?
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the
review.
> 
> General:
> 
> TBD
> 
> Issues:
> 
> Major: 2
> Minor: 1
> Nits:  1
> 
> 1) MAJOR: Management of token storage in RS
> 
> There seems to be an expectation that when the client uploads an access
token
> that the RS will retain it until the client attempts to establish a DTLS
> association. This seems to require some sort of management of token
lifetime
> in the RS. The only discussion I can find of this issue is the following
in section 7:
> 
> ... A similar issue exists with the
> unprotected authorization information endpoint where the resource
> server needs to keep valid access tokens until their expiry.
> Adversaries can fill up the constrained resource server's internal
> storage for a very long time with interjected or otherwise retrieved
> valid access tokens.
> 
> This seems to imply a normative requirement to keep tokens until their
expiry.
> But I find no supporting normative requirements about this. And, this
section
> only presents it as a DoS attack, rather than a potential problem with
valid
> usage.
> 
> ISTM that there is an implied requirement that the RS have the capacity to
> store one access token for every PoP key of every authorized client.
> If so, that ought to be stated. If not, then some other way of bounding
storage
> ought to be discussed.

In section 5.8.1 of draft-ietf-ace-oauth-authz is the sentence "The RS MUST
be prepared to store at least one access token for future use."   When this
was put in, this is exactly what we were discussing.  There is no
requirement that an RS needs to store two access tokens for future use.  I
think this means that there is a strongly bounded requirement on storage.

Authors - It might be worthwhile to re-iterate this requirement in both of
the profile documents.

> 
> 2) MAJOR: Missing normative language
> 
> I found several places where the text seems to suggest required behavior
but
> fails to do so using normative language:
> 
> * In section 3.3:
> 
> ... Instead of
> providing the keying material in the access token, the authorization
> server includes the key identifier in the "kid" parameter, see
> Figure 7.  This key identifier enables the resource server to
> calculate the symmetric key used for the communication with the
> client using the key derivation key and a KDF to be defined by the
> application, for example HKDF-SHA-256.  The key identifier picked by
> the authorization server needs to be unique for each access token
> where a unique symmetric key is required.
> ...
> Use of a unique (per resource server) "kid" and the use of a key
> derivation IKM that is unique per authorization server/resource
> server pair as specified above will ensure that the derived key is
> not shared across multiple clients.
> 
> The uniqueness seems to be a requirement. Perhaps "needs to be unique"
> should be "MUST be unique". (And something similar for the IKM.)
> 
> * Also in section 3.3:
> 
> All CBOR data types are encoded in CBOR using preferred serialization
> and deterministic encoding as specified in Section 4 of
> [I-D.ietf-cbor-7049bis].  This implies in particular that the "type"
> and "L" components use the minimum length encoding.  The content of
> the "access_token" field is treated as opaque data for the purpose of
> key derivation.
> 
> IIUC the type of serialization and encoding is a requirement. Will need
some
> rewording to make it so.
> 
> * In section 3.3.1:
> 
> ... To
> be consistent with the recommendations in [RFC7252] a client is
> expected to offer at least the ciphersuite TLS_PSK_WITH_AES_128_CCM_8
> [RFC6655] to the resource server.
> 
> I think "is expected" should be "MUST".

The rule would be MUST implement not MUST offer.  A client could offer a
completely different ciphersuite that is consistently used in the group and
that would be fine.  

> 
> * Also in section 3.3.1:
> 
> ... This
> specification assumes that the access token is a PoP token as
> described in [I-D.ietf-ace-oauth-authz] unless specifically stated
> otherwise.
> 
> I think "assumes

Re: [Ace] Review of ietf-ace-key-groupcomm-07

[Jim Schaad]

> -Original Message-
> From: Francesca Palombini 
> Sent: Tuesday, July 14, 2020 2:25 PM
> To: Jim Schaad ; draft-ietf-ace-key-
> groupc...@ietf.org
> Cc: ace@ietf.org
> Subject: Re: Review of ietf-ace-key-groupcomm-07
> 
> Hi Jim,
> 
> Thank you so much for another extensive review! We have submitted v-08 of
> the draft to answer it.
> Comments inline. If there is any answer/update that does not satisfy you,
> hopefully we can continue the discussion by mail and figure out the major
> points to discuss during IETF108.
> 
> Thanks,
> Francesca and Marco
> 
> On 26/06/2020, 06:02, "Jim Schaad"  wrote:
> 
> 
> * Section 2 - update DTLS reference
> 
> FP: The Ace profile of DTLS is defined to set up DTLS 1.2, there is no profile
> defined to set up DTLS 1.3, so I don’t think we should update to 1.3 here.

[JLS] Fine - but be prepared for pushback from the IESG on this.

> 
> * Section 3 - The content format application/ace+cbor is not defined by 
> the
> transport profiles but by the framework.
> 
> FP: The point is that the profiles might change the content format, so even if
> this specific one ace+cbor is defined in Ace, profiles might define and use 
> other
> ones. Rephrased to clarify.

[JLS] No, the profile can dictate the media type between C and RS, but between 
C and AS is set by the framework.

> 
> * Section 3.1 - Given that a role is defined as a tstr, that format is not
> usable if one wishes to assign an integer abbreviation per OPT7.
> 
> FP: I tried to reformulate here that the aif is the default encoding, and 
> specify
> that the other format defined is an example. In the end it is up to the
> application profile to specify the format of scope.

Sure, but why not express figure 4 in terms of AIF rather than as something 
that looks like a new structure?

> 
> * Section 3.1 - Is there a reason that a gid is a bstr and not a tstr.  I
> assume that this is the same as GROUPNAME which much be a text string to
> be
> in a url-path.
> 
> FP: We have modified that to be tstr to be consistent with ace key groupcomm
> oscore, but please note this is only an example.

[JLS] Yes I know it is an example, but the gname cannot be anything other than 
a tstr unless you are going to completely break the connection between this 
value and the name in the URI.

> * Section 3.2 - the def of scope seems odd because it is not well defined 
> if
> it would be the same as the requested scope. (AS response)
> 
> FP:  I need more clarifications: Is it the following that is strange “'scope'
> containing the granted scope, if different from the scope requested by the
> client. “ ? Note that the terminology “requested and granted scope” comes
> from OAuth: https://tools.ietf.org/html/rfc6749#section-3.3. I removed the
> second part of the sentence as per comment below.

[JLS] What seems odd is that if it is absent, then it is not clear what the 
grants are.  I don't know if you need to specify that the grant is the same as 
the request when it is not present.  On the other hand this is duplicating 
information in the framework document.

> 
> * Section 3.3 - Am I supposed to know why I care about public keys at this
> point?
> 
> FP:  I thought this sentence was supposed to cover it (second paragraph of 
> 3.3):
> “Optionally, the Client might want to request necessary information concerning
> the public keys in the group, as well as concerning the algorithm and related
> parameters for computing signatures in the group.” What’s missing?

[JLS] Well - lets start with the use of the singular group in the text.  There 
are a number of problems here:  1.  It would make sense that this refer to the 
public key usage from group comm document.  2. The term "information concerning 
the public keys in the group" to me reads - get the public keys.  3.  There is 
no motivation about why you are getting this from the token post rather than 
from the group descriptor.

> * Section 3.3 - are you imposing a new requirement that the token be
> validated prior to returning the response to a token post?  As I remember
> it, this is not required to happen prior to the response being returned 
> just
> before access is granted.  (I.e. you can validate the token in parallel)
> (After successful verification...)
> 
> FP: It seems to us this is already defined in the framework: from
> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-35#section-5.8.1
> “When an RS receives an access token, it MUST verify it before storing it.”
> And later
> “If token or claim verification fails, the RS MUST discard the token and, if 
> this
> was an interaction with authz-info, return an erro

[Ace] Working Group Adoption Call for draft-bormann-core-ace-aif

[Jim Schaad]

I had been holding off doing an adoption call waiting for a formal request
to adopt it.  However, given that this is now a dependency for three
different WG documents I think we need to do this now.

Adoption call for
https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ 

This document provides a template for an authorization information format
(AIF) using a CDDL generic.  Questions to be answered:

1.  Do you think the ACE WG should adopt this document?  If not please
provide some reasoning.

2.  If adopted are you willing to review the document?

3.  Would you have any implementation plans?  Currently this is referenced
by the MQTT-TLS document, the Group KDC documents.

Adoption call ends on July 28.

Jim & Daniel


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

Re: [Ace] 4.01 Get A Token From There, discovery-/form-driven applications and tokens opaque to the client

[Jim Schaad]

> -Original Message-
> From: Ace  On Behalf Of Christian Amsüss
> Sent: Monday, July 13, 2020 8:12 AM
> To: ace@ietf.org
> Subject: [Ace] 4.01 Get A Token From There, discovery-/form-driven
> applications and tokens opaque to the client
> 
> Hello ACE,
> 
> piecing together parts of the big picture of Resource Directory, CoRAL
forms
> and ACE, I was wondering where in the whole story the client should tie
its
> intention to the key material it uses to authorize an action.
> 
> Take this -- admittedly contrived, but hopefully illustrative example:
> 
> * We have a device (C) inside example.com that coordinates a lot of
>   actions (and thus has a good standing with the AS and gets almost all
>   the tokens it asks for.
> 
> * The device would ike to register its management interface with the RD.
> 
> * A malicious attacker intercepts the discovery process, and tells C
>   that there is an RD at
>   `;rt=core.rd`
>   (which is a perfectly legitimate service we're running there for
>   commercial purposes; its interface is that you submit POST a link
>   there in link-format, and then it ties up the link target with endless
>   requests).
> 
> * The device tries to register to the local RD by POSTing some data
>   there, but as it has no token to the attack server, it receives a
> 
>   4.01 Unauthorized
>   Get your token from coap://as.example.com, scope launch-attack,
>   audience attack.example.com
> 
> * The client takes those pieces to the AS, which grants it a token
>   (after all, C would be authorized to launch an attack, given it's
>   known to be a coordinator -- it just doesn't mean to).
> 
> * C sends the token to the RS attack, and sends its POST again, with th
>   link to its own management interface.
> 
> * The attack server brings C to a grinding halt, because it was tricked
>   to shoot its own foot.
> 
> (Admittedly it's good practice for foot- and other guns to not just
silently ignore
> query parameters like ep=the-coordinator<=3600, but A) other interfaces
> may be more accidentally-compatible, and B) CoRAL forms would widen the
> range of craftable requests enormously).
> 
> My question here is: Where did this go wrong? Should C have verified with
> attack.example.com that it really has the resource type core.rd?
> Should it have understood the scope of the action? Should it have a
different
> security association with the AS for every action it asks tokens for? And
does the
> answer still hold if it has already obtained a token to launch attacks
(but just
> didn't notice that the RD it was sent to happens to have the very URI its
attack
> forces use)?

I would have expected that the C would have two different keys to talk to
the AS.  One for dealing with any attack servers and one for dealing with
things inside the company.  I would also expect that C would know which of
those keys are to be used for any given operation.  Thus if it is doing
registration it will ask for a token using the inside key and not the attack
key.  This would then be denied by the AS.  In terms of an existing token,
the token should be associated with which key was used to obtain it and thus
an existing attacker token would not be used for talking to the RD.

That being said, we need to come up with some better answers for getting
information from the RS to the client in some type of protected manner.
Either that or we need to decide that the client is suddenly going to have
to understand everything.  At one point I was thinking that talking to an RD
over multicast should be done using group keying but I am not sure that is
reasonable.  However it could be reasonable that every C would know the
audience for the RD it wants to talk to.  The problem with that is that if
there are two of them then you would end up with needing to know either the
pattern for RD audience strings or all of the possible audience strings.
You do have the benefit that if you get the answer back from a specific
address, then you are going to talk to that address.  Which works great for
unicast but does not solve any problems with multicast discovery.  

One possible answer is that there needs to be some pre-configuration for
directory services.  It may be that one or more audiences are needed to be
known to the end entity so that it can talk securely to an directory and
thus the first step would not be possible.

Jim


> 
> Kind regards
> Christian
> 
> --
> To use raw power is to make yourself infinitely vulnerable to greater
powers.
>   -- Bene Gesserit axiom

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

[Ace] Agenda for IETF 108

[Jim Schaad]

We are collecting agenda items for IETF 108.  We have a 100 minute slot at
the meeting and I am sure that it will be overflowing.  If you want to be on
the agenda please let the chairs know.

Please include the following data in your agenda request:

1. The document(s) that the presentation applies to
2. Who is giving the presentation
3.  How long do you expect the presentation to take.
4.  Are there any ordering issues that need to be noted.

Jim & Daniel


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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

> -Original Message-
> From: Olaf Bergmann 
> Sent: Wednesday, July 1, 2020 1:25 AM
> To: Jim Schaad 
> Cc: 'Benjamin Kaduk' ; 'Carsten Bormann' ;
> ace@ietf.org; draft-ietf-ace-dtls-authorize@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> 
> Hi Jim,
> 
> Jim Schaad  writes:
> 
> > If you are not doing a re-encoding of the token, then I believe that
> > preferred serialization and deterministic serialization are going to
> > generate the same answer.  With the map being used then this is not
> > true, and it is also true that the change in map ordering will hit
> > this.
> 
> There seems to be agreement on this, and therefore I will change the text
> following Carsten's proposal (use bytes for the access_tocken and state that
> preferred serialization and deterministic serialization should be used for the
> CBOR serialization.
> 
> > This is a piece of the document that I have never implemented because
> > I just don't believe that this option is a reasonable thing to require
> > being done so I missed the fact that the original encoded token is not
> > being used.
> 
> You haven't missed anything—the intention always was to use the original
> encoded token as transferred on the wire. The issue was introduced in this 
> last
> unpublished change that should have clarified the serialization of the data
> structure that is used as input for the HKDF.
> 
> > There is a possible DOS attack by a MITM changing the encoding on the
> > token since it is not protected when posted to the RS.
> 
> Yes, this is inherent to the upload mechanism and unrelated to key derivation.
> My intention is to access-protect the token endpoint in my implementation such
> that only authorized clients can upload an access token.
> 
> > If this is going to be changed, I would say use the binary string
> > encoding from the bstr of the inner most COSE wrapping layer as the
> > input to minimize this.
> 
> Now you have lost me. The innermost COSE wrapping layer would be the one in
> the contents of the cnf claim, given that we do not invent claims that also 
> can
> include COSE structures?

Yes this is the binary string that holds the claims.  It would be possible to 
have multiple COSE layers - i.e. encrypt and signing layers, and you would want 
to make sure that you agree on where you are pulling the content.

Using the token itself however is fine and you don't need to try and deal with 
this.

Jim

> 
> Grüße
> Olaf

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

> -Original Message-
> From: Benjamin Kaduk 
> Sent: Tuesday, June 30, 2020 9:25 AM
> To: Carsten Bormann 
> Cc: Olaf Bergmann ; draft-ietf-ace-dtls-
> authorize@ietf.org; ace@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> 
> On Tue, Jun 30, 2020 at 04:21:34PM +0200, Carsten Bormann wrote:
> > On 2020-06-30, at 12:19, Olaf Bergmann  wrote:
> > >
> > > NEW:
> > >
> > >   All CBOR data types are encoded in canonical CBOR as defined in
> > >   Section 3.9 of {{RFC7049}}. This implies in particular that the
> > >   `type` and `L` components use the minimum length encoding
> >
> > Note that 7049bis, which has been submitted to IESG already, all but
> deprecates this and replaces this with “deterministic encoding”.  There is 
> only
> one actual technical change, which is about map ordering.  Also, please check
> whether “preferred encoding” would actually be enough.
> >
> > I would generally prefer to avoid the need for deterministic/canonical
> encoding — is there really a need to re-encode the token?
> 
> My original comment was in the context of a novel data structure being used as
> HKDF input, which has 'type' and 'L' fields unrelated to any preexisting 
> token.
> Using the 'access_token' map as transmitted would be helpful, but is not
> sufficient.

If you are not doing a re-encoding of the token, then I believe that preferred 
serialization and deterministic serialization are going to generate the same 
answer.  With the map being used then this is not true, and it is also true 
that the change in map ordering will hit this.  This is a piece of the document 
that I have never implemented because I just don't believe that this option is 
a reasonable thing to require being done so I missed the fact that the original 
encoded token is not being used.  

There is a possible DOS attack by a MITM changing the encoding on the token 
since it is not protected when posted to the RS.  If this is going to be 
changed, I would say use the binary string encoding from the bstr of the inner 
most COSE wrapping layer as the input to minimize this.

Jim


> 
> -Ben

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

Re: [Ace] Extended REST model comment

[Jim Schaad]

> -Original Message-
> From: Carsten Bormann 
> Sent: Tuesday, June 30, 2020 8:35 AM
> To: Jim Schaad 
> Cc: draft-bormann-core-ace-...@ietf.org; ace@ietf.org
> Subject: Re: [Ace] Extended REST model comment
> 
> On 2020-06-30, at 16:43, Jim Schaad  wrote:
> >
> > In trying to formalize a policy for the RD testing, I ended up with
> > something that I think needs to be noted in this section.  There is a
> > difference between the following statements:
> >
> > Access is granted to resources created by the client.
> > Access is granted to resources that could have been created by the client.
> >
> > The first is what the text seems to cover.  This make sense in for the
> > coffeepot where only the person who created the order should be able
> > to cancel it.  (Well maybe an administrator might need to as well.)
> > However it does not cover the case where an installer created a number
> > of entries in the RD.  A QA person then comes through to make sure the
> > installation was done correctly.  When he finds a problem, the first
> > statement requires that the original installer come out to fix it
> > while the second statement allows the QA person to make the fix.
> 
> Hi Jim,
> 
> interesting.  I was thinking about #1 — I can make a coffee, I can cancel
> making it, you can make a coffee, but you can’t cancel my coffee.
> Or delete my RD entry, etc.  So making the resource confers ownership (really:
> a separate set of permission bits) that is bound to the subject.
> 
> In my view of how permission systems usually work, the other alternative
> requires creating a group.  The inherited permission would then be attached to
> the group.
> Since AIF is about capability lists, not about subject identities, I think we 
> are
> covered — just have the capability list on the group.

[JLS] I would agree that there is no need to make any changes in the AIF 
structure.  I would just like to see some text discussing that policy can 
enforce this in either way.

Jim

> 
> NFSv4 permissions probably also have a way to handle this kind of inheritance,
> but I’ll not have time to look that up today...
> 
> Grüße, Carsten


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

[Ace] Extended REST model comment

[Jim Schaad]

In trying to formalize a policy for the RD testing, I ended up with
something that I think needs to be noted in this section.  There is a
difference between the following statements:

Access is granted to resources created by the client.
Access is granted to resources that could have been created by the client.

The first is what the text seems to cover.  This make sense in for the
coffeepot where only the person who created the order should be able to
cancel it.  (Well maybe an administrator might need to as well.)  However it
does not cover the case where an installer created a number of entries in
the RD.  A QA person then comes through to make sure the installation was
done correctly.  When he finds a problem, the first statement requires that
the original installer come out to fix it while the second statement allows
the QA person to make the fix.

Jim


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

[Ace] Review of ietf-ace-key-groupcomm-07

[Jim Schaad]

* Section 1 para 1 - I have a vague memory of deciding that we were going to
become CBOR only with this document per the argument from Carsten.  I did
not find this in the minutes so this could easily be some other document
that I am thinking of.

* Section 2 - I have a problem with Figure 1 in terms of what is labeled as
an RS.  The text below calls the KDC and RS and not the Dispatcher.  

* Section 2 - update DTLS reference

* Section 2 - I think you might want the last sentence to refer to step 3
rather than section  - The pointer to the section has already been provided
but pointing back to the figure makes a degree of sense.

* Section 2 - KDC - This is the first time that I have heard about the fact
that this is a two part protocol - You should tell me about the phases
before you get here.

* Section 2 - "Leaving or removing" this is a sentence which does not read
well.  (Also why is this current when no other line is.)

* Section 2 - You should probably have a numbered item that corresponds to
the secure group communication line in the picture.

* Section 3 - The content format application/ace+cbor is not defined by the
transport profiles but by the framework.

* Section 3.1 - Given that a role is defined as a tstr, that format is not
usable if one wishes to assign an integer abbreviation per OPT7.

* Section 3.1 - the "Other additional" seems to be a strange thing to have
in this list because it does not match the lead in paragraph.

* Section 3.1 - Is there a reason that a gid is a bstr and not a tstr.  I
assume that this is the same as GROUPNAME which much be a text string to be
in a url-path.

* Section 3.2 - s/non expired/non-expired/

* Section 3.2 - the def of scope seems odd because it is not well defined if
it would be the same as the requested scope. (AS response)

* Section 3.2 - the text w/ scope can be simplified to the scope that the AS
grants access to and skip the last sentence.

* Section 3.2 - ditto w/ above on "other additional"

* Section 3.3 - s/request necessary information/request information/

* Section 3.3 - Am I supposed to know why I care about public keys at this
point?

* Section 3.3 - last sentence of the text implies that sign_info and
pub_key_enc are required.  Last sentence of para 2 needs to be re-written

* Section 3.3 - should identify what sign_info is for.

* Section 3.3 - are you imposing a new requirement that the token be
validated prior to returning the response to a token post?  As I remember
it, this is not required to happen prior to the response being returned just
before access is granted.  (I.e. you can validate the token in parallel)
(After successful verification...)

* Section 3.3 - "payload of response deviates"  I don't believe that this is
a true statement.  However, you should state at tis point how it deviates if
you believe it does.  I assume that you mean that there is a payload as
oppose to no payload.
  
* Section 3.3 - You would not be able to reuse the same kdcchallenge value
with a different key.  It would not have any way of being associated with
that key and would look like somebody else was attempting to use the value.

* Section 3.3 - s/were included in the request/are included in the request/
present tense.

* Section 3.3 - Do you really mean to say "request includes pub_key_enc",
"response does not include pub_key_enc"?  That seems to be wrong in the
general case.  Also seems to say the same thing about 'sign_info'.  Also
seems to contradict the next paragraph.

* Section 3.3 - The forward reference for sign_info is incorrect - it should
be 3.3.1.  (I also don't know if you need this two paragraphs in a row.)

* Same paragraph - group identifier or group name?  You need to do a
detailed pass through the document and look at every instance of this string
and either make it an identifier or a name and perhaps add these to the
terminology section so that one can quickly look back to distinguish them.
Perhaps you should be using context identifier rather than group identifier
just to make it clearer the difference between what goes into the different
locations.  The problem with that is it is OSCORE specific so it may not
work well.

* Section 3.3 - last paragraph - should this be referring to applications or
profiles?  -- really a global question.  Consider - is the OSCORE profile
attached to a specific application or to a set of unknown applications?

* Section 3.3.1 - s/one ore more/one or more/

* Section 3.3.1 - s/is lower or at most equal to/is at most/ - also what
happen if the response would include zero elements?  You asked and nothing
needs to be returned?

* Section 3.3.1 - second bullet - kill the "if included" text.  This is
covered above.

* Section 3.3.1 - s/sign_info/sign_info/

* Section 3.3.1 - This is looking really complicated and I don't know why
you don't just simplify it down to a single request/response pair.  Define a
value for use when the server either does not know or does not want to share
a value and so f

[Ace] Review of draft-bormann-core-ace-aif-08

[Jim Schaad]

This is a clean review so the last one most likely still applies.

*  From my review of the group comm document.  There needs to be an easy way
to talk about a single entry in the array of all permissions.  Some times
you only want to ask for one thing and not deal with permissions for any
other Toid.  Perhaps also define an AIF-Generic-One<>

* Section 3 - I think you might want to highlight that the first bullet
implies that once a Toid is found, then there is no need to continue
searching.   The array allows this because it is an ordered list.  Optional
to toss the authorization set if a duplicate Toid is found.  (And no, I
don't want to switch to a map.)

* Section 3 - the previous statement is correct for this data model.  Should
it be a requirement for all data models encoded with this?  (I think yes)

* Section 3 - I am happy that you are pushing the JSON encoding as a text
string!!!

* Section 2.1 - I think it would be better to use one of the URI naming
parts than using local-part as the identifier assigned here.   My problem is
that local-part is a term I associate with email addresses.  Perhaps
"path-query" with or without a leading uri would be a better name.

* Section 2.2 - Some of the implementations might be avoided by making a
single operation into a series of steps which can then be checked.  Thus
"opening an unlocked door" becomes two steps "unlock a door" and "open a
door" with different permissions set for each.

* Section ?? - We should probably say something about the use of "0" for
permissions in this model.  Is this legal and means nothing else?

Jim


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

Re: [Ace] AIF as discussed today (Re: I-D Action: draft-bormann-core-ace-aif-08.txt)

[Jim Schaad]

> -Original Message-
> From: Ace  On Behalf Of Francesca Palombini
> Sent: Tuesday, June 23, 2020 6:45 AM
> To: Carsten Bormann ; Ace Wg 
> Cc: Marco Tiloca 
> Subject: Re: [Ace] AIF as discussed today (Re: I-D Action: draft-bormann-core-
> ace-aif-08.txt)
> 
> Hi Carsten,
> 
> Thanks for this quick update! Just some short high level comments, to make
> sure we can use this for ace-key-groupcomm-oscore.
> 
> In ace-key-groupcomm-oscore, we would say that Toid is the identifier of the
> OSCORE group, so the OSCORE "group name", which is encoded as a bstr. For
> Tperm, it's a bit further away from what the aif document specifies (which is
> why I want to check with you), but we would go for array of tstr, since we 
> can't
> really encode the permission to be a "monitor" node (for example) by
> indicating a REST method. This is a bit stretched from the document right now,
> but it should work.
> 
> We would have to register a media type (and content format) for this, so what
> would this be? You use aif+cbor for the default, so maybe something like "aif-
> ace-group+cbor". For section 5.3, we would have to register Toid and Tperm
> with something like:
> 
> Toid registry:
> * name: gname
> * description: group name of the OSCORE group as specified in ace-key-
> groupcomm-oscore
> 
> Tperm registry:
> * name: roles
> * description: role of the group member as specified in ace-key-groupcomm-
> oscore
> 
> I think we are missing some form of "encoding" column in the registries above.
> In that case it would be "bstr" for Toid gname and "CBOR array of tstr" for
> Tperm role. It would also be "tstr" for local-part Toid and "int" for Tperm 
> REST-
> method-set. (also, minor, but you sometimes use "local-part" and sometimes
> "local-uri", see section 4). Even better, the description or the encoding in 
> the
> registry could point to "path" and "permissions" cddl, for the default values 
> in
> the aif doc.
> 
> Using "array of tstr" for roles allows us to express what we need for "set of
> roles". I don't see this being in contrast with the aif document right now.

This follows what I would expect, for MQTT I would see

AIF-MQTT = AIF_Generic
filter = tstr
permissions = [ +permission ]
permission = "publish" / "subscribe"

For the group comm draft, I think that

AIF-GROUP-COM = AIF_Generic
path = tstr  ; group name
permissions = uint . bits methods
methods = &(
requester = 1,
   responder = 2,
   monitor = 3,
   verifier = 4
)

This does require a registry if we ever expect this to grow.
 
> So all in all, I think this can work for ace-key-groupcomm-oscore. Please let 
> me
> know if you see anything that bothers you in my summary.
> 
> Thanks,
> Francesca
> 
> On 23/06/2020, 00:17, "Ace on behalf of Carsten Bormann"  boun...@ietf.org on behalf of c...@tzi.org> wrote:
> 
> I went ahead and quickly implemented what we had discussed today.
> 
> https://www.ietf.org/id/draft-bormann-core-ace-aif-08.html
> 
> Lots more editing to do, but the gist of what I was trying to say should 
> be
> there.
> Comments welcome!
> 
> Grüße, Carsten
> 
> 
> > On 2020-06-23, at 00:12, internet-dra...@ietf.org wrote:
> >
> >
> > 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 WG of the IETF.
> >
> >Title   : An Authorization Information Format (AIF) for 
> ACE
> >Author  : Carsten Bormann
> > Filename: draft-bormann-core-ace-aif-08.txt
> > Pages   : 9
> > Date: 2020-06-22
> >
> > Abstract:
> >   Constrained Devices as they are used in the "Internet of Things" need
> >   security.  One important element of this security is that devices in
> >   the Internet of Things need to be able to decide which operations
> >   requested of them should be considered authorized, need to ascertain
> >   that the authorization to request the operation does apply to the
> >   actual requester, and need to ascertain that other devices they place
> >   requests on are the ones they intended.
> >
> >   To transfer detailed authorization information from an authorization
> >   manager (such as an ACE-OAuth Authorization Server) to a device, a
> >   representation format is needed.  This document provides a suggestion
> >   for such a format, the Authorization Information Format (AIF).  AIF
> >   is defined both as a general structure that can be used for many
> >   different applications and as a specific refinement that describes
> >   REST resources and the permissions on them.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/
> >
> > There are also htmlized versions available at:
> > http

Re: [Ace] IANA considerations for authz-info RT

[Jim Schaad]

That corresponds to what I expected to see.

> -Original Message-
> From: Ace  On Behalf Of Carsten Bormann
> Sent: Monday, June 22, 2020 8:56 AM
> To: ace@ietf.org
> Subject: [Ace] IANA considerations for authz-info RT
> 
> Marco and I still have to do the bike shedding on the actual name (“ace.ai”
> below), but we can look at my proposed text already anyway:
> 
> 8. IANA Considerations
> 
> 8.NN. CoRE Resource Type registry
> 
>IANA is requested to register a new Resource Type (rt=) Link Target
>Attribute in the "Resource Type (rt=) Link Target Attribute Values"
>subregistry under the "Constrained RESTful Environments (CoRE)
>Parameters" {{?IANA.core-parameters}} registry:
> 
>rt="ace.ai".  This resource type describes an ACE-OAuth authz-info
>endpoint resource.
> 
>Specific ACE-OAuth profiles can use this common resource type for
>defining their profile-specific discovery processes.
> 
> Have I captured the discussion today?
> 
> 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

[Ace] Minutes Posted

[Jim Schaad]

I have posted the minutes for the meeting today.  If you want to make any
change let me know.

Jim


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

[Ace] AIF followup comment

[Jim Schaad]

Francesca, Cigdem,

One of the things that you might want to consider as part of you problem
with adapting to AIF is that the profile may want to re-define the bit
string so that instead of using the CoAP request codes, you use your set of
options allowing for a tighter encoding.

Jim


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

[Ace] FW: Review draft-ietf-ace-mqtt-tls-profile-05

[Jim Schaad]

Let's see if I can get the mailing list right this time

-Original Message-
From: Jim Schaad  
Sent: Monday, June 8, 2020 3:02 PM
To: 'draft-ietf-ace-mqtt-tls-prof...@ietf.org'

Cc: 'c...@ietf.org' 
Subject: Review draft-ietf-ace-mqtt-tls-profile-05

* Style Issue. "Abbreviations should be expanded in document title and upon
first use in the document.  Full expansion of the text should be followed by
the abbreviation in parentheses."  Some items such as TLS are considered to
be known by everybody and thus do not need to be expanded.
https://www.rfc-editor.org/materials/abbrev.expansion.txt contains both
"known" and "unknown" abbreviations.  (Yes this means you are going to have
a really long title.)  (I might argue that  OASIS should be listed as well
known.)

* Section 1 - para 1 - Sentence two has a plurality mismatch between client
and server.  I think in this case server (and broker) should be pluralized.

* Section 1.3 - Broker - s/publishes/publish/  The set of pluralized items
seems to be too large by one.

* Section 1.3 - I think we ought to define Session given that we no longer
require that Clean Session be used.

* Section 1.3 - I do not believe that CONNACK is always the first packet
from the broker to a client.  An AUTH message may be the first one.

* Section 2.1 - para 3 s/the public key used by the RS/the public key to be
used by the RS/

* Section 2.1 - I think (but am not sure) that we may need to do some
registrations around the use of thumbprints in a confirmation claim.  If I
forget, please remind me to track this down.

* Section 2.2.2 - para #1 - s/using client authentication/using server
authentication/  If we are doing MQTT as the default then the server not the
client is authenticated here.  You may not want to have lost the potentially
here.

* Section 2.2.3 - I think that the client state MUST include the token and
either the same token is supplied or a token with the same key is supplied
in order to match with an existing state.

* Section 6.2 - I think it makes sense to put in a note that between the
fact that the server will disconnect on almost any error and is not required
to keep session state between connections, clients need to make a greater
effort to ensure that tokens remain valid and they do not attempt to publish
to topics that they do not have permissions for.

* Section 8 - The storage of tokens long term can be restricted to only
current valid ones if an immediate validation of the token is done.  This
means that the RS spends time doing the validation, but does not need to
consume memory.

This is looking really good.  I think we have only two technical issues open
at this point.  The question of registrations for hash identifications in
confirmation claims and if changes to the default scope structure are to be
done.

Jim


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

[Ace] Review draft-tiloca-ace-oscore-gm-admin-01

[Jim Schaad]

* Does 'joining_path' contain the path or the full URI to the joining
resource.  Is it possible for the Group Manager Administration to be on a
different server (or via a different address) from the Group Manager itself?
Path tends to me to say only path.

* Section 2.3.2.1 - I think it makes more sense to make all of the defaults
to the groupcomm draft from ACE for OSCORE.  Since this is for managing
those types of groups, it should be that document which gets to set the
defaults.  If it wants to refer back to the same documents that is fine, but
it should be that the defaults can change based on changing that document.

* Section 2.3.2.2 - I think there may be a difference between an empty
string and an absent string for group_title.  Just verifying that what you
want is an empty string.

* Section 2.4.1 - I am not sure why this is a subsection of 2.4.

* Section 2.5.3 - What does "or is not fine to consider for tis OSCORE
group" in bullet #4 list #2?  Is this implying some type of judgement on the
part of the AS based on parameters in the group definition or the expected
usage of the group?

* Section 2.5.3 - I think it might make sense to return at least some of the
information in the return value of the POST such as the "joining_path" and
the "as_uri" because just the management path is not sufficient to be able
to start populating the RD.

* Section 2.5.3 - An interesting question - Should it be allowable for the
name to be different between the management and the group key nodes?  I
would like to see some type of discussion at least on the mailing list.
Doing the search on the join path would result in the same answer and little
additional penalty since I doubt that GM Admin clients are going to be
constrained.

* Section 2.5.5 -  The second paragraph makes zero sense to me.  The third
paragraph should just be talking about the update message and not mixing the
create and update messages together.

* Section 2.5.5.2 - I have read this section twice and I still do not think
I understand what is going on here.  How much of this is needed and how much
is extraneous?  Is there some simplification that can be used to make this
easier?

Jim

s/fowllowing/following/


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

Re: [Ace] "default value" for authz-info endpoint

[Jim Schaad]

We should make sure to keep draft-tiloca-core-oscore-directory in mind for 
this.  It has a relation link defined for the Authorization server.

Jim


-Original Message-
From: Ace  On Behalf Of Carsten Bormann
Sent: Monday, June 1, 2020 7:52 AM
To: Seitz Ludwig 
Cc: Benjamin Kaduk ; ace@ietf.org
Subject: Re: [Ace] "default value" for authz-info endpoint

On 2020-06-01, at 11:13, Seitz Ludwig  wrote:
> 
> Hi Ben,
> 
> I had a look at the well-known URI list at IANA and it seems that for vanilla 
> OAuth 2.0 endpoints (authorization, token, introspect) there are no 
> well-known URI:s either. What exists is an URI used by the authorization 
> server to self-describe (including attributes giving the values of the 
> endpoint's URIs).
> 
> So my interpretation would be that instead of defining a well-known URI for 
> authz-info, we need to define an attribute that a Resource Server can include 
> in its well-known information to identify the authz-info endpoint URI it is 
> exposing. 
> 
> @Carsten (or other core experts): Would it make sense to define a new 
> attribute in the /.well-known/core format for Resource Servers using coap?

It would probably not be an attribute but a link relation and/or a resource 
type.

I would expect the authz-info resource would usually be the same for an entire 
server?
This might argue for the “hosts” link relationship and an rt= registration.

Registry:
Resource Type (rt=) Link Target Attribute Values in Constrained RESTful 
Environments (CoRE) Parameters

If the authz-info is often different for each resource, a link from the 
resource to the authz-info with an appropriate link relation would work best.

Registry:
Link Relations

Grüße, Carsten


> 
> /Ludwig
> 
> 
> -Original Message-
> From: Ace  On Behalf Of Benjamin Kaduk
> Sent: den 31 maj 2020 00:36
> To: ace@ietf.org
> Subject: [Ace] "default value" for authz-info endpoint
> 
> Hi all,
> 
> I was prompted by the discussion at the interim to look more closely 
> at what we say about the "default name" for endpoint URIs, e.g., the 
> authz-info endpoint.  The last paragraph of
> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-5.8.
> 1
> says:
> 
>   The default name of this endpoint in an url-path is '/authz-info',
>   however implementations are not required to use this name and can
>   define their own instead.
> 
> I've gotten advice from some URI experts that this doesn't give an 
> easy/discoverable path (pun intended) to using a non-default value, which is 
> problematic from the perspective of BCP 190 (and we should expect to get 
> discussed at IESG evaluation time).  This sort of issue goes away if we 
> allocate a well-known URI for authz-info from 
> https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml and 
> have that be the default.  In particular, that wouldn't actually stop any 
> deployments from using /authz-info, but it does mean they'd have to knowingly 
> "opt in" to doing so.
> 
> What do people think?
> 
> Thanks,
> 
> Ben
> 
> ___
> 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 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] FW: Webex meeting invitation: ACE interim 07

[Jim Schaad]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Atlantic/Reykjavik
BEGIN:STANDARD
DTSTART:16010101T00
TZOFFSETFROM:+
TZOFFSETTO:+
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T00
TZOFFSETFROM:+
TZOFFSETTO:+
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Jim Schaad;SENT-BY="mailto:daniel.miga...@ericsson.com":mailto:a
 ce-cha...@ietf.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=ace@ietf.o
 rg:mailto:ace@ietf.org
ATTACH:CID:39118A2BE2F7CD4294B45129D13A735D@namprd15.prod.outlook.com
DESCRIPTION;LANGUAGE=en-US:\n\n-Original Appointment-\nFrom: Jim Sc
 haad \nSent: Wednesday\, May 27\, 2020 12:32 PM\nTo: 
 Jim Schaad\; Daniel Migault\nSubject: Webex meeting invitation: ACE interi
 m 07\nWhen: Monday\, June 22\, 2020 2:00 PM-3:30 PM Atlantic/Reykjavik.\nW
 here: https://ietf.webex.com/ietf/j.php?MTID=mf10e2f04280cf225c5d2374973df
 48b5\n\n\nJim Schaad invites you to join this Webex meeting.\n\n\n\nMeetin
 g number (access code): 161 348 3825\n\nMeeting password: d54fSbDXHb6\n\n\
 n\nMonday\, June 22\, 2020\n2:00 pm  |  (UTC+00:00) Monrovia\, Reykjavik  
 |  1 hr 30 mins\n\n\n\nJoin meeting<https://ietf.webex.com/ietf/j.php?MTID
 =mf10e2f04280cf225c5d2374973df48b5>\n\n\n\nJoin by phone\nTap to call in f
 rom a mobile device (attendees only)\n1-650-479-3208 Call-in toll number (US/Canada)\nGlobal call
 -in numbers<https://ietf.webex.com/ietf/globalcallin.php?MTID=m2912a2424d7
 c4c7e522c691e68a5aabd>\n\n\n\nJoin from a video system or application\nDia
 l 1613483...@ietf.webex.com<%20sip:1613483...@ietf.webex.com>\nYou can als
 o dial 173.243.2.68 and enter your meeting number.\n\n\n\nJoin using Micro
 soft Lync or Microsoft Skype for Business\nDial 1613483825.ietf@lync.webex
 .com<%20sip:1613483825.i...@lync.webex.com>\n\nNeed help? Go to http://hel
 p.webex.com\n\n\n
UID:a5b989a3-f3d4-44d5-9050-930e9585caef
SUMMARY;LANGUAGE=en-US:FW: Webex meeting invitation: ACE interim 07
DTSTART;TZID=Atlantic/Reykjavik:20200622T14
DTEND;TZID=Atlantic/Reykjavik:20200622T153000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20200527T163204Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:1590597124
LOCATION;LANGUAGE=en-US:https://ietf.webex.com/ietf/j.php?MTID=mf10e2f04280
 cf225c5d2374973df48b5
X-MICROSOFT-CDO-APPT-SEQUENCE:1590597124
X-MICROSOFT-CDO-OWNERAPPTID:0
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MICROSOFT-LOCATIONS:[{"DisplayName":"https://ietf.webex.com/ietf/j.php?MT
 ID=mf10e2f04280cf225c5d2374973df48b5"\,"LocationAnnotation":""\,"LocationU
 ri":""\,"LocationStreet":""\,"LocationCity":""\,"LocationState":""\,"Locat
 ionCountry":""\,"LocationPostalCode":""\,"LocationFullAddress":""}]
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT5M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR


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

[Ace] Review on draft-bormann-core-ace-aif-07

[Jim Schaad]

* Section 2 - I would like more clarification on the subject as being
derived implicitly from the armor and is a single entity rather than
multiple entities.   If we think that we want to do multiple subjects then
that needs to be discussed.

* Section 2.1 - The model does not current deal with the question of queries
and how they would be permitted for a non-query object.

*  How do we ant to look at doing the generalization for the structure
provided.  There are two things to look at:

1.  The object identifier:  It makes sense for a good many things for this
to be an absolute-path.  However for other things this would be some type of
identifier.  With both the GroupKDC and with MQTT this identifier is a
string.  In the MQTT case the string has defined wild card behavior.  Part
of the question is how much does the object naming scheme need to be
identified to the client, the AS and the RS.  

2.  The permissible actions:  For a coap addressed device, it makes sense
for this to be based on the set of coap verbs and the compressed bit string
makes a great deal of sense.  However for both GroupKDC and MQTT these verbs
are not the same and thus cannot be compressed in the same manner. 

What I would like to see is a structure defined that can be used in a number
of situations, but which the details are going to be very object dependent.


authorization-info = [ * authorization]

authorization = [
   object: object-identifier,
   permissions: [* permission-name] | uint .bits methods
]

permission-name = tstr

One option would be to allow the methods to be object dependent this means
that you could have  "methods = &( PUBLISH: 0, SUBSCRIBE: 1)" for the MQTT
case.  The advantage of this is that it provides better compressions, but it
also means that one needs to know what the enumeration is for each different
type of object.  I don't know if this means that one needs to start having a
registry to deal with people adding verbs to a particular interface.  I also
don't know what it would mean if they were interface specific and an object
supported two different interfaces.

Nits:
Section 2 - para 2 s/on object/an object/

Jim


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

Re: [Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT

[Jim Schaad]

That is not an issue.  If you ask for adoption, we can adopt any draft with any 
name.

-Original Message-
From: Ace  On Behalf Of Carsten Bormann
Sent: Monday, May 18, 2020 9:12 AM
To: Ace Wg 
Subject: Re: [Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT

On 2020-05-18, at 17:21, Carsten Bormann  wrote:
> 
> [1]: https://tools.ietf.org/html/draft-bormann-core-ace-aif

Benjamin reminds me that this has -core- as the crucial third word of the draft 
name.
I hope that doesn’t get in the way if we decide to pick this up as an 
(informational) ACE document (I could resubmit this under a different name, but 
that would be confusing).
Or we (ACE) could actually decide to throw this back over the fence to CoRE?

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

[Ace] Interim minutes

[Jim Schaad]

I have posted the minutes - review and comment as appropriate.

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

Re: [Ace] Update of access rights

[Jim Schaad]

As I said, I have not fully thought it out.  A better way to state this might 
be - this token uses the same key as rather than implying overriding.

-Original Message-
From: Olaf Bergmann  
Sent: Sunday, May 17, 2020 11:32 PM
To: Jim Schaad 
Cc: 'Francesca Palombini' ; 'Ace Wg' 

Subject: Re: [Ace] Update of access rights

Hi Jim,

Jim Schaad  writes:

> define a new claim which says - This token supersedes the token(s) 
> with CWTID values of "x", "y" and "z".

Isn't this the same as token revocation with all its implications?  I would 
prefer strict token ordering combined with a sound revocation mechanism. In 
both scenarios, you would still have the issue that the client forwards the 
superseding token/revocation message if it has a benefit from doing so.

Grüße
Olaf

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

Re: [Ace] Update of access rights

[Jim Schaad]

I have not had a chance to think this out and get all of the implications
right, but my understanding is that what we were trying to avoid was having
the same secret key/public key present on the RS in more than one token.
This simplifies what the RS needs to do.  However, I am now under the
impression that having the RS deal with multiple tokens with the same public
key might be less of an issue than trying to make some decisions on what
tokens are supposed to supersede other tokens.

One of the ways that this might be avoided is to push the problem to where
it, in some sense, belongs.  The AS should be able to make this type of
decision if a token is supposed to replace an existing token or not and it
has more knowledge about what tokens are associated with what keys.  If we
go back and say - the AS should include a CWTID in the token and then define
a new claim which says - This token supersedes the token(s) with CWTID
values of "x", "y" and "z".  

Jim



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

Re: [Ace] Fwd: Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-05-18

[Jim Schaad]

Agenda has been uploaded to the meeting.   Note that the list of upcoming 
meetings seems to have changed it’s set of links and for me is not giving a 
jabber room link nor a WebEx link.  Information on  both can be found in the 
agenda.

 

Jim

 

From: Ace  On Behalf Of Daniel Migault
Sent: Wednesday, May 13, 2020 8:17 PM
To: Ace Wg 
Subject: [Ace] Fwd: Authentication and Authorization for Constrained 
Environments (ace) WG Virtual Meeting: 2020-05-18

 

Hi, 

 

This is a reminder that we have an interim meeting Monday May 18. We are 
preparing the agenda, so please let the chairs know if you are willing to 
present. 

 

Please also upload you slides here by Sunday 23:59 anywhere in the world.

https://datatracker.ietf.org/meeting/interim-2020-ace-06/session/ace 

 

Information on the meeting:

https://datatracker.ietf.org/meeting/interim-2020-ace-06/session/ace  

 

Yours, 

Jim and Daniel  

-- Forwarded message -
From: IESG Secretary mailto:iesg-secret...@ietf.org> >
Date: Mon, Apr 20, 2020 at 10:12 PM
Subject: [Ace] Authentication and Authorization for Constrained Environments 
(ace) WG Virtual Meeting: 2020-05-18
To: IETF-Announce mailto:ietf-annou...@ietf.org> >
Cc: mailto:ace@ietf.org> >



The Authentication and Authorization for Constrained Environments (ace) Working 
Group will hold
a virtual interim meeting on 2020-05-18 from 10:00 to 11:30 America/New_York 
(14:00 to 15:30 UTC).

Agenda:
(No agenda submitted)

Information about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee

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




 

-- 

Daniel Migault

Ericsson

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

Re: [Ace] draft-ietf-ace-oauth-authz

[Jim Schaad]

-Original Message-
From: Michael Richardson  
Sent: Tuesday, May 5, 2020 11:07 AM
To: Jim Schaad ; 'Ace' 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz


Jim Schaad  wrote:
> I have much the same problem.  While a client could find an AS which
> would authenticate the client, I don't know how the client would
> establish any degree of trust in the AS which is going to give it
> tokens.

Is your question that you don't know how to trust that the AS is the correct
AS for RS-foo?

[JLS] No, my question is how do I know to trust the AS period.  I don't have
a key to establish a secure session with the AS.  I guess doing full X.509
certificate processing would be an answer, but that could be difficult in
the event of a key compromise.

> If you have already put a local public key for the AS into the
> client, then you might as well put in a name for the AS as well.  I
> suppose you could get by with a shared secret but that does not seem
to
> be a good way to build up the system.

Maybe there are redundant instances of the AS, or maybe there are multiple
ways (thus different IP addresses) by which to reach the AS.
[JLS] It could be that there are redundant instances of the AS, but then you
have the problem of either doing key sharing between all of them or needing
the ability to validate the key assigned to each of them.  If you have
different addresses, that might be interesting, but you are going to need to
do trial connections to each possible AS found until you get one that works.

Jim



--
Michael Richardson , Sandelman Software Works  -=
IPv6 IoT consulting =-




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

Re: [Ace] draft-ietf-ace-oauth-authz

[Jim Schaad]

Thanks Peter, that makes things a lot clearer.  However I think that you are 
not asking for who is an AS, but who is an AS that has a particular interface.  
It would make more sense to define a new interface identifier for the 
upload/control protocol rather than just identifying who is an AS.

 

Jim

 

 

From: Ace  On Behalf Of Peter van der Stok
Sent: Tuesday, May 5, 2020 12:26 AM
To: Benjamin Kaduk 
Cc: Jim Schaad ; Olaf Bergmann ; 
'Ace' 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

 

HI all,

I agree about the authorization/trust problem.
My request concerns something more trivial.

Suppose we have this new network with a set of servers, an (AS) (may be more) 
and a controller.
The servers, controller and AS may have used BRSKI to enter the network.
The servers will only provide their service when a token has been sent.
The AS is completely empty, not aware of the servers or its clients.
The controller wants to fill the AS with the necessary information.

Both controller and AS have agreed on an initialization protocol, and are 
equipped with the necessary secrets. (A protocol to be standardized in general, 
but not my concen here)

Now, what IP address does the controller use to start the communication?

Typing in the IP address is a possibility, switching off all other devices is 
another, etc...
I hoped that a coap discovery could be used such that the controller learns the 
IP address of the AS.

When several AS servers are present, the controller can access each one of them 
out till it accesses the AS with the correct credentials.

I hope my request has become a bit clearer.

Peter



Benjamin Kaduk schreef op 2020-05-05 06:09:

On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote: 

Hi Peter,

Peter van der Stok mailto:stokc...@bbhmail.nl> > writes:




When I want to access an OCF device I can find its IP address through
service discovery (rfc7252 section 7) using an rt-value registered at
the IANA core parameters registry.  For example, when I want to
initialize the AS I have to type in the IP address of the AS.  From
that moment on keys and certificates can be compared to continue
initialization.

Using service discovery can automate that process.

My request is that authz draft registers an rt-value in core
parameters registry for service discovery of the AS, unless a
different process has already been established for AS initialization.


That is exaclty what originally has been done in section 9 of
draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the
process.


I think I'm still a little confused as to what good being able to
"discover" that the network says something is an AS is, without some prior
trust and/or key material for that AS.  How would the necessary trust be
established as part of such a discovery scheme?

Thanks,

Ben

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

Re: [Ace] draft-ietf-ace-oauth-authz

[Jim Schaad]

I don't see how the four-corner model solves the issue that I highlighted.  If 
the client does not have a key for any local AS, then nothing helps.  The 
four-corner model deals with the issue of the client and the RS not trusting 
the same AS, but the different AS entities trust each other on the back side.

Getting trust in a local AS seems to be a bootstrapping problem.

Jim


-Original Message-
From: Carsten Bormann  
Sent: Monday, May 4, 2020 10:38 PM
To: Jim Schaad 
Cc: Benjamin Kaduk ; Olaf Bergmann ; Peter van 
der Stok ; peter van der Stok 
; Ace 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

On 2020-05-05, at 06:54, Jim Schaad  wrote:
> 
> I have much the same problem.  While a client could find an AS which 
> would authenticate the client, I don't know how the client would 
> establish any degree of trust in the AS which is going to give it tokens.

Hence the four-corner model [1].

Grüße, Carsten

[1]: https://tools.ietf.org/html/draft-ietf-ace-actors

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

Re: [Ace] draft-ietf-ace-oauth-authz

[Jim Schaad]

I have much the same problem.  While a client could find an AS which would
authenticate the client, I don't know how the client would establish any
degree of trust in the AS which is going to give it tokens.  If you have
already put a local public key for the AS into the client, then you might as
well put in a name for the AS as well.  I suppose you could get by with a
shared secret but that does not seem to be a good way to build up the
system.

Jim


-Original Message-
From: Benjamin Kaduk  
Sent: Monday, May 4, 2020 9:09 PM
To: Olaf Bergmann 
Cc: Peter van der Stok ; Jim Schaad
; consulta...@vanderstok.org; 'Ace' 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote:
> Hi Peter,
> 
> Peter van der Stok  writes:
> 
> > When I want to access an OCF device I can find its IP address 
> > through service discovery (rfc7252 section 7) using an rt-value 
> > registered at the IANA core parameters registry.  For example, when 
> > I want to initialize the AS I have to type in the IP address of the 
> > AS.  From that moment on keys and certificates can be compared to 
> > continue initialization.
> >
> > Using service discovery can automate that process.
> >
> > My request is that authz draft registers an rt-value in core 
> > parameters registry for service discovery of the AS, unless a 
> > different process has already been established for AS initialization.
> 
> That is exaclty what originally has been done in section 9 of 
> draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the 
> process.

I think I'm still a little confused as to what good being able to "discover"
that the network says something is an AS is, without some prior trust and/or
key material for that AS.  How would the necessary trust be established as
part of such a discovery scheme?

Thanks,

Ben

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

Re: [Ace] draft-ietf-ace-oauth-authz

[Jim Schaad]

What do you expect to see?   By default a client needs to know that something 
is an AS and have a key to interact with that AS.

 

Jim

 

 

From: Ace  On Behalf Of Peter van der Stok
Sent: Wednesday, April 29, 2020 11:57 PM
To: Ace 
Subject: [Ace] draft-ietf-ace-oauth-authz

 

Hi authz authors,,

While implementing a version of AS, I noticed that there is no resource type 
(rt) registered for /.well-known/core discovery.
Is this voluntary?
If not, can it still be added?

thanks,

peter 

-- 

Peter van der Stok
vanderstok consultancy
mailto: consulta...@vanderstok.org  , 
stokc...@bbhmail.nl  
www: www.vanderstok.org  
tel NL: +31(0)492474673 F: +33(0)966015248

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

[Ace] Minutes have been uploaded

[Jim Schaad]

I have uploaded minutes to the Datatracker.  Please review and comment with
corrections.

Jim


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

Re: [Ace] Scheduling additional interim meetings

[Jim Schaad]

Reminder - If you want to have input on when the next two meetings are going
to be, you need to fill out the doodle poll.

Jim


-Original Message-
From: Ace  On Behalf Of Jim Schaad
Sent: Tuesday, April 7, 2020 8:51 PM
To: ace@ietf.org
Subject: [Ace] Scheduling additional interim meetings

Daniel and I would like to schedule two additional interim meetings to occur
in May and June.  I have created a doodle poll for the times that I know
that I am available and would like to get people to fill it in.  The poll
has options for May dates in it.  The June dates would be 4 weeks later so
please look at both the May and June dates when filling out the poll.

As an example, May 12th and June 9th are represented as May 12th in the
poll.

https://doodle.com/poll/e7vtvi5zx3eekcgw

Thanks for filling this in.  We should be able to announce the final dates
at the April 15th interim meeting.

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] Scheduling additional interim meetings

[Jim Schaad]

Daniel and I would like to schedule two additional interim meetings to occur
in May and June.  I have created a doodle poll for the times that I know
that I am available and would like to get people to fill it in.  The poll
has options for May dates in it.  The June dates would be 4 weeks later so
please look at both the May and June dates when filling out the poll.

As an example, May 12th and June 9th are represented as May 12th in the
poll.

https://doodle.com/poll/e7vtvi5zx3eekcgw

Thanks for filling this in.  We should be able to announce the final dates
at the April 15th interim meeting.

Jim


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

Re: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

[Jim Schaad]

And I thought this was why we “hired” experts.

 

As has been  noted previously in this discussion, there is no requirement that 
the scope must be a text string, it can be a binary string as well.  Further, I 
believe that there will start being some dictionary work being done at some 
point in the future when defining a new scope format so that any text strings 
could be compressed down.

 

I also am of the opinion that one of the major uses of CWTs is going to be as 
an authorization token and that scoping of authorization is an important part 
of this.   I would probably be more sympathetic to the argument of making it 
two bytes if that had been done for about half of the items currently 
registered.

 

I would make it a one byte because I think it is important, is going to be used 
by a lot of places where just audience is not sufficient to restrict scope, and 
ACE is the current hotspot where it is going to be used.  Both for general 
purpose authorization and for the group/multicast authorization as well.  My 
current expectation is still that most of the time HTTP will be using JWT not 
CWT.  

 

Jim

 

 

From: Hannes Tschofenig  
Sent: Monday, March 23, 2020 6:41 AM
To: Jim Schaad ; 'Seitz Ludwig' 
; 'Mike Jones' ; 'Chuck 
Mortimore' 
Cc: chuck.mortim...@visa.com; cwt-reg-rev...@ietf.org; 
draft-ietf-ace-oauth-au...@ietf.org; drafts-expert-rev...@iana.org; ace@ietf.org
Subject: RE: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

 

Hi all, 

 

This is an interesting case. 

 

CWT was created based on the work on ACE-OAuth. I would therefore agree with 
Ludwig that it should receive priority treatment with regards to the selection 
of the value encodings. 

 

I do, however, also have sympathy for the argument Chuck mentioned regarding 
the scope encoded as a string. Of course, there is no need to encode the scope 
as a human-readable string.  

 

The main question is whether we should argue about one byte. 

 

Highly-paid ACE chairs: what is your opinion? 

 

Ciao
Hannes

 

 

From: Jim Schaad mailto:i...@augustcellars.com> > 
Sent: Saturday, March 21, 2020 4:32 PM
To: 'Seitz Ludwig' mailto:ludwig.se...@combitech.se> >; 'Mike Jones' mailto:michael.jo...@microsoft.com> >; 'Chuck Mortimore' 
mailto:charliemortim...@gmail.com> >; Hannes 
Tschofenig mailto:hannes.tschofe...@arm.com> >
Cc: chuck.mortim...@visa.com <mailto:chuck.mortim...@visa.com> ; 
cwt-reg-rev...@ietf.org <mailto:cwt-reg-rev...@ietf.org> ; 
draft-ietf-ace-oauth-au...@ietf.org 
<mailto:draft-ietf-ace-oauth-au...@ietf.org> ; drafts-expert-rev...@iana.org 
<mailto:drafts-expert-rev...@iana.org> ; ace@ietf.org <mailto:ace@ietf.org> 
Subject: RE: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

 

No you should not need to make any changes in the document.  This will be taken 
care of by the RFC Editor.

 

Jim

 

 

From: Ace mailto:ace-boun...@ietf.org> > On Behalf Of 
Seitz Ludwig
Sent: Saturday, March 21, 2020 3:35 AM
To: Mike Jones mailto:michael.jo...@microsoft.com> >; Chuck Mortimore 
mailto:charliemortim...@gmail.com> >; 
hannes.tschofe...@arm.com <mailto:hannes.tschofe...@arm.com> 
Cc: chuck.mortim...@visa.com <mailto:chuck.mortim...@visa.com> ; 
cwt-reg-rev...@ietf.org <mailto:cwt-reg-rev...@ietf.org> ; 
draft-ietf-ace-oauth-au...@ietf.org 
<mailto:draft-ietf-ace-oauth-au...@ietf.org> ; drafts-expert-rev...@iana.org 
<mailto:drafts-expert-rev...@iana.org> ; ace@ietf.org <mailto:ace@ietf.org> 
Subject: Re: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

 

Please disregard the last message (small keyboard, large fingers). What I 
intended to write was this:

 

Sorry for the delay, I’ve now looked into the changes necessary and it 
basically is this line in the draft:

 

8.13. CBOR Web Token Claims

[…]

Claim Key: TBD (suggested: 9) -> … suggested: 42)

 

I wonder if I need to make this change at all since the value is only suggested 
(and we now have a diverging decision by the designated experts). Can  IANA 
clarify this for me?

 

Thank you for your patience,

 

 

Ludwig

 

 

From: Seitz Ludwig mailto:ludwig.se...@combitech.se> > 
Sent: den 21 mars 2020 11:26
To: Seitz Ludwig mailto:ludwig.se...@combitech.se> 
>; Mike Jones mailto:michael.jo...@microsoft.com> 
>; Chuck Mortimore mailto:charliemortim...@gmail.com> >; hannes.tschofe...@arm.com 
<mailto:hannes.tschofe...@arm.com> 
Cc: chuck.mortim...@visa.com <mailto:chuck.mortim...@visa.com> ; ace@ietf.org 
<mailto:ace@ietf.org> ; draft-ietf-ace-oauth-au...@ietf.org 
<

[Ace] Congestion control needs to be included

[Jim Schaad]

I had a weird weekend trying to get coverage testing up for my Observe
implementation and in the process found out that it had not implemented the
required congestion control.  As part of this I had to go back and do a
careful read of RFC 7641 to get things right in my code and following that I
thought that this document really needs to have a discussion of congestion
control as well.  Part of this can be a reference to section 4.5.1 of RFC
7641 where we are using observe but we need to go through the document and
potentially look at some other places where we need to discuss congestion as
well.

I will also note that observe does not guarantee that all messages will be
sent to a client, just that after a while it will have the most current
version of the content.  This means that there is a high probability that
clients will not get every update of key material if turn over is being done
at all quickly.

Jim


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

Re: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

[Jim Schaad]

No you should not need to make any changes in the document.  This will be taken 
care of by the RFC Editor.

 

Jim

 

 

From: Ace  On Behalf Of Seitz Ludwig
Sent: Saturday, March 21, 2020 3:35 AM
To: Mike Jones ; Chuck Mortimore 
; hannes.tschofe...@arm.com
Cc: chuck.mortim...@visa.com; cwt-reg-rev...@ietf.org; 
draft-ietf-ace-oauth-au...@ietf.org; drafts-expert-rev...@iana.org; ace@ietf.org
Subject: Re: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

 

Please disregard the last message (small keyboard, large fingers). What I 
intended to write was this:

 

Sorry for the delay, I’ve now looked into the changes necessary and it 
basically is this line in the draft:

 

8.13. CBOR Web Token Claims

[…]

Claim Key: TBD (suggested: 9) -> … suggested: 42)

 

I wonder if I need to make this change at all since the value is only suggested 
(and we now have a diverging decision by the designated experts). Can  IANA 
clarify this for me?

 

Thank you for your patience,

 

 

Ludwig

 

 

From: Seitz Ludwig mailto:ludwig.se...@combitech.se> > 
Sent: den 21 mars 2020 11:26
To: Seitz Ludwig mailto:ludwig.se...@combitech.se> 
>; Mike Jones mailto:michael.jo...@microsoft.com> 
>; Chuck Mortimore mailto:charliemortim...@gmail.com> >; hannes.tschofe...@arm.com 
 
Cc: chuck.mortim...@visa.com  ; ace@ietf.org 
 ; draft-ietf-ace-oauth-au...@ietf.org 
 ; drafts-expert-rev...@iana.org 
 ; cwt-reg-rev...@ietf.org 
 
Subject: RE: [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

 

Hello all, soo

 

From: Ace mailto:ace-boun...@ietf.org> > On Behalf Of 
Seitz Ludwig
Sent: den 17 mars 2020 10:01
To: Mike Jones mailto:michael.jo...@microsoft.com> >; Chuck Mortimore 
mailto:charliemortim...@gmail.com> >; 
hannes.tschofe...@arm.com  
Cc: chuck.mortim...@visa.com  ; ace@ietf.org 
 ; draft-ietf-ace-oauth-au...@ietf.org; 
drafts-expert-rev...@iana.org  ; 
cwt-reg-rev...@ietf.org  
Subject: Re: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

 

Fair enough, take my points as the author’s opinion only.  That leaves us with 
3 experts to make the decision. Your position is clear, Chuck hasn’t commented 
on the latest exchange but he was agreeing with you before. I propose we give 
Hannes another day and if he doesn’t comment we go ahead with your decision, is 
that acceptable for you?

 

/Ludwig

 

 

From: Mike Jones mailto:michael.jo...@microsoft.com> > 
Sent: den 16 mars 2020 19:43
To: Seitz Ludwig mailto:ludwig.se...@combitech.se> 
>; Chuck Mortimore mailto:charliemortim...@gmail.com> >; hannes.tschofe...@arm.com 
 
Cc: drafts-expert-rev...@iana.org  ; 
cwt-reg-rev...@ietf.org  ; 
chuck.mortim...@visa.com  ; 
draft-ietf-ace-oauth-au...@ietf.org 
 ; ace@ietf.org 
 
Subject: RE: [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

 

Ludwig, yes, while you’re a designated expert, note that the instructions to 
the designated experts at https://tools.ietf.org/html/rfc8392#section-9 
includes this text:

   In cases where a registration decision could

   be perceived as creating a conflict of interest for a particular

   Expert, that Expert should defer to the judgment of the other

   Experts.

 

So, as I see it, you should actually recuse yourself from this decision.  That 
said, I’ve sent a private note to Hannes asking him to also weigh in.

 

   Cheers,

   -- Mike

 

From: Seitz Ludwig mailto:ludwig.se...@combitech.se> > 
Sent: Monday, March 16, 2020 3:18 AM
To: Mike Jones mailto:michael.jo...@microsoft.com> >; Chuck Mortimore 
mailto:charliemortim...@gmail.com> >; 
hannes.tschofe...@arm.com  
Cc: drafts-expert-rev...@iana.org  ; 
cwt-reg-rev...@ietf.org  ; 
chuck.mortim...@visa.com  ; 
draft-ietf-ace-oauth-au...@ietf.org 
 ; ace@ietf.org 
 
Subject: [EXTERNAL] RE: [Cwt-reg-review] [IANA #1158953] Requested review for 
IAN

[Ace] Missing role

[Jim Schaad]

There is a missing role/functionality that needs to be added to the
document.  "proxy signature checker" has the ability to get the public keys
associated with the different members of the group but does not get any
access to the symmetric keying material

Jim


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

[Ace] FW: Review of draft-ietf-ace-key-groupcomm-oscore-05

[Jim Schaad]

Forgot to cc the group

-Original Message-
From: Jim Schaad  
Sent: Sunday, March 15, 2020 1:48 PM
To: 'draft-ietf-ace-key-groupcomm-osc...@ietf.org'

Subject: Review of draft-ietf-ace-key-groupcomm-oscore-05

* Introduction:  In para 2, the second sentence needs to be re-written.  If
you remove the subclause, then you get "This relies on a Group Manager where
members exchange   CoAP messages secured with Group OSCORE." Which is wrong.

* Section 2 -  The following is a problematic statement " All communications
between the involved entities rely on the CoAP protocol and MUST be
secured."  For something like MQTT you want to be able to do it in JSON/HTTP

* Section 2.2 - I think it might be worthwhile in para 3 to give the reason
for needing a new group identifier - This is because of the conflict in name
between group identifier of OSCORE and group identifier of
ace-key-groupcomm.  You have not yet stated that they are different things.

* Section 3.1 - I think I said this before but ["requester", "monitor"]
seems to be a bit of an oxymoron.  Anybody who is either a requester or a
responder can be a monitor without advertising the fact.

* Section 3.1 -  The table in figure 1 is currently not usable due to the
definition of scope in ace-key-groupcomm.

* Section 3.1 - The framework allows for the scope and the audience to be
implicit for an endpoint that is only doing one thing.  Are you sure you
want to eliminate that option?

* Section  4 - I think you probably want to justify the reason for changing
the base name of the resource.  Also the same comments that I made in
ace-key-groupcomm about registering as a well-known are going to exist if
you really want it to be fixed.

* Section 5.2 - scope should not be a mandatory element in the request - it
is implicit in the path name and the scope in the token.

* Section 5.2.1 -  Is this a place where we need to look at replay?  I don't
think so because of the cryptographic wrapper, but we need to have that
discussion in the document.  Which indicates a pointer from this section to
where that discussion is.

* Section 5.4 - cs_alg should refer to the IANA registries not the COSE
document - what if there is a new signature algorithm, like say RSA.

* Section 6 - is it an error for a monitor to provide a public key?  After
all an invalid signature would not need to be checked.   To make life even
more fun, does the rsnonce need to be provided on a token post?

* Section 8 - For bullet 2.a - Is there a reason why this does not do the
rekey and return the new key material rather than returning an error?



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

[Ace] Review for draft-ietf-ace-key-groupcomm-05

[Jim Schaad]

Here is a new review - the sooner you ask about anything that is unclear the
more likely I will remember what I was referring to.

Jim



*  In figure 4:  The CDDL is not correct.  "2*role" should be "2*role:tstr"
or role should be defined as a separate item

* Section 3.2 - The third to last paragraph is incorrect, the token should
have the expires AT not the expires IN parameter.  There is a solid
assumption that in this case there is a common idea of a wall clock between
all of the servers and there for stating a hard expiration time is more
appropriate than an expires in moment.  Additionally, tokens will generally
not include the rs_cnf even if it is in the response message and will
include a cnf for an asymmetric key.  In short, this paragraph is just plain
wrong.

* In section 3.2 - Why is the AS not allowed to return the same
authorization token to the same request assuming that things such as the
amount of time left before it expires would seem reasonable.  I am not sure
why this is a requirement let along one in this draft.   Additionally, it
says nothing about re-use of the same secret for a symmetric algorithm which
also might be something that needs to be said.

* In Section 3.3 - As an input to your "make it an array" decisions,
remember that the order of scope elements that the client gave to the AS are
not necessarily the same order as are in the token.  I think you might just
need to collapse all three arrays into a single value in the map.

* In section 3.3 - Move the data structure of sign_info to section 3.3.1

* In section 3.3 - Move the data structure description of pub_key_enc to
section 3.3.2

* In section 3.3.3 - I think you might want to rename the 'rsnonce' to be
something that is KDC specific.

* In section 4.1 - I am not sure that I like the idea of reserving
/ace-group against all comers, esp. as this is not the resource name that is
being used by the OSCORE version of the document.  You can talk to the core
people, but a better way of saying that this is a specific interface is to
defined that as a property ("if=") and register that interface name.  If
you really do mean to reserve this name against all comers then you need to
make a registration in the well-known registry as part of the IANA sections.
The last paragraph may or may not reverse the section on /ace-group.

* In section 4.1.2.1 - You cannot really reference cnonce to the framework
document as you are going to be using a different content-format and
therefore a new identifier is needed.

* In section 4.1.2.1 - See issue #60 on github about when credential
verification is needed.

* In section 4.1.2.1 - Please insert a forward pointer on 'control_path' to
a section which describes exactly what this is supposed to be doing because
it is not clear from this text.  I think it will need more than a single
paragraph to do so. 

* In section 4.1.2.1 - What happens if a 'control_path' is provided but not
supported - does that mean a bad request?

* In section 4.1.2.1 - /assigns a name NAME to the node/   is this assigning
a name to the node or to the join result?  I don't know what the node would
be but I may have missed a definition.

* In section 4.1.2.1 - Unless you have a reason for allowing floating point
for 'exp', make it integer only.  

* In section 4.1.2.1 - For control_path,  I assume that fragment is not
supported - are paramenters?  The problem is that you say "URI path" which
has a meaning.

* In section 4.1.2.1 - Mismatch between NAME and NODENAME in the text - need
to harmonize

* In Section 4.1.2.1 - I believe that the minimal content for a join request
is an empty map.  I believe that the minimal content for a join response is
an empty map.  The first makes sense as authorization comes from else where
and so can the public key if it is needed.  I am not so sure that an empty
response makes a great deal of sense for a response but it may be what you
intended.

* In Section 4.1.2.2 - I am not sure that it makes sense to return key
material to a client for which the scope permits it to join, but which has
not actually done the join process.   

* In section 4.1.3.1 - I would like to have the ability to do a fetch based
on the roles of the client associated with the public key.  That is I would
like to retrieve only those public keys associated with a requestor.

* In section 4.1.4.1 - Is there any information in the policies which is
sensitive?   Is there a reason not to return this info to everybody?

* In section 4.1.5.1 - Should this be restricted to group members?

* In section 4.1.6.1 - This is be restricted to just the correct client -
That is subscriber #2 should not be able to access subscriber #1's resource
here.

* In section 4.1.6.3 - The third paragraph is redundant as this is already
covered by the first paragraph

* In section 4.1.6.3 - The second and fourth paragraph are not making any
sense.  There is no body for a DELETE handler.

* In section 4.1.7.1 - If a public key is replaced, doe

[Ace] Using OAuth and ACE-OAuth with MQTT

[Jim Schaad]

Hannes,

This is going to be a long email and I hope that I do not get too many
things wrong in the process of getting it written up.

So the question that you raised is can the current MQTT profile use the
existing OAuth and ACE-OAuth protocols.  My assertion is that the answer is
yes and I will walk through the two different protocols in order to
demonstrate this.  For simplicilty I am only going to deal with one of the
TLS configurations that the MQTT profile envisions.

For TLS authentication, the server is to be validated by using an X.509
certificate and there is to be a method for the client to be able to
associate the identifier in the certificate with the OAuth token request.
This I assume is a well understood problem in the OAuth WG.  The client is
not authenticated to the server by TLS, this is deferred to MQTT protocol.
When using ACE-OAuth, this is generally going to be tied through the
audience field in some method.

The format of the scope field is defined in the MQTT document and the AS
will need to be able to parse that field and do the proper enforcement.  I
think this different than what a normal OAuth AS does where the scope is a
single value rather than a composite value.

The key which is placed in the token is going to be an asymmetric signing
key.  This is the standard thing for OAuth.  At some point in the future it
might be nice to allow for symmetric keys to be sent out, but for now the
ACE-OAuth is sufficient for dealing with that case.

Using OAuth

The client makes a request to an OAuth authorization server for a token.
The grant_type for the token is going to be "client_credentials", the scope
is a text string defined by the MQTT profile document.  Authorization is
needed for the connection.  My assumption is that this is now normally done
by the use of HTTPS rather than something like basic authentication.

**

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
scope=publish_topic1/topic2%2Epublish_topic3/+/stats%2Esubscribe_topic3/#

**

The AS response with a standard message

**

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
 "access_token":". JWT token ..",
 "token_type":"bearer",
 "expires_in": 3600,
}

**

The client now connects to the MQTT server using TLS, validating the
certificate of the server against it's trust anchors and the "known" name of
the MQTT server.

The client now sends an MQTT CONNECT message to the server passing the JWT
token in as part of the Authentication Data (section 2.2.4 of the MQTT
document).




Using ACE-OAuth

***

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/ace+json

{
  "scope": "publish_topic1/topic2 publish_topic3/+/stats
subscribe_topic3/#",
  "audience": "mqtts://mqtt.example.com"
}

**

For ACE-OAuth, the default value of grant_type is client_credentials so that
parameter is omitted.


*

HTTP/1.1 200 OK
Content-Type: application/ace+json

{
 "access_token":". JWT token ..",
 "expires_in": 3600,
 "ace_profile" : "mqtt_tls"
}



As can be seen, there are only minimal differences between what is sent out
between the Vanilla and the ACE version of OAuth.  In both cases it is
assumed that the client is going to know which asymmetric key is going to be
used.  There are a couple of differences however:

1.  I have used the value of "bearer" for "token_type" in OAuth because that
seemed to me to be the one which mapped to the usage in a better manner.
The OAuth-ACE framework however registers the value of "PoP" and specifies
it as the default value.  It may make more sense to use that value in the
OAuth case as well.

2.  In the ACE-OAuth case, we can return a key to the user and thus be able
to do symmetric keys as well.  If you are already doing TLS and validating
signatures that way I would expect that this is not going to be a common
case.

3.  In the ACE-OAuth case, it is possible to return information about the
TLS key that the server would be using.  This would allow for situations
were the MQTT TLS connection is not doing certificate chain validation, but
instead using information passed in the rs_cnf field to validate either the
public key or the certificate directly.


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

Re: [Ace] Comments on the MQTT draft

[Jim Schaad]

 

 

From: Cigdem Sengul  
Sent: Monday, March 9, 2020 5:35 AM
To: Jim Schaad 
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 
Subject: Re: Comments on the MQTT draft

 

Hello Jim,

Comments inline.

 

 

Yes, I can see this can be problematic but this was to avoid the broker keeping 
state for clients that are no more authorised to receive those messages. The 
session state can include actual messages if QoS>=1, so maybe high overhead. 

 

The Session Expiry is also set by the client:

 

[JLS] All of that makes a great deal of sense to me.   What if a session 
expires when a token expires independent of the client’s request for a long 
session expiry interval.  After all, if the token is the identity then if the 
token expires you can no longer prove you are the same person and thus can have 
the same session back.   You probably need some weasel text about allowing for 
an expired session to get a new token if it is kept open perhaps, but I have 
not looked exactly when a connection would be forced closed due to token 
expiration yet.

 

[CS] Yes. We opted for not keeping any state because that indeed had too many 
problematic issues. One was, as I already mentioned, extra state kept for a 
time determined by the client (session expiry) - which we thought would cause 
trouble. There are some non-normative text in MQTT spec about how the server 
storage limits or admin policies can overwrite client-set expiry. 

The other issue is that the broker checks existing session with the (MQTT) 
Client Identifier. This info is not burned into the token (note that this 
client id is different than ACE client id used for e.g., authenticating to AS)

So, I feel that is problematic as well... 

So, there is a security-qos trade-off. 

 

[JLS]  I was planning to put a pointer to the token into my session state so 
that it could be checked.  However, as I stated in the original.  This needs to 
be justified one way or the other in the document. 

 

 


4.  I keep going back and forth on a recommendation that we channel bind in
the challenge response case.  I don't have the knowledge to be able to do a
formal proof, but I think that all of necessary conditions are going to be
met without it.  However, having the binding included would most likely make
the proofs that much easier.  

 

[CS] I am confused about this as well. Because, as we discussed in the interim 
meeting, the exporter-based

flow only works at the connection time, and not for reauthentication (that is 
why we kept the challenge/response flow). 

I am aiming to submit the v04 - but I will probably need to submit v05 to 
clarify all this. 

 

[JLS]]  You can do the exporter at any time.  I was thinking in terms of 
signing the triple of 

 

 Thanks,

-Cigdem 

 


Jim

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

Re: [Ace] Comments on the MQTT draft

[Jim Schaad]

 

 

From: Cigdem Sengul  
Sent: Sunday, March 8, 2020 3:30 PM
To: Jim Schaad 
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 
Subject: Re: Comments on the MQTT draft

 

Hello Jim,

 

Comments inline.

 

On Sun, Mar 8, 2020 at 7:04 PM Jim Schaad mailto:i...@augustcellars.com> > wrote:

1.  I want to verify that the following is the desired statement:  There is
a strong preference that TLS not use PSK for authentication.  This follows
from the recommendation to use TLS:Anon-MQTT:ace for the authentication
option.  I have no problems with this statement, I just want to be sure that
the group as a whole is ok with this position.   I found that I implemented
the SHOULD NOT option for PSK to start with, but that is because I was
trying to be completist not because I think the position is wrong.

 

To tell the truth, I've put the RECOMMENDED as I believed it was expected that 
I provide a recommendation. 

Otherwise, any of the methods are OK (with some exceptions for anon:anon, and 
over authenticating/authorising with the last mode).  

 

[JLS]  I approve of having a recommended method, that is one which everybody 
will implemented, I just want to ensure people think this is the right one.

 


2.  While implementing I found that there did not appear to be a mandatory
to implement validation algorithm, one needs to be specified.

 

Do you mean mandatory-to-implement certificate validation policy?

 

[JLS]  What cryptographic algorithm is used to implement the hash/signature for 
the two authentication methods – it can be the same for both.


3.  After reading the log of bugs which have been showing up on the MQTT
code base that I have been using, I think there needs to be text put into
the document to deal with the clean session requirement that this profile is
enforcing.  I am seeing a lot of people who are relying on the fact they are
not reconnecting with clean session to get QoS information back from the
server in the event of unexpected disconnects.

 

Yes, I can see this can be problematic but this was to avoid the broker keeping 
state for clients that are no more authorised to receive those messages. The 
session state can include actual messages if QoS>=1, so maybe high overhead. 

Session State in the Server consists of:

* The existence of a Session, even if the rest of the Session State is 
empty.

* The Clients subscriptions, including any Subscription Identifiers.

* QoS 1 and QoS 2 messages which have been sent to the Client, but have 
not been completely acknowledged.

* QoS 1 and QoS 2 messages pending transmission to the Client and 
OPTIONALLY QoS 0 messages pending transmission to the Client.

 

The Session Expiry is also set by the client:

When a client connects with a long Session Expiry Interval, it is requesting 
that the Server maintain its MQTT session state after it disconnects for an 
extended period. Clients should only connect with a long Session Expiry 
Interval if they intend to reconnect to the Server at some later point in time. 
When a client has determined that it has no further use for the Session it 
should disconnect with a Session Expiry Interval set to 0.  

 

[JLS] All of that makes a great deal of sense to me.   What if a session 
expires when a token expires independent of the client’s request for a long 
session expiry interval.  After all, if the token is the identity then if the 
token expires you can no longer prove you are the same person and thus can have 
the same session back.   You probably need some weasel text about allowing for 
an expired session to get a new token if it is kept open perhaps, but I have 
not looked exactly when a connection would be forced closed due to token 
expiration yet.

 

 


4.  I keep going back and forth on a recommendation that we channel bind in
the challenge response case.  I don't have the knowledge to be able to do a
formal proof, but I think that all of necessary conditions are going to be
met without it.  However, having the binding included would most likely make
the proofs that much easier.  

 


Jim



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

[Ace] Planning for the Vancouver Meeting

[Jim Schaad]

It appears that the logistics for the upcoming meeting in Vancouver are
going to be more complicated than is normal.  To start with at the present
time it appears that neither of the chairs are going to be physically
present for the meeting.

Please let the chairs know if you desire to do a presentation for Vancouver.
We will need the following information:

1.  What document or proposed document are you addressing?
2.  How long do you think it is going to take?
3.  Are you planning to give the presentation locally or remotely?  If you
are going to be remote is there somebody who might be able to do it locally?

In addition to the normal volunteers for a Jabber Scribe (local) and one or
more notetakers (one local and others either local or remote), we are going
to need to get somebody to sit up at the front of the meeting and get slides
up and press buttons for meetecho.  If you can do any of these please let us
know that as well.

Jim & Daniel


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

[Ace] Comments on the MQTT draft

[Jim Schaad]

1.  I want to verify that the following is the desired statement:  There is
a strong preference that TLS not use PSK for authentication.  This follows
from the recommendation to use TLS:Anon-MQTT:ace for the authentication
option.  I have no problems with this statement, I just want to be sure that
the group as a whole is ok with this position.   I found that I implemented
the SHOULD NOT option for PSK to start with, but that is because I was
trying to be completist not because I think the position is wrong.

2.  While implementing I found that there did not appear to be a mandatory
to implement validation algorithm, one needs to be specified.

3.  After reading the log of bugs which have been showing up on the MQTT
code base that I have been using, I think there needs to be text put into
the document to deal with the clean session requirement that this profile is
enforcing.  I am seeing a lot of people who are relying on the fact they are
not reconnecting with clean session to get QoS information back from the
server in the event of unexpected disconnects.

4.  I keep going back and forth on a recommendation that we channel bind in
the challenge response case.  I don't have the knowledge to be able to do a
formal proof, but I think that all of necessary conditions are going to be
met without it.  However, having the binding included would most likely make
the proofs that much easier.  

Jim


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

Re: [Ace] [Rats] [Cbor] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

[Jim Schaad]

 

 

From: Laurence Lundblade  
Sent: Friday, March 6, 2020 7:38 AM
To: Henk Birkholz 
Cc: Jim Schaad ; Smith, Ned ; 
Michael Richardson ; r...@ietf.org; ace@ietf.org; 
c...@ietf.org
Subject: Re: [Rats] [Cbor] [Ace] RATS Entity Attestation Tokens (EAT) - to be a 
CWT or not to be a CWT?

 

So far, there are three things we have turned up in work on EAT that we would 
like considered as changes to CWT.

 

1) Naked CWT’s, probably tagged

The point of the tag would be for use in protocols where you can’t tell a naked 
CWT is a CWT by the context of the protocol. So far we seem to always assign a 
tag to new CBOR data structures for this purpose. For naked CWT’s, it seems we 
really should have the tag, even if it makes Jim’s code larger.

 

2) Disallow floating point dates

Right now CWT allows dates like the expiration date to be floating point. The 
only use of floating point dates is fractional seconds and dates so large they 
are not human time scale. As it stands a CWT decoder MUST implement floating 
point. This is a substantial burden for no good reason at all. One option here 
is an incompatible change to these data items. Another is to define new 
integer-only data items (new labels/keys) for the same data items.

 

 

[JLS] As far as I am concerned this is just a profiling effort.  I also agree 
that it makes almost no sense to use floating point for dates in almost all 
cases where CWT claims have been created.

 

3) Claims Characteristics for new registered claims

A lot of people had a lot of opinions and points on what data formats and types 
and such were used for claims back in 2019 in EAT. I (hopefully) captured most 
of that in some recommendations for claims characteristics. Text is currently 
here in a PR against the EAT draft <https://github.com/ietf-rats-wg/eat/pull/7> 
, but it seems it really should be for all CWT claims.

 

[JLS]  After one fast read, I think that these are good generic suggestions, 
however I disagree that this should be true for all CWT claims.  There is an 
explicit expert review section that is designed for the registration of 
extremely explicit claims that will violate these guidelines.   

 

jim

 

I don’t know if there are more things EAT would like to change in CWT. Or maybe 
there are other uses of CWT that would like to change it.

 

 

I proposed that EAT be an update to the CWT RFC. Dave Thaler said they should 
probably be separate from EAT and handled in the ACE WG and that made sense to 
most of us. Seems to me that a new RFC that either updates or obsoletes 8392 
would be the thing to do, but maybe there are other ways. 

 

LL

 





On Mar 6, 2020, at 2:30 AM, Henk Birkholz mailto:henk.birkh...@sit.fraunhofer.de> > wrote:

 

Please let me correct myself:

My proposal is to simply assign a single CBOR tag for unsigned (aka "naked") 
CWT Claims sets. I wrote "EAT" Claims Set before and that made me loose the 
perspective that an EAT is a CWT (I should read my own subject more often...).

I think this is useful outside of RATS as well and will start a corresponding 
draft in RATS to create a more tangible proposal that elaborates on motivation 
& background: as with YANG modules, CBOR tags can be defined in any WG.

There are multiple benefits to this approach:

* parsers can choose to ignore tags in any case,
* it is the least invasive approach (next to doing nothing),
* we will not be the ones that attempt to reopen RFC8392, and
* we detach this effort from progressing EAT as it is CWT-related.

Viele Grüße,

Henk


On 06.03.20 08:35, Henk Birkholz wrote:



Hi Jim,
from an implementation point of view that is fine. To quote Carsten here "tags 
are cheap" and you would have to parse the whole structure to make sure it is 
an EAT Claims Set. My point is, it does not hurt to register a CBOR tag for an 
unsigned EAT Claims Set that adheres to the some content definitions as EAT, 
but that is not signed via a COSE array. In contrast, in most cases it does 
help, I think, and enables a clear semantic equivalence for the content.
Viele Grüße,
Henk
On 06.03.20 03:15, Jim Schaad wrote:



I would not claim that a collection of CWT claims is a CWT.  I would agree that 
a CWT does require that some security be applied.  I was instead making the 
argument that there was no need to have a special marking for the collection as 
oppose to the CWT since it is possible to distinguish the cases apart.   In 
CDDL I would put something like

claimsMade = CWT / claimsMap

where the CWT is over a claimsMap element.   In this case one could easily 
distinguish between the two cases without additional tagging.

Jim


-Original Message-
From: Ace mailto:ace-boun...@ietf.org> > On Behalf Of 
Smith, Ned
Sent: Thursday, March 5, 2020 4:48 PM
To: Michael Richardson mailto:mcr+i...@sandelman.ca> >; 
r...@ietf.org <mailto:r...@ietf.org> ; ace@ietf.org <mailto:ace@ietf.org> ; 
c...@

Re: [Ace] [Cbor] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

[Jim Schaad]

Henk,

I want to re-iterate that this is not quite the same no/low cost situation that 
leads me to say - yes just tag it and be fine.

There is a very high chance that making this change is going to lead one into a 
situation where they are going to need to change their because people are going 
to start using this tag all of the time and not just when the claims are bare.  
That is the "unsigned CWT Claims Set" could be passed into the a COSE library 
to be signed and the tag would never be stripped.

There is also a small cost in terms of message size, but I assume that you are 
willing to absorb that.

Jim


-Original Message-
From: Henk Birkholz  
Sent: Thursday, March 5, 2020 11:35 PM
To: Jim Schaad ; 'Smith, Ned' ; 
'Michael Richardson' ; r...@ietf.org; ace@ietf.org; 
c...@ietf.org
Subject: Re: [Cbor] [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a 
CWT or not to be a CWT?

Hi Jim,

from an implementation point of view that is fine. To quote Carsten here "tags 
are cheap" and you would have to parse the whole structure to make sure it is 
an EAT Claims Set. My point is, it does not hurt to register a CBOR tag for an 
unsigned EAT Claims Set that adheres to the some content definitions as EAT, 
but that is not signed via a COSE array. In contrast, in most cases it does 
help, I think, and enables a clear semantic equivalence for the content.

Viele Grüße,

Henk

On 06.03.20 03:15, Jim Schaad wrote:
> I would not claim that a collection of CWT claims is a CWT.  I would agree 
> that a CWT does require that some security be applied.  I was instead making 
> the argument that there was no need to have a special marking for the 
> collection as oppose to the CWT since it is possible to distinguish the cases 
> apart.   In CDDL I would put something like
> 
> claimsMade = CWT / claimsMap
> 
> where the CWT is over a claimsMap element.   In this case one could easily 
> distinguish between the two cases without additional tagging.
> 
> Jim
> 
> 
> -Original Message-
> From: Ace  On Behalf Of Smith, Ned
> Sent: Thursday, March 5, 2020 4:48 PM
> To: Michael Richardson ; r...@ietf.org; 
> ace@ietf.org; c...@ietf.org
> Subject: Re: [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT 
> or not to be a CWT?
> 
> My interpretation of this thread was that CWT spec requires at least one of 
> (COSE_Encrypt, COSE_MAC, COSE_Signature) or it isn't valid COSE. That implies 
> the parser should never get to "if input is a map" as it isn't valid COSE.
> 
> If the above interpretation isn't true then the 'do nothing' option is best.
> 
> -Ned
> 
> On 3/5/20, 2:43 PM, "RATS on behalf of Michael Richardson" 
>  wrote:
> 
>  
>  { I found Jim's very interesting email very hard to read without good
>  quoting, I'm repeating the important part }
>  
>  henk> 2.) go to ACE and ask for an "unsigned token" option, 
> or
>  
>  Jim Schaad  wrote:
>  jls> I don't have a problem with this, I am not sure that I see any
>  jls> reason for it however.  See below.
>  
>  henk> 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets 
> (i.e.,
>  henk> that are not signed).
>  
>  jls> I don't see any difference between this and option #2
>  
>  jls> 4.) Just write your CWT code in a sensible manner.
>  
>  jls> My CWT code base does not make any assumptions about the number 
> or
>  jls> order of COSE security wrapping layers on a token.  It thus 
> looks
>  jls> like
>  
>  jls> while (true) {
>  jls> if input has a COSE_Encrypt tag { decrypt it; set input to the 
> content; save the encryption information if needed e.g. shared key 
> authentication; continue; }
>  jls> if input has a COSE_MAC tag { validate it; set input to the 
> content; save the MAC information if needed e.g. shared key authentication; 
> continue;}
>  jls> if input has a COSE_Signature tag { validate it; set input to 
> the content; save the signer information; continue }
>  jls> if input is a map - return input as the set of claims;
>  jls> throw an exception because it is not the correct format.
>  jls> }
>  
>  jls> This does not require a tag for a naked set of claims and would
>  jls> allow that set of claims to be pass in the same place as a CWT 
> can
>  jls> be passed.  What you are suggesting would require extra code to
>  jls> exist someplace that is going to check for an additional tag.
&

Re: [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

[Jim Schaad]

I would not claim that a collection of CWT claims is a CWT.  I would agree that 
a CWT does require that some security be applied.  I was instead making the 
argument that there was no need to have a special marking for the collection as 
oppose to the CWT since it is possible to distinguish the cases apart.   In 
CDDL I would put something like

claimsMade = CWT / claimsMap 

where the CWT is over a claimsMap element.   In this case one could easily 
distinguish between the two cases without additional tagging.

Jim


-Original Message-
From: Ace  On Behalf Of Smith, Ned
Sent: Thursday, March 5, 2020 4:48 PM
To: Michael Richardson ; r...@ietf.org; ace@ietf.org; 
c...@ietf.org
Subject: Re: [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or 
not to be a CWT?

My interpretation of this thread was that CWT spec requires at least one of 
(COSE_Encrypt, COSE_MAC, COSE_Signature) or it isn't valid COSE. That implies 
the parser should never get to "if input is a map" as it isn't valid COSE. 

If the above interpretation isn't true then the 'do nothing' option is best.

-Ned

On 3/5/20, 2:43 PM, "RATS on behalf of Michael Richardson" 
 wrote:


{ I found Jim's very interesting email very hard to read without good
quoting, I'm repeating the important part }

henk> 2.) go to ACE and ask for an "unsigned token" option, or

Jim Schaad  wrote:
jls> I don't have a problem with this, I am not sure that I see any
jls> reason for it however.  See below.

henk> 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e.,
henk> that are not signed).

jls> I don't see any difference between this and option #2

jls> 4.) Just write your CWT code in a sensible manner.

jls> My CWT code base does not make any assumptions about the number or
jls> order of COSE security wrapping layers on a token.  It thus looks
jls> like

jls> while (true) {
jls> if input has a COSE_Encrypt tag { decrypt it; set input to the 
content; save the encryption information if needed e.g. shared key 
authentication; continue; }
jls> if input has a COSE_MAC tag { validate it; set input to the 
content; save the MAC information if needed e.g. shared key authentication; 
continue;}
jls> if input has a COSE_Signature tag { validate it; set input to the 
content; save the signer information; continue }
jls> if input is a map - return input as the set of claims;
jls> throw an exception because it is not the correct format.
jls> }

jls> This does not require a tag for a naked set of claims and would
jls> allow that set of claims to be pass in the same place as a CWT can
jls> be passed.  What you are suggesting would require extra code to
jls> exist someplace that is going to check for an additional tag.

jls> IT IS
jls> ALSO GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW TAG SHOULD BE
jls> LEGAL TO PLACE INSIDE OF A CWT.  After all it makes more sense to
jls> always include it than to just sometimes include it.

Emphasis mine.
So your suggestion is to do nothing.
I also wondered why that wouldn't work, but I hadn't written enough code to
ask the question intelligently.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-


___
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] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

[Jim Schaad]

-Original Message-
From: Ace  On Behalf Of Henk Birkholz
Sent: Wednesday, March 4, 2020 2:33 PM
To: Jim Schaad ; r...@ietf.org; ace@ietf.org; 
c...@ietf.org
Subject: Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to 
be a CWT?

Hi Jim,

I'll take a stake into my heart for the group then :) Please note that I claim 
that there is no evidence that I am a vampire nor that I am the provenance of 
option 1.).
[JLS]  Please note I was planning on staking the idea not the person, I was 
just going to de-credential you.  However that does raise the question should I 
bring salt and a sewing kit (mummies) or a gun with a silver bullet 
(werewolves)?

I tried to phrase the output of the last virtual interim as neutral as possible 
and I think your reply is to be categorized as:

Option 1.) is "out of the question" as a reply from a COSE WG chair.

[JLS] That would be the COSE author and ACE and CBOR WG chair.  I am not a COSE 
WG chair.  However, I guess I hit all three asks.

Viele Grüße,

Henk

On 04.03.20 22:42, Jim Schaad wrote:
> Henk,
> 
> Well you have definitely written a message designed to get a response from me.
> 
> -Original Message-
> From: Ace  On Behalf Of Henk Birkholz
> Sent: Wednesday, March 4, 2020 10:41 AM
> To: r...@ietf.org; ace@ietf.org; c...@ietf.org
> Subject: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to 
> be a CWT?
> 
> Hi RATS enthusiasts,
> hi ACE,
> hi CBOR,
> 
> in the RATS WG we had a lot of discussions about the nature of an Entity 
> Attestation Token (EAT):
> 
>   > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/
> 
>   > https://github.com/ietf-rats-wg/eat/
> 
> A bit of (hopefully useful) context: an EAT is one way to convey 
> believable evidence from an Attester (a role residing on a device-like
> entity) to a Verifier (another role defined by RATS - the appraiser of 
> evidence). All that is done to provide a Relying Party with "simple enough" 
> attestation results generated by the Verifier to enable Relying Parties (in 
> general, the remote peer) to make an informed decision about whether to put 
> trust in the trustworthiness of that Attester or not. In summary, an Attester 
> could be compromised in some way and RATS tries to inhibit that Attester to 
> lie about that.
> 
> There are a lot of benefits if an EAT (representing evidence) is a CWT:
> 
> * we avoid conflicting CWT claim index/label definitions in the IANA 
> registry, while being able to use the CWT world of claims (existing, 
> cnf soon, and such),
> * at first glance it seems simpler to use existing code that can 
> process CWT, and
> * EAT can simply inherit the well defined COSE signing conventions.
> 
> Alas, there is also a very specific drawback:
> 
> * sometimes RATS might not want to sign a token (maybe that does 
> render it not a token anymore, but rather a ticket. But that is just a 
> rather minor detail for now)
> 
> Why do RATS sometimes not require a signature around their CWT Claims Sets? 
> Because the surrounding secure channel between two entities with well 
> established authenticity and trustworthiness can be good enough to convey 
> useful CWT Claims Sets without a signature (emphasis on: in RATS).
> 
> Now - there are multiple options discussed in the RATS WG how to deal with 
> this:
> 
> 1.) go to COSE and ask for a "null signature",
> 
> [JLS] For suggesting this, you should have all of you security credentials 
> revoked.  The idea of deliberately introducing a way to take the security 
> value of COSE signatures to zero is something that should be staked like a 
> vampire and not allowed to continue.  I strongly believe that this is a fatal 
> flaw in the current JOSE security suite and have several times deliberated 
> writing a document to remove the "null signature" from JOSE.  While it is bad 
> to have signatures which are no longer adequately secure, having one with 
> zero security is just brain dead.
> 
> 2.) go to ACE and ask for an "unsigned token" option, or
> 
> [JLS] I don't have a problem with this, I am not sure that I see any reason 
> for it however.  See below.
> 
> 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are 
> not signed).
> [JLS] I don't see any difference between this and option #2
> 
> [JLS]
> 4.) Just write your CWT code in a sensible manner.
> 
> My CWT code base does not make any assumptions about the number or 
> order of COSE security wrapping layers on a token.  It thus looks like
> 
> while (true) {
>  if input has a COSE_Encrypt tag { decrypt it; set input to the content; 
> save the encryption information if needed e.g. 

Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

[Jim Schaad]

Henk,

Well you have definitely written a message designed to get a response from me.

-Original Message-
From: Ace  On Behalf Of Henk Birkholz
Sent: Wednesday, March 4, 2020 10:41 AM
To: r...@ietf.org; ace@ietf.org; c...@ietf.org
Subject: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be 
a CWT?

Hi RATS enthusiasts,
hi ACE,
hi CBOR,

in the RATS WG we had a lot of discussions about the nature of an Entity 
Attestation Token (EAT):

 > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/

 > https://github.com/ietf-rats-wg/eat/

A bit of (hopefully useful) context: an EAT is one way to convey believable 
evidence from an Attester (a role residing on a device-like
entity) to a Verifier (another role defined by RATS - the appraiser of 
evidence). All that is done to provide a Relying Party with "simple enough" 
attestation results generated by the Verifier to enable Relying Parties (in 
general, the remote peer) to make an informed decision about whether to put 
trust in the trustworthiness of that Attester or not. In summary, an Attester 
could be compromised in some way and RATS tries to inhibit that Attester to lie 
about that.

There are a lot of benefits if an EAT (representing evidence) is a CWT:

* we avoid conflicting CWT claim index/label definitions in the IANA registry, 
while being able to use the CWT world of claims (existing, cnf soon, and such),
* at first glance it seems simpler to use existing code that can process CWT, 
and
* EAT can simply inherit the well defined COSE signing conventions.

Alas, there is also a very specific drawback:

* sometimes RATS might not want to sign a token (maybe that does render it not 
a token anymore, but rather a ticket. But that is just a rather minor detail 
for now)

Why do RATS sometimes not require a signature around their CWT Claims Sets? 
Because the surrounding secure channel between two entities with well 
established authenticity and trustworthiness can be good enough to convey 
useful CWT Claims Sets without a signature (emphasis on: in RATS).

Now - there are multiple options discussed in the RATS WG how to deal with this:

1.) go to COSE and ask for a "null signature",

[JLS] For suggesting this, you should have all of you security credentials 
revoked.  The idea of deliberately introducing a way to take the security value 
of COSE signatures to zero is something that should be staked like a vampire 
and not allowed to continue.  I strongly believe that this is a fatal flaw in 
the current JOSE security suite and have several times deliberated writing a 
document to remove the "null signature" from JOSE.  While it is bad to have 
signatures which are no longer adequately secure, having one with zero security 
is just brain dead.

2.) go to ACE and ask for an "unsigned token" option, or

[JLS] I don't have a problem with this, I am not sure that I see any reason for 
it however.  See below.

3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are not 
signed).
[JLS] I don't see any difference between this and option #2

[JLS]
4.) Just write your CWT code in a sensible manner.  

My CWT code base does not make any assumptions about the number or order of 
COSE security wrapping layers on a token.  It thus looks like

while (true) {
if input has a COSE_Encrypt tag { decrypt it; set input to the content; 
save the encryption information if needed e.g. shared key authentication; 
continue; }
if input has a COSE_MAC tag { validate it; set input to the content; save 
the MAC information if needed e.g. shared key authentication; continue;}
if input has a COSE_Signature tag { validate it; set input to the content; 
save the signer information; continue }
if input is a map - return input as the set of claims;
throw an exception because it is not the correct format.
}

This does not require a tag for a naked set of claims and would allow that set 
of claims to be pass in the same place as a CWT can be passed.  What you are 
suggesting would require extra code to exist someplace that is going to check 
for an additional tag.  It is also going to lead to people thinking that this 
new tag should be legal to place inside of a CWT.  After all it makes more 
sense to always include it than to just sometimes include it.  This would be 
more of an issue if an array rather than a map was being used to carry the 
claims as there would be a chance to not know what type of security wrapper 
exists.

[JLS END]


At the last RATS virtual interim there was no certainty how to approach this. 
So this is a call out. COSE, ACE, and CBOR, how would you approach this 
"unsigned CWT Claims Set" requirement?

If one of the three options highlighted above is out of the question, please 
say so (and please elaborate on the why for the sake of helping the RATS WG 
understand why that is not a good idea).

If one of the three options looks like a low hanging fruit & viable, please say 
so (and... you know the dr

Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03

[Jim Schaad]

Hannes,

I am having a bit of an issue over the last paragraph below and I am not sure 
exactly where the boundary is supposed to be between OAuth and ACE anymore.  
From the comments that you made during the development of the ACE OAuth 
framework, there was a big effort to try and make sure that the framework can 
be used with JSON, and with HTTP.  I have implemented a version of the protocol 
that is using both JSON and HTTP in order to get the necessary POP keys for my 
MQTT client/server pair.   

That said, I also am planning to be on the call next Monday.

Jim


-Original Message-
From: Ace  On Behalf Of Hannes Tschofenig
Sent: Friday, February 28, 2020 12:59 AM
To: Cigdem Sengul 
Cc: ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03

Hi Cigdem,

Thanks for your quick response.

>From the text you cited regarding MQTT v5 it is not backwards compatible to 
>version 3.1.1. The exact impact of working between two devices of different 
>versions has not been described in the spec either. The follow sentence in 
>your introduction can easily give readers the impression that the two versions 
>are backwards compatible. Here is the sentence:

" It is expected that MQTT
   deployments will retain backward compatibility for MQTT v3.1.1
   clients, and therefore, this document also describes a reduced set of
   protocol interactions for MQTT v3.1.1 - the OASIS Standard
   [MQTT-OASIS-Standard].
"

Maybe you want to change the wording a little bit.  I think the reason why you 
want to describe a solution for v3.1.1 is that this is the widely deployed 
version.

Regarding the broker term: It is probably a matter of taste but I would refer 
to the terms used in the spec and would not replicate the terminology from the 
OASIS MQTT specs in the draft. Someone who implements the draft will have to 
become familiar with MQTT anyway. But that’s just me. For example, I often see 
people using the term “certificate authorities (CA)” in their write-ups. RFC 
5280 defines and uses the term “certification authority (CA)". While the two 
sound and look similar only one is actually correct.

I noticed you have put a normative dependency on 
[I-D.palombini-ace-coap-pubsub-profile]. I don't think it is necessary because 
it is not a requirement to implement the spec. You could use it on top of it -- 
or you could use something else as well. I would move it to the informative 
part. The added benefit of doing that is that you do not block your spec till 
that draft becomes RFC. On the other hand, RFC 6749, RFC 7800, and 
I-D.ietf-ace-cwt-proof-of-possession cannot be informative references when you 
use PoP tokens in your solution.

You might be interesting to hear that there is currently no way to obtain the 
keys for a PoP token over HTTP, which your solution requires. The virtual 
interim meeting in the OAuth group should probably be of interest to you.

Ciao
Hannes

From: Cigdem Sengul 
Sent: Tuesday, February 25, 2020 3:10 PM
To: Hannes Tschofenig 
Cc: ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03

Hello Hannes,

We used  broker as it is a widely accepted term in the MQTT Community for 
"server" e.g., majority of the provider would list also a broker implementation 
to refer to their server implementation.

With respect to whether 3.1,1 clients talking to v5, there may be some issues. 
This is what the spec says:

Non-normative Comment
If the Server distributes Application Messages to Clients at different protocol 
levels (such as MQTT V3.1.1) which do not support properties or other features 
provided by this specification, some information in the Application Message can 
be lost, and applications which depend on this information might not work 
correctly.

The spec also defines a protocol version error message:
If the [Client's] Protocol Version [in the CONNECT packet] is not 5 and the 
Server does not want to accept the CONNECT packet, the Server MAY send a 
CONNACK packet with Reason Code 0x84 (Unsupported Protocol Version) and then 
MUST close the Network Connection

So, whether a broker provides dual support would depend on the provider. E.g., 
the Mosquitto broker supports the different protocol versions.

Thanks,
--Cigdem

On Tue, Feb 25, 2020 at 10:01 AM Hannes Tschofenig 
 wrote:
Hi Cigdem, Hi Anthony, Hi Paul,

Why are you using the term MQTT broker? My understanding of the MQTT spec is 
that there are only clients and servers - nothing more.

Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT v3.1.1 
client talk to a MQTT v5 client via a server that supports both v3.1.1 and v5?

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.

Re: [Ace] Jim's Proposal on legal requestor

[Jim Schaad]

 

 

From: Ace  On Behalf Of Marco Tiloca
Sent: Wednesday, February 26, 2020 6:08 AM
To: Michael Richardson ; Jim Schaad 
; ace@ietf.org
Subject: Re: [Ace] Jim's Proposal on legal requestor

 

Hi!

Jim, I think now I understand your idea and it makes sense to me.

Some comments in line below.

Best,
/Marco

On 2020-02-26 14:17, Michael Richardson wrote:

 
clarifying question.
 
Jim Schaad  <mailto:i...@augustcellars.com>  wrote:
> I do not seem to have been doing a good job of explaining the issue
> that I am raising here, so I am going to go scenario based for a
> description.
 
> (1) I get an access token from an AS with a scope of [
> "coap://multicast-01", ["responder"]]
> (2) I join the group associated
> with that address
> (3) I then decide to send the message below out
> encrypted with the group symmetric key and signed with the public key I
> registered during the join
 
>GET coap://multicast-01/resource1
 
. (I numbered the steps)
I believe that (1) was intended to allow you to become a responder for this 
resource.


==>MT
Step (1) is intended to allow access to the group-membership resource at the 
Group Manager (GM), to get the keying material for communicating in the group.

Practically, the roles are currently used only at the GM to determine which 
public keys is relevant to return to a node upon its joining.
<==

[JLS] When implies that the only roles of interest are “monitor” vs not 
“monitor”.






 
 
> It then processes the get request
> because it does not know that this is a violation of the scope assigned
> to me by the AS.
 
!


==>MT
As above, the original idea for that scope was to have it applied to the group 
joining itself and the resource at the GM to access for joining.

But I agree that we should inform the other group members of that role, i.e. 
"allowed to send requests" and/or "allowed to send responses".
<==




 
 
> The only way that I know for the server TimeX to enforce the allowable
> operations is for that information to be propagated along with the
> signature public key from the KDC to the server.  


==>MT
This can be one more parameter in the Joining Response or in the Public Key 
Response, when request public keys of group members are included.

Together with the array of public keys, we can have a same-ordered array of 
roles echoing the roles from the scope of the Access Token above. Each element 
of the array can possibly be an array of roles.

How does it sound?
<==
[JLS] Yes this makes sense.  The only potential issue is what happens if the 
set of roles becomes in some sense unbounded for an application.  However, in 
that case I would expect that the list of roles would be known to the joining 
clients.  The one thing that comes up here is should there be a compression of 
these values since we are sending them to a larger group of people.



One can create a
> similar scenario on the other side where a client sends a response when
> it is only authorized as a "requester".


==>MT
Right, if it's "requester"-only.
<==




 
It seems to me that if the access control to the group is a group-shared
symmetric key + asymmetric signature, that each responder requires the list of 
valid signers.
Or, we need LAKE to turn the group key into 1:1.


==>MT
What I understand from Jim's proposal is essentially enabling at each group 
member a list of valid request signers and valid response signers.
<==


==>MT
Just to complement, this is all fine for this level of "filtering", i.e. "this 
group member can send requests/responses or not".

We have a separate draft at [1], defining a new Group OSCORE profile of ACE, to 
enforce access control within the group, i.e. to access group members' 
resources after having joined, i.e. as a group member towards another group 
member.

That is, that profile considers a granularity of exact REST methods and 
resources, i.e. as fine-grained as ACE can be. Also, it enables having together 
ACE-based access control and Group OSCORE, which is so far not possible with 
other profiles.

The current version -01 in the datatracker defines a "full mode" where both 
OSCORE and Group OSCORE are considered as security protocols between Client and 
RS. We plan to submit soon an updated version, focusing more on a lighter, 
intended-to-be main mode, that focuses on using only Group OSCORE as security 
protocol between Client and RS.

[1] https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01
<==

Best,
/Marco




 
 
--
Michael Richardson  <mailto:mcr+i...@sandelman.ca> , 
Sandelman Software Works
 -= IPv6 IoT consulting =-
 
 
 





___
Ace mailing list
Ace@ietf.org <mailto:Ace@ietf

Re: [Ace] Jim's Proposal on legal requestor

[Jim Schaad]

-Original Message-
From: Ace  On Behalf Of Michael Richardson
Sent: Wednesday, February 26, 2020 5:17 AM
To: Jim Schaad ; ace@ietf.org
Subject: Re: [Ace] Jim's Proposal on legal requestor


clarifying question.

Jim Schaad  wrote:
> I do not seem to have been doing a good job of explaining the issue
> that I am raising here, so I am going to go scenario based for a
> description.

> (1) I get an access token from an AS with a scope of [
> "coap://multicast-01", ["responder"]]
> (2) I join the group associated
> with that address
> (3) I then decide to send the message below out
> encrypted with the group symmetric key and signed with the public key
I
> registered during the join

>GET coap://multicast-01/resource1

. (I numbered the steps)
I believe that (1) was intended to allow you to become a responder for this
resource.


[JLS] Yes

> It then processes the get request
> because it does not know that this is a violation of the scope
assigned
> to me by the AS.

!

> The only way that I know for the server TimeX to enforce the allowable
> operations is for that information to be propagated along with the
> signature public key from the KDC to the server.  One can create a
> similar scenario on the other side where a client sends a response
when
> it is only authorized as a "requester".

It seems to me that if the access control to the group is a group-shared
symmetric key + asymmetric signature, that each responder requires the list
of valid signers.
Or, we need LAKE to turn the group key into 1:1.

[JLS] Having the list of valid signers in not in itself sufficient as both
requests and responses are going to be signed so you know who sent the
message and the fact that they are on the legal list.  Doing the turn the
group key into 1:1 doesn't work if you want to do a multicast request, as
that would end up being all unicast.

Jim


--
Michael Richardson , Sandelman Software Works  -=
IPv6 IoT consulting =-




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

[Ace] Minutes for todays interim posted

[Jim Schaad]

I have posted up the minutes for todays interim
https://datatracker.ietf.org/meeting/interim-2020-ace-04/materials/minutes-i
nterim-2020-ace-04-202002251100


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

[Ace] Jim's Proposal on legal requestor

[Jim Schaad]

I do not seem to have been doing a good job of explaining the issue that I
am raising here, so I am going to go scenario based for a description.

*  I get an access token from an AS with a scope of  [
"coap://multicast-01", ["responder"]]
*  I join the group associated with that address
*  I then decide to send the message below out encrypted with the group
symmetric key and signed with the public key I registered during the join

   GET coap://multicast-01/resource1

* The server TimeX receives the above message.  It starts to process the
message by checking the signature - that passes.  It then decrypts the
message and that succeeds.  It then processes the get request because it
does not know that this is a violation of the scope assigned to me by the
AS.

This will not happen for the MQTT profile as long as the AS (singular or
plural) are setup correctly as the MQTT broker would not allow the publish
operation to occur as it also has the set of operation permissions to
enforce.

The only way that I know for the server TimeX to enforce the allowable
operations is for that information to be propagated along with the signature
public key from the KDC to the server.  One can create a similar scenario on
the other side where a client sends a response when it is only authorized as
a "requester".  

Jim


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

Re: [Ace] Scope question

[Jim Schaad]

-Original Message-
From: Marco Tiloca  
Sent: Monday, February 24, 2020 2:14 PM
To: Jim Schaad ; 
draft-ietf-ace-key-groupcomm-osc...@ietf.org
Cc: 'Ace Wg' 
Subject: Re: Scope question

Hi Jim,

On 2020-02-24 19:02, Jim Schaad wrote:
> I was starting to code up the encoding of scope and wanted to clarify 
> what the encoding is.
>
> The text appears to say that the encoding is:
>
> scope = [ groupId: tstr, ?[* role : any ]]
>
> I was expecting this to be more along the lines of
>
> scope = [ + scope_item ]
> scopeItem = [ groupId: tstr, ?[* role : any ]]
>
> This would allow for more than one group to be identified in a single 
> token which I think is important given some of the statements about 
> only having a single token for a client.  This does not solve the 
> resource server having multiple audiences but that is fine.

==>MT
At the January interim, we mentioned a multi group/topic scope as next step. 
The format you suggest above is essentially the one we also had in mind. This 
should be firstly defined in the ace-key-groupcomm document.

This should be just fine for the Token request/response and the Access Token 
itself. Then I am thinking of what happens next. In a general case, in each of 
the specified groups a different signature algorithm
(etc.) is used.

Then, in the 2.01 response from /authz-info , we would have 'sign_info'
also as an array of arrays and 'pub_key_enc' as an array (unless the very same 
configuration applies for each scopeItem above). Same goes for 'rsnonce' 
becoming an array. The order of such arrays' elements is the same as for the 
scopeItems in the 'scope' claim.
<==

[JLS] I am having some problems with thinking that this is a good idea.  The 
only reason to have different signing keys is to keep the different signature 
keys isolated in terms of correlation.   If this is the case then adding a 
situation where we are going to share this information with a specific entity 
seems to be a bad idea.  I would think that if the signing keys are going to be 
separate then that should be true all of the back as far as possible.  This 
would mean that, if possible, that even the AS should not know that the 
different signing keys are associated with the same entity.

Jim


>
> I am unsure if it makes sense to allow for the array to be removed for 
> scope in the second example in the event that only one group is 
> specified.  One byte saved at the expense of more code.

==>MT
I think it makes sense to avoid that byte, and essentially revert to the 
original scope format when only one group is specified.
<==

Best,
/Marco

>
> Jim
>
>

--
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se



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

[Ace] Scope question

[Jim Schaad]

I was starting to code up the encoding of scope and wanted to clarify what
the encoding is.

The text appears to say that the encoding is:

scope = [ groupId: tstr, ?[* role : any ]]

I was expecting this to be more along the lines of

scope = [ + scope_item ]
scopeItem = [ groupId: tstr, ?[* role : any ]]  

This would allow for more than one group to be identified in a single token
which I think is important given some of the statements about only having a
single token for a client.  This does not solve the resource server having
multiple audiences but that is fine.

I am unsure if it makes sense to allow for the array to be removed for scope
in the second example in the event that only one group is specified.  One
byte saved at the expense of more code.

Jim


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

Re: [Ace] [EXTERNAL] RE: Access token question

[Jim Schaad]

I have found that I had to put a scope encoding format into my database for 
each audience definition.  Just saying that the scope is CBOR is not going to 
be sufficient, just like saying that it is a text string is not enough.

 

For the text string side you have:

*   It is a text string
*   It is a text string with space separated values
*   It is a text string with space separated values and each value has an 
underscore which separates operation and resource (MQTT)

 

On the binary side you have:

*   The proposal from Carsten that has not get adopted anywhere yet.
*   The group communication format (roughly based on the above format)

 

There is a question about how all of the binary values are going to work if you 
do a JSON encoded request rather than a CBOR encoded request.  At the moment, I 
am assuming that the binary value is encoded (in CBOR) and then base64url 
encoded and placed in the JSON.  I am not sure if people are going to want to 
define this as being native JSON instead depending on how the fields of the 
binary format are encoded.

 

Given all of this, I don’t know if adding something to the framework is going 
to be generally useful or not.  So much of what a scope looks like is going to 
be application dependent.  With any luck we are going to be able to get a good 
set of scope definitions at some point in the near future and can produce a 
survey document.  I am not holding my breath on this yet.

 

Jim

 

 

From: Francesca Palombini  
Sent: Sunday, February 23, 2020 11:55 PM
To: Mike Jones ; Jim Schaad 
; 'Seitz Ludwig' 
Cc: 'Ace Wg' 
Subject: Re: [EXTERNAL] RE: Access token question

 

Thanks all! Section 8.13 of the framework is exactly what I was looking for, I 
don’t know how I did not see it. A bit surprised there is no text referencing 
it in the framework itself.

 

Also, about the “scope” claim registration: the claim description and the 
specification document give 2 different pointers. The claim description ref 
points to the description for JWT (JSON string etc), I think this should be 
adapted to using CBOR (writing a section in the ACE framework, which could then 
reference both pointers). Also minor, I would add the precise section of 6749 
we should look at, which I assume is 3.3.

 

Francesca

 

From: Mike Jones mailto:michael.jo...@microsoft.com> >
Date: Friday, 21 February 2020 at 19:45
To: Jim Schaad mailto:i...@augustcellars.com> >, 
Francesca Palombini , 'Seitz Ludwig' 
mailto:ludwig.se...@combitech.se> >
Cc: Ace Wg mailto:ace@ietf.org> >
Subject: RE: [EXTERNAL] RE: Access token question

 

And https://tools.ietf.org/html/rfc8693#section-7.4, which registers “scope” at 
https://www.iana.org/assignments/jwt/jwt.xhtml.

 

        -- Mike

 

From: Jim Schaad mailto:i...@augustcellars.com> > 
Sent: Friday, February 21, 2020 9:15 AM
To: 'Francesca Palombini' mailto:francesca.palomb...@ericsson.com> >; 'Seitz Ludwig' 
mailto:ludwig.se...@combitech.se> >; Mike Jones 
mailto:michael.jo...@microsoft.com> >
Cc: 'Ace Wg' mailto:ace@ietf.org> >
Subject: [EXTERNAL] RE: Access token question

 

You are missing something

 

https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-8.13

 

defined here

 

From: Francesca Palombini mailto:francesca.palomb...@ericsson.com> > 
Sent: Friday, February 21, 2020 4:37 AM
To: Seitz Ludwig mailto:ludwig.se...@combitech.se> 
>; Mike Jones mailto:michael.jo...@microsoft.com> 
>; Jim Schaad mailto:i...@augustcellars.com> >
Cc: Ace Wg mailto:ace@ietf.org> >
Subject: Access token question

 

Hi,

 

Quick question regarding access token and scope. 

I know that “scope” semantics is left to the application to define, but in 
general I would expect to include there some information about resource and 
method/operations allowed on that resource. Please correct me if any of this is 
not exact.

 

It was my understanding that “scope” (or more precisely the “scope” value) 
defined for the Client-AS request and response should be included in the access 
token as well. Checking in CWT, there is no such “scope” claim defined. “aud” 
claim is indeed defined for the CWT, but that should correspond to “aud” 
parameter in the ACE request/response. So where do I put the exact resource and 
operations in the access token?

 

What am I missing?


Francesca

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

Re: [Ace] Access token question

[Jim Schaad]

You are missing something

 

https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-8.13

 

defined here

 

From: Francesca Palombini  
Sent: Friday, February 21, 2020 4:37 AM
To: Seitz Ludwig ; Mike Jones 
; Jim Schaad 
Cc: Ace Wg 
Subject: Access token question

 

Hi,

 

Quick question regarding access token and scope. 

I know that “scope” semantics is left to the application to define, but in 
general I would expect to include there some information about resource and 
method/operations allowed on that resource. Please correct me if any of this is 
not exact.

 

It was my understanding that “scope” (or more precisely the “scope” value) 
defined for the Client-AS request and response should be included in the access 
token as well. Checking in CWT, there is no such “scope” claim defined. “aud” 
claim is indeed defined for the CWT, but that should correspond to “aud” 
parameter in the ACE request/response. So where do I put the exact resource and 
operations in the access token?

 

What am I missing?


Francesca

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

Re: [Ace] draft-ietf-ace-key-groupcomm-oscore

[Jim Schaad]

-Original Message-
From: Marco Tiloca  
Sent: Friday, January 31, 2020 10:32 AM
To: Jim Schaad ; 
draft-ietf-ace-key-groupcomm-osc...@ietf.org
Cc: ace@ietf.org
Subject: Re: draft-ietf-ace-key-groupcomm-oscore

Hi Jim,

On 2020-01-31 16:46, Jim Schaad wrote:
>
> -Original Message-
> From: Marco Tiloca 
> Sent: Friday, January 31, 2020 3:24 AM
> To: Jim Schaad ; 
> draft-ietf-ace-key-groupcomm-osc...@ietf.org
> Cc: ace@ietf.org
> Subject: Re: draft-ietf-ace-key-groupcomm-oscore
>
> Hi Jim,
>
> Thanks for these comments!
>
> Please, find some replies below.
>
> Best,
> /Marco
>
> On 2020-01-31 00:16, Jim Schaad wrote:
>> This is not a finished review - but I wanted to get it out.
>>
>> Jim
>>
>>
>> General - Should the concept of a legal requester be part of the 
>> information that is transported with the public key?  I don't believe 
>> that this is currently done, but would additionally allow for a 
>> server to ignore comments from individuals who are not authorized for that 
>> role.
> 
> This can be indicated in the public key, and then the Group Manager indicates 
> this "role" to other group members, when providing them with the public key 
> of the legal requester.
>
> However, how can the Group Manager verify that a legal requester is indeed 
> one, as its public key claims? If we stick to raw public keys, this seems not 
> possible as the only thing that the Group Manager really does is verifying 
> possession of the corresponding private key upon joining.
>
> This would probably require certificates rather than public keys, as provided 
> in the 'client_cred' parameter upon joining, which is something that 
> ace-key-groupcomm is anyway admitting, while we are just not doing it here. 
> Then, it becomes about trusting the certificate issuer on legitimately 
> claiming that the certificate owner is indeed a legal requester.
> 
> [JLS] I was assuming that the GM could pull this information from the 'scope' 
> field of the token.


Ok, so it should be just about adding one more role to the current valid ones 
for 'scope', and updating the list of possible role combinations.

Then it's up to the policy evaluation at the AS to confirm that a client is 
indeed a legal requester, and that that ends up in the token.


[JLS]  I just realized we are not talking about the same problem.  I was 
thinking about propagating the difference between a publisher (client) and a 
responder (server) from the key server to the users of the keys.  This would 
mean that a server would be able to say - but this message is not authorized to 
ask me a question, so don't reply (or fail).


>
>> Section 2.2 - must new security parameters be regenerated on each 
>> membership change?
> 
> If the application really requires forward and backward security, yes.
> This is further discussed in the first security consideration of Section 14.
>
> Related, more general aspects about this are discussed in the security 
> considerations of ace-key-groupcomm. In particular, the Group Manager may 
> want to enforce a more relaxed policy than "on each membership change", 
> though making some compromise on the continuity of backward and forward 
> security.
> 
> [JLS] My problem is that I consider the secret key different from the 
> parameters - might be a semantic issue


Other than that, the ID Context (Group ID) is also renewed; the Master Salt may 
be renewed; the used Sender IDs have to remain the same.

Maybe we can have here some of the text on this from the first paragraph of
https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-06#section-2.1

[JLS] Perhaps we need to have some type of term for the difference between 
those items which are "static" over time and those items which are "dynamic" 
over time.  This might also be a difference in what is returned on the issue 
you raised today in the virtual.

Jim


>
>> Section 2.2. - Does completion of a group rekeying include confirmed 
>> redistribution before the version number is incremented?
> 
> I would say no, but regardless it's something to clarify, possibly already in 
> ace-key-groupcomm .
>
> Having the Group Manager generated and sent out the new keying material is 
> sufficient to also increment the version number.
>
> It is good that the Group Manager can also get confirmation of distribution, 
> mostly for possible individual re-provisioning, possibly up to a maximum 
> number of retries.
>
> Worst case, some group members remain behind, will not be able to retrieve a 
> context or decrypt correctly, and will eventually go to the Group Manager to 
> understand the current status, 

Re: [Ace] draft-ietf-ace-key-groupcomm-oscore

[Jim Schaad]

-Original Message-
From: Marco Tiloca  
Sent: Friday, January 31, 2020 3:24 AM
To: Jim Schaad ; 
draft-ietf-ace-key-groupcomm-osc...@ietf.org
Cc: ace@ietf.org
Subject: Re: draft-ietf-ace-key-groupcomm-oscore

Hi Jim,

Thanks for these comments!

Please, find some replies below.

Best,
/Marco

On 2020-01-31 00:16, Jim Schaad wrote:
> This is not a finished review - but I wanted to get it out.
>
> Jim
>
>
> General - Should the concept of a legal requester be part of the 
> information that is transported with the public key?  I don't believe 
> that this is currently done, but would additionally allow for a server 
> to ignore comments from individuals who are not authorized for that role.


This can be indicated in the public key, and then the Group Manager indicates 
this "role" to other group members, when providing them with the public key of 
the legal requester.

However, how can the Group Manager verify that a legal requester is indeed one, 
as its public key claims? If we stick to raw public keys, this seems not 
possible as the only thing that the Group Manager really does is verifying 
possession of the corresponding private key upon joining.

This would probably require certificates rather than public keys, as provided 
in the 'client_cred' parameter upon joining, which is something that 
ace-key-groupcomm is anyway admitting, while we are just not doing it here. 
Then, it becomes about trusting the certificate issuer on legitimately claiming 
that the certificate owner is indeed a legal requester.

[JLS] I was assuming that the GM could pull this information from the 'scope' 
field of the token.

>
> Section 2.2 - must new security parameters be regenerated on each 
> membership change?


If the application really requires forward and backward security, yes.
This is further discussed in the first security consideration of Section 14.

Related, more general aspects about this are discussed in the security 
considerations of ace-key-groupcomm. In particular, the Group Manager may want 
to enforce a more relaxed policy than "on each membership change", though 
making some compromise on the continuity of backward and forward security.

[JLS] My problem is that I consider the secret key different from the 
parameters - might be a semantic issue

>
> Section 2.2. - Does completion of a group rekeying include confirmed 
> redistribution before the version number is incremented?


I would say no, but regardless it's something to clarify, possibly already in 
ace-key-groupcomm .

Having the Group Manager generated and sent out the new keying material is 
sufficient to also increment the version number.

It is good that the Group Manager can also get confirmation of distribution, 
mostly for possible individual re-provisioning, possibly up to a maximum number 
of retries.

Worst case, some group members remain behind, will not be able to retrieve a 
context or decrypt correctly, and will eventually go to the Group Manager to 
understand the current status, including the latest version number, and get the 
latest group key material.

[JLS] This is how I read the text - please do some clarification

>
> Section 4.2.1 - I think that we are going to need a discussion on a 
> couple of issues related to the OSCORE half of how these values are 
> going to be created.  Pieces of the discussion are: 1. What is the POP 
> her going to try and prove.  Specifically is timeliness part of the 
> discussion.  2. What do we do about  token which grants access to 
> multiple topics.  Is joining the second group considered to be a 
> re-join rather than an original join for the purposes of this 
> discussion?  3.  What are the interactions about cached public keys, 
> when are these ok and how is this communicated to the client as a failure?


Sure. Some comments on your points for the discussion:

1. Ultimately the POP is about the owned private key used to sign by the 
joining node. Building this part of the challenge this way ties the challenge 
itself with the OSCORE context the two peers have. This is the same 
construction we have in [1] for building a signature challenge, so probably 
both documents would likely be affected.

2. Tokens covering multiple groups/topics are a next thing to define in 
ace-key-groupcomm. Adapting this challenge-based POP will follow. As a general 
case, the client wants to use different public keys in different groups, which 
would mean providing one POP signature for each key. Then, the N_S challenge 
can be as follows:

--- If the Access Token is posted to /authz-info , the RS returns an array of 
N_S, i.e. as many as the number X of groups/topics in the 'scope' of the token. 
Since the client may then upload Y < X public keys (some of which for more than 
one group), the client should include in the joining request Y signatures

Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08

[Jim Schaad]

-Original Message-
From: Ace  On Behalf Of Francesca Palombini
Sent: Wednesday, January 29, 2020 6:43 AM
To: Benjamin Kaduk ; draft-ietf-ace-oscore-prof...@ietf.org; Ace 
Wg 
Subject: Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08

Hi Ben,

Thank you so much for this very thorough and in-depth review! 

I have started a PR (https://github.com/ace-wg/ace-oscore-profile/pull/25 ) 
where I plan to include all the review comments. I have started with the 
editorial fixes, which I have collected in one issue: 
https://github.com/ace-wg/ace-oscore-profile/issues/24 

The details of answers and additional questions for clarification are inline, I 
also noted with "OK" the points where I agree with your suggestion and don't 
see any problem implementing in the PR. I will keep the numbering consistent in 
the mail thread and in the github to make sure everything is covered.

Additionally, you made a number of points I'd like to get wg opinion on:

* The mechanism of letting the RS pick the identifier of the client is not 
worth the additional complexity. So I propose we revert that, and go back to AS 
MUST pick the clientId, the clientId MUST be included in the token. This will 
only add some considerations about the scenario has several-AS-per-RS, in which 
case these AS need to be synchronized on clientIds they give out. (6., 21., 
61., 65.)

[JLS] For better or worse, this is not the only consideration.  The above 
statement presumes that only the AS is going to be assigning the client 
identifiers.  If the RS uses a different method of doing authentication as 
well, such as LAKE, then there is a chance for collisions at that point as well.

* Recommendation about length of nonces N1 and N2 to use. The wg agreed on 64 
bits, now Ben suggests to use 128 bits nonces. Reminder: these nonces are 
appended to the input salt to create the Master Salt, to run the HKDF and 
derive the keys. Also consider that OSCORE appendix B2 has a similar setting 
and does some considerations about that, mentioning that "typically nonces of 
at least 8 bytes will be used".

[JLS] I am agnostic on this, but I think that generally 64-bits from each side 
is sufficient.  This does add an additional 8 bytes of message size when 
sending the token to the server.  That worries me slightly.

* Define and register 2 new ACE parameters to transport the nonces used in the 
exchange, instead of using "cnonce". (see point 3., 53.)
* Define the nonces as bstr so that length value is encoded. (7.)
https://tools.ietf.org/html/rfc8613#page-72 
* Editorial: point 75.

Thanks again!
Francesca

On 07/01/2020, 17:40, "Ace on behalf of Benjamin Kaduk"  wrote:

Hi all,

Some high-level points before the section-by-section commentary:

1.I'm a little confused by the registry we are creating in Section 9.2.
While it's clear that we need something to specify the CBOR map key
labels to encode the structure for transit, it's not clear that we need
easy extensibility vs.  a fixed table.  A registry implies expectations
of future additions, but draft-ietf-core-object-security did not feel a
need to make a registry for future extensions; what has changed in the
past few months that makes extensibility needed now?  Why is this
document the right place to create the registry as opposed to that one?

FP: Why extensibility now: an example is the Group OSCORE profile, which 
extends this registry with fields that the OSCORE profile does not need, 
related to countersignatures (see 
https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#page-22 ). 
The difference between OSCORE (RFC8613) and this doc is that in OSCORE the 
security context is never sent on the wire, it is assumed to be 
pre-established, while here we needed to define a structure to send. Yes, we 
could avoid defining the registry and define all the fields (we can think of 
right now), including those for ace-key-groupcomm-oscore as a fixed table, but 
we thought this would be better, also considering that the OSCORE security 
context could get extended in a future version of OSCORE.

2.We are in some sense defining a new substructure within "kid" values (a
CBOR-encoded array of one or two elements) for usage by things using
this profile.  That's probably not problematic, as the "kid" can be an
arbitrary bstr and its interpretation is up to the recipient -- any
recipient that implements this profile will know to handle the
substructure, but it does feel a little unusual and perhaps worth an
early note.  (IIUC, we also need to be careful about actually providing
the bstr framing in our examples.)

FP: Ok, I will add an early note and also make sure the array is wrapped in a 
bstr. Do you have any opinion on where best to add this note? Kid appears first 
in 3.1, should we have it in the introductory section 3.? Or were you thinking 
even before?

3.I'm concerned about the usage of "

[Ace] draft-ietf-ace-key-groupcomm-oscore

[Jim Schaad]

This is not a finished review - but I wanted to get it out.

Jim


General - Should the concept of a legal requester be part of the information
that is transported with the public key?  I don't believe that this is
currently done, but would additionally allow for a server to ignore comments
from individuals who are not authorized for that role.

Section 2.2 - must new security parameters be regenerated on each membership
change?

Section 2.2. - Does completion of a group rekeying include confirmed
redistribution before the version number is incremented?

Section 4.2.1 - I think that we are going to need a discussion on a couple
of issues related to the OSCORE half of how these values are going to be
created.  Pieces of the discussion are: 1. What is the POP her going to try
and prove.  Specifically is timeliness part of the discussion.  2. What do
we do about  token which grants access to multiple topics.  Is joining the
second group considered to be a re-join rather than an original join for the
purposes of this discussion?  3.  What are the interactions about cached
public keys, when are these ok and how is this communicated to the client as
a failure?

Section 4.3 - Does it make sense to return a new rsnoce as part of these
errors?



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

[Ace] Review for draft-ietf-ace-key-groupcomm-04

[Jim Schaad]

This is not a finished review, but I wanted to get it out

Jim



Section 1 - last paragraph - the first sentence in this paragraph is giving
me fits trying to understand it.  I would suggest something, but I really
don't understand it.

General - Update the reference to RFC 7049 to the bis draft.

Section 3.1 - Should we try and harmonize the scope format here with either
the format in MQTT or with the one that Carsten once proposed.  The
multiplicity of scope formats is going to become a problem at some point.

Section 3.1 - It might make sense to move the contents of the last paragraph
of 'scope' up to the two points dealing with the elements.  I had a brief
moment where I thought REQ1 and REQ2 conflicting with the CBOR array.

Section 3.2 - I think the definition of 'exp' is incorrect.  Did you mean to
use 'exi'?

Section 3.2 - for scope - if the format is the same as in Section 3.1 - just
say that and omit the details.

Section 3.3 - Does REQ3 indicate that the profile is supposed to say that
the set of valid algorithms is defined or that a set of identifiers
different than that defined in the COSE Algorithm registry can be used.  An
example would be a text version of object identifiers.  My current reading
is that the latter is correct.

Section 3.3.3 - I don't think that you can return an rsnounce at this point.
There is nothing that ensures that one knows who the client is and thus one
cannot tie the nonce to any specific client.  Depending on what you are
trying to prove with the POP interaction this may not be provable with this.

Section 4.1 -  Now does one enforce the MUST NOT for the resource name of
/ace-group?

Section 4.1.2.1 - I think that this is the "join".  Using that word here
will clarify what is going on.

Section 4.1.2.1 - Once again - tell me why I care about scope in this
location.

Section  4.1 - I am not sure, but I think that I might want to suggest
putting a node in the path between guid and the node id for a single end
point.  That is /ace-group/gid/nodes/node.  This allows for one to not deal
with potential name collisions with the other nodes under gid.

Section 4.1.3.1 - Why can get_put_keys not be an empty array? Should this be
a bad request error if it is empty?

* - Should a client be able to ask for a previous set of keying material?
Consider the case of a client having key material n, missing update n+1 and
getting update n+2.  The client then gets a message encrypted to update n+1.
It never saw the material and thus cannot decrypt the message.

Section 4.3 - first para - another condition is if it discovers that new
keying material has been issued.  (Either as a message with a new epoch or a
notification from the server.)  While this is covered in the second
paragraph it is not clear that the client is going to stop using the key
material in that case.

Section 4.3 - para 3 - Is there a difference between not being able decrypt
because of decryption failure rather than on the basis of not having key
material to decrypt.  That is type of failure makes a difference

Section 4.4 - Policy can be that the KDC does a general rekey instead of
just doing an individual rekey

Section 6 - gkty does not match description - should be text string not byte
string





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

Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Jim Schaad]

I started doing testing of my code and I have started to run into some massive 
problems with the confirmation claim.The COSE version of the POP key 
registrations cause a problem because of the way the registration template in 
the document is written.  It currently says:

 

JWT Confirmation Method Name:

 

Claim Name of the equivalent JWT confirmation method value, as

registered in [IANA.JWT.Claims 
<https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-11#ref-IANA.JWT.Claims>
 ].  CWT claims should normally have

a corresponding JWT claim.  If a corresponding JWT claim would not

make sense, the Designated Experts can choose to accept

registrations for which the JWT Claim Name is listed as "N/A".

 

The issue here is the word “equivalent”.  There are two possible 
interpretations of this:  That this is a similar item in terms of how things 
are used, but there is no way to encode this item into a JWT.  Or, that this is 
how one should encode this item in a JWT.  The first interpretation implies 
that even though one would like to pass a COSE_Key confirmation in a JWT there 
is no way to do this.  (Yes, one can potentially convert the COSE Key into a 
JOSE Key but that is not always going to succeed as some keys in one system may 
not be representable in the other system.) The second interpretation says that 
you just encode the COSE_Key as JSON and put it into the map with the ”jwk” key 
and you are happy.  Which of course will not work.

 

I had misled myself in the message below as I had missed reading the JWT 
Confirmation Method Name field in the registration templates.   If you look at 
the text below, it is hard to know if “COSE_Key” is to be used in a JSON 
structure (which I had originally assumed) or if “jwk” is supposed to be used 
in a JSON structure.

 

   o  Confirmation Method Name: "COSE_Key"
   o  Confirmation Method Description: COSE_Key Representing Public Key
   o  JWT Confirmation Method Name: "jwk"
   o  Confirmation Key: 1
   o  Confirmation Value Type(s): COSE_Key structure
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.2 
<https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-11#section-3.2>
  of [[ this document ]]

 

At a minimum we should probably clarify the language on this.  And I need to 
look at the COSE documents and decode if there needs to be some text on 
encoding in a JSON environment or not.

 

Jim

 

 

From: Ace  On Behalf Of Jim Schaad
Sent: Sunday, January 19, 2020 3:35 PM
To: 'Brian Campbell' ; 'Seitz Ludwig' 

Cc: 'Roman Danyliw' ; oauth-ext-rev...@ietf.org; 'Daniel 
Migault' ; drafts-lastc...@iana.org; 'Ludwig 
Seitz' ; 'Benjamin Kaduk' ; ace@ietf.org
Subject: Re: [Ace] Requested review for IANA registration in 
draft-ietf-ace-oauth-params

 

I have managed to merge most of my code that deals with the confirmation claim 
and I have ended up with a single problem when dealing with confirmations.  If 
this is going to get fixed, it needs to get fixed in 
draft-ietf-ace-cwt-proof-of-possession prior to this document finishing 
processing the EDIT process in the RFC editor.

 

All of the items that can appear in a confirmation claim are unique except for 
the ‘kid’ claim method.  This field is defined as being a text field for JWT 
(RFC 7800), but it is defined as being a binary field for CWT.  It is a text 
field when defined in RFC 7800.  I do not anticipate any issues for the 
definition of a thumbprint as COSE is using a very different format for the 
definition of thumbprints which will led to a different naming convention.

 

Jim

 

 

 

From: Brian Campbell mailto:bcampb...@pingidentity.com> > 
Sent: Monday, January 13, 2020 10:01 AM
To: Seitz Ludwig mailto:ludwig.se...@combitech.se> >
Cc: Ludwig Seitz mailto:ludwig_se...@gmx.de> >; Roman 
Danyliw mailto:r...@cert.org> >; oauth-ext-rev...@ietf.org 
<mailto:oauth-ext-rev...@ietf.org> ; Daniel Migault 
mailto:daniel.miga...@ericsson.com> >; Jim Schaad 
mailto:i...@augustcellars.com> >; Benjamin Kaduk 
mailto:ka...@mit.edu> >; ace@ietf.org <mailto:ace@ietf.org> ; 
drafts-lastc...@iana.org <mailto:drafts-lastc...@iana.org> 
Subject: Re: [Ace] Requested review for IANA registration in 
draft-ietf-ace-oauth-params

 

Thanks Ludwig,

 

On Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig mailto:ludwig.se...@combitech.se> > wrote:

[snip] 

 

From: Ace mailto:ace-boun...@ietf.org> > On Behalf Of 
Brian Campbell

 

[snip]

   

So in -09 the "cnf" Introspection Response Parameter was the following the 
syntax of the "cnf" claim from PoP Key Semantics for CWTs 
[ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the syntax of 
PoP Key Semantics for JWTs [RFC7800] transitively via [I-D.ietf-oauth-mtls] 
reference. I think

Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Jim Schaad]

I have managed to merge most of my code that deals with the confirmation claim 
and I have ended up with a single problem when dealing with confirmations.  If 
this is going to get fixed, it needs to get fixed in 
draft-ietf-ace-cwt-proof-of-possession prior to this document finishing 
processing the EDIT process in the RFC editor.

 

All of the items that can appear in a confirmation claim are unique except for 
the ‘kid’ claim method.  This field is defined as being a text field for JWT 
(RFC 7800), but it is defined as being a binary field for CWT.  It is a text 
field when defined in RFC 7800.  I do not anticipate any issues for the 
definition of a thumbprint as COSE is using a very different format for the 
definition of thumbprints which will led to a different naming convention.

 

Jim

 

 

 

From: Brian Campbell  
Sent: Monday, January 13, 2020 10:01 AM
To: Seitz Ludwig 
Cc: Ludwig Seitz ; Roman Danyliw ; 
oauth-ext-rev...@ietf.org; Daniel Migault ; Jim 
Schaad ; Benjamin Kaduk ; ace@ietf.org; 
drafts-lastc...@iana.org
Subject: Re: [Ace] Requested review for IANA registration in 
draft-ietf-ace-oauth-params

 

Thanks Ludwig,

 

On Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig mailto:ludwig.se...@combitech.se> > wrote:

[snip] 

 

From: Ace mailto:ace-boun...@ietf.org> > On Behalf Of 
Brian Campbell

 

[snip]

   

So in -09 the "cnf" Introspection Response Parameter was the following the 
syntax of the "cnf" claim from PoP Key Semantics for CWTs 
[ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the syntax of 
PoP Key Semantics for JWTs [RFC7800] transitively via [I-D.ietf-oauth-mtls] 
reference. I think I understand that the two PoP key semantics documents are 
conceptually the same or similar. But I don't know that the syntax is the same? 
Figure 5 <https://tools.ietf.org/html/draft-ietf-ace-oauth-params-10#section-6> 
 is pointed to for mapping between CBOR and JSON but it only has mappings for 
the main top level parameters. Maybe I just don't get it or am missing 
something...   

 

[LS] No you are not missing something, I just got sloppy trying to do a 
quickfix.

 

Background: The reason for defining both JSON and CBOR-based interactions is 
that you might have a powerful client communicating with a constrained RS. The 
client does vanilla OAuth interactions with the AS via the token endpoint, but 
is served a CWT and associated ACE parameters (cnf, ace-profile, …) for 
interaction with the RS. 

The pop-key should decode to the same binary representation regardless of 
whether it came in a JSON or CBOR wrapper.

 

Okay, so noting that there is cnf content that doesn't decode to a key, I 
suppose I'll just take it on faith that all the relevant or expected usages 
involve a key that can be represented in both CBOR and JSON. 


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.

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

Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00

[Jim Schaad]

-Original Message-
From: Marco Tiloca  
Sent: Wednesday, January 15, 2020 9:21 AM
To: Jim Schaad ; 
draft-tiloca-ace-oscore-gm-ad...@ietf.org
Cc: ace@ietf.org
Subject: Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00

Hi Jim,

Thanks for your reply, see more comments inline.

Best,
/Marco

On 2020-01-12 03:38, Jim Schaad wrote:
>
> -Original Message-
> From: Ace  On Behalf Of Marco Tiloca
> Sent: Wednesday, January 8, 2020 8:08 AM
> To: Jim Schaad ; 
> draft-tiloca-ace-oscore-gm-ad...@ietf.org
> Cc: ace@ietf.org
> Subject: Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00
>
> Hi Jim,
>
> Thanks a lot for this review!
>
> We have been working on an updated version accessible at [1], which is 
> already taking into account your comments on CoRAL.
>
> Please, find below inline some more replies and open points.
>
> Best,
> /Marco
>
> [1]
> https://gitlab.com/crimson84/draft-tiloca-ace-oscore-gm-admin/blob/v-0
> 1/draft-tiloca-ace-oscore-gm-admin.md
>
> On 2019-11-20 00:13, Jim Schaad wrote:
>> This is just going to be a high level review on how things are done 
>> rather than a detailed review on each line of text.
>>


>> 4.  Are you making it a requirement that the group name be the same 
>> as the group identifier assigned by the "group_name" parameter?  If 
>> so then having some type of title and description would seem to be almost 
>> mandatory.
> 
> They are in fact the very same thing. The "group_name" parameter specifies 
> the group name, as intended to identify the OSCORE group both by the 
> administrator and the joining nodes in the other related documents. We can 
> use only "invariant name" rather than "invariant identifier". Are we missing 
> something? If so, what do you suggest we should give a title and description 
> to?
> 
>
> If you are looking at "group_name":"GP00123", then as a configuration agent 
> it is difficult to know just what this group is supposed to be.  In this case 
> some type of title or description helps to figure that out.


We can add a new group configuration parameter 'group_title', as a CBOR text 
string. This specifies a human-readable descriptive name of the group, 
suggesting what it is about.


[JLS] Sounds like a logical thing to do.

>
>> 5.  There needs to be some parameters around pointing to the correct 
>> AS and so forth.  The management API may reject because it does not trust 
>> the AS.
>> Don't assume that this is a single value for the AS either.
> 
> This is good and also aligned with other related drafts.
>
> If we interpret your suggestion correctly:
>
> 1) The POST request to /manage may specify also an optional 'as_uri'
> parameter, with the link to a suggested AS. The GM may accept the suggestion 
> or not. If not, it has to think of an alternative AS, as valid issuer of 
> tokens for joining that group.
>
> 2) The GM must have one more parameter in the group configuration with the 
> effective AS URI, i.e. either one provided by the administrator and accepted, 
> or one otherwise decided.
>
> Do you think of any additional related parameters to be included in the POST 
> request, other than 'as_uri'? Perhaps the public key of the suggested AS if 
> applicable?
>
> Do you think the suggestion in the request should actually be a list of AS, 
> out of which the GM may pick up at most one?
> 
>
> I have put something into draft-schaad-core-reef which starts thinking about 
> this.  I think that we need to sit down and do a brainstorming session to 
> figure out what items should/should not be put into such a structure.
>


With pleasure, and thanks for the pointer :-)

Out of my hat, I can think of: the URI of one AS and its /token endpoint; the 
profile(s) that the Group Manager have to use (if it supports them) for letting 
joining nodes enter the group; the public key of the AS if applicable; the ACE 
audience that the Group Manager has to use for this group.


[JLS]  One of the things that needs to be remembered is that this does not have 
to be flat, so there can be a clean separation between an AS and a GM.

>> 6.  You are missing a lot of management detail on the POST to the 
>> group node.  Some of the things that are missing would be:
>> a)  Is the group active or inactive
> 
> We can have one more parameter on the group-configuration resource for this.
>
> We are interpreting active/inactive as follows. Ideally, upon creating the 
> group, the request can specify the initial status as active or inactive. Upon 
> later updating the group by sending a request to the group-configuration 
> resource, the administrator c

Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope

[Jim Schaad]

 

 

From: Cigdem Sengul  
Sent: Wednesday, January 15, 2020 4:44 AM
To: Jim Schaad 
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 
Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription 
is in scope

 

Hello,

 


It gets interesting when the scope is more restricted than the subscription 
request. 

For instance, the scope is sport/+

But subscription is sport/#

 

Should this be refused? Obviously the subscriber is attempting to subscribe to 
more than it has permission for. But does the broker still allow the 
subscription but reduce it to "sport/+"? 

 

[JLS] Given that this is not defined in the base MQTT specification, most 
clients would not expect this if the ACE is grafted on the side of the program. 
 I would therefore say this is a “not authorized” and go on.

 

 

[CS] Agreed. Another issue that we should say something about is the case when 
multiple permission strings aggregated together gives enough permission to the 
subscription request, based on the _current_ topic hierarchy. 

Example:

Scope strings in the token were: publish_sport/tennis  publish_sport/basketball

and then the client asks for publish_sport/+

 

If tennis and basketball are the only topics under sport, then this is a valid 
request. 

But, if the topic hierarchy is changes during the connection time (adds 
sport/baseball) then subscriber gets PUBLISH messages for something they should 
not. 

When topic subscriptions are not protected, the broker would send anything at 
the single level for sport/+ and would not worry about the new additions after 
the subscription. 

 

When topic subscriptions are protected, the Broker can choose to do two things:

1) Allow the subscription but internally subscribe the clients to 
sport/basketball and sport/tennis only.

or

2) Reject the subscription and the client needs to ask for subscriptions that 
are a subset or equal to their permission strings. So the client specifically 
needs to ask for publish_sport/tennis and publish_sport/basketball matching its 
scope strings. But then scope parameter cannot be optional and must be included 
in the AS response. 

or

3) Allow the subscription, when a new level is added, check the permissions of 
all active subscribers, send DISCONNECT if the current permissions do not apply 
to the new hierarchy. 

 

1 would need to be again signalled to the client, 2 might be too restrictive, 
and 3 may introduce a processing load if things are changing all the time 
(which I do not expect). 

Leaning towards 3...  Any thoughts?

 

[JLS]  My first thought was to run and hide.  I think you have the scope 
strings setup wrong, they all should be “subscribe_” not “publish_” as a client 
is never going to ask to publish with a wildcard (MQTT-3.3.2-2). I would 
far prefer that the answer be 2 rather than 1 and I think that 3 is right out.

 

For 3 you are saying we are going to subscribe you, and then potentially 
disconnect you at a later time for something you never heard about.  I don’t 
really care about 1, only because there is no way to communicate this 
information back to the client that one is changing the set of subscriptions 
that was requested.  

 

I am not sure what you are requesting in terms of returning the scope 
parameter.  The current OAuth specification states that if the Authorization 
server returns a token that contains a different scope that the one requested 
by the client, then it is required to return the modified scope to the client.  
Is that what you are looking for.

 

Jim

 

 

--Cigdem

 

 

 

 

 

Jim

 

 

--Cigdem 


Jim


___
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] Review of draft-ietf-ace-mqtt-tls-profile-03

[Jim Schaad]

 

 

From: Cigdem Sengul  
Sent: Tuesday, January 14, 2020 8:25 AM
To: Jim Schaad 
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03

 

Thank you for this review, Jim. 

Responses inline. 

 

On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad mailto:i...@augustcellars.com> > wrote:






2.2.2 - I am unclear under what circumstances you could end put with a token
which does not parse when processing a PUBLISH message.  If the token cannot
be parsed at connection time, that I can understand.  However having parsed
the token then it does not make sense that the token becomes not parsable at
the time of publishing.  Am I missing something?

 

[CS] There is a misunderstanding. The PUBLISH message refers to the actual 
PUBLISH message to the "authz-info" topic which contains the token i.e., this 
may not parse to a token. (The PUBLISH message is not for other messages that 
are permissioned in the token.)

The client connects (without much security), publishes the token to the public 
"authz-info" topic, which only the broker can read. 

Then, disconnects, and tries to connect with ace security. 

 

Since MQTT v5 can return error messages in response to PUBLISH messages, here, 
this is used to signal to the publisher that there is something wrong with its 
token. 

 

Added: https://github.com/ace-wg/mqtt-tls-profile/issues/38

 

[JLS] Ok – I see where I got mixed in in reading this.  I think this may just 
be a problem on my end and you might not be able to do this better.

 

 

 


2.2.4 - I am having a problem with trying to parse the content of the AUTH
property.  I have no problems with 2.2.4.3 because this is a zero length
sequence of bytes.  However for 2.2.4.1 and 2.2.4.2 there is a token
(possibly binary with no length prefix) followed by an optional binary
cryptographic value.  For introspection, I would need to figure out the
length of the token before I could make a guess at the length of the
cryptographic value.  However given that there is no divider this does not
seem possible.  This may also become a problem for the response from the
client in the event that there is a change from an 8-byte nonce to a
variable length one.

 

[CS] Not specified a  format, because I  thought we discarded the idea of using 
the variable-length nonce based on the meeting in Singapore. 

What would you suggest - introduce a specific format to accommodate variable 
length?

length_of_token+binary data for token+(the rest is cryptographic value)?

 https://github.com/ace-wg/mqtt-tls-profile/issues/40

 

[JLS] I put in a comment on the github issue about what I was looking for.  
Additionally,  my only possible problem with the fixed size nonce is that the 
IESG or Security Directorate down the line may decide that it is too small for 
some reason (16 bytes signed by a 521-bit (65+ byte key)).  Some might consider 
it to be small for a SHA-256 MAC operation.  Not the exact same situation here 
for TLS as it is not really a compact protocol.  But it may considered to be 
for the IoT variants being used.  I don’t know.

 

 

Jim

 


I am going to play with something else.  I am sure I will find other issues
at a different time.

 

Thank you for your review. Much appreciated. 

--Cigdem 

 


Jim














Nits:
Section 2 Para 1 s/Broker.Figure 1/Broker.  Figure 1/
Section 2 Para 1  s/setup.The/setup.  The/
Section 2.2.2 Last Para s/when the AS/when the RS/


___
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] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope

[Jim Schaad]

 

 

From: Cigdem Sengul  
Sent: Tuesday, January 14, 2020 6:24 AM
To: Jim Schaad 
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 
Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription 
is in scope

 

Hello Jim,

 

Topic filter and permission filter matching is something that I would like to 
have a better resolution as well. 

Responses inline. 

On Mon, Jan 13, 2020 at 1:38 AM Jim Schaad mailto:i...@augustcellars.com> > wrote:

I have run across an interesting question for doing validation of
subscriptions that I would like to get an opinion on.

When doing a publish, there is not an issue.  One simply takes the set of
values in the scope field as topic filters and checks the publication topic
against the set of permissible publication topic filters in the scope.

 

[CS] Yes. 

 


When doing a subscribe, there are four distinct cases that can arise:
1.  The subscription is for a single topic and either is or is not
successfully matched against the scope topic filter.

 

[CS] Yes. 

 

2.  The subscription is for a topic filter and it is identical to the scope
topic filter.

 

[CS] Yes. 

3.  Both are topic filters and are not the same.  Is one supposed to do some
type of subset matching on the two filters or does one always say that this
is not a match.  This is not addressed in the MQTT document and I am not
sure where it would be addressed.   As an example:

Scope value is subscribe_sport/#
Subscription topic is sport/tennis/#

The second is clearly a subset of the first and thus it would seem logical
to include it, but it gets more complicated if one instead asks for

Subscription topic is sport/+

In this case the two wild cards are not the same value.

 

We were thinking using a subset matching to check whether the token would 
permit the subscription request. 

For your example, a subscription request 

"sport/+" would cover all the single-levels under "sport" - including "sport/" 
but not "sport" . 

So if the scope is "subscribe_sport/#" which covers all multi-levels under 
"sport" (including "sport", the subscription request should still succeed. 
(i.e., the subscriber has a larger set of permissions than the request)

 

Now when the broker receives a publication with "sport/tennis" then it should 
pass this message on to the subscriber. 

When it receives a publication "sport/tennis/player1" then it should not. This 
would be normal broker behaviour as well (without using ace). 

 

[JLS] This is what I expected the answer to be, I will need to figure out what 
this algorithm looks like now for all of the corner cases.

 

It gets interesting when the scope is more restricted than the subscription 
request. 

For instance, the scope is sport/+

But subscription is sport/#

 

Should this be refused? Obviously the subscriber is attempting to subscribe to 
more than it has permission for. But does the broker still allow the 
subscription but reduce it to "sport/+"?

Currently would opt for the former, because the second option may be hard to 
signal to the subscriber - the SUBACK reason string together with the user 
property field may be used for such feedback to the subscriber but would need 
to be defined properly.

 

[JLS] Given that this is not defined in the base MQTT specification, most 
clients would not expect this if the ACE is grafted on the side of the program. 
 I would therefore say this is a “not authorized” and go on.

 

Jim

 

 

--Cigdem 


Jim


___
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] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Jim Schaad]

Brian,

 

If it does not work then I should know by the end of next week.  I am trying to 
merge my JWT and CWT token issuing code in my ACE OAuth server right now.

 

Jim

 

 

From: Brian Campbell  
Sent: Monday, January 13, 2020 10:01 AM
To: Seitz Ludwig 
Cc: Ludwig Seitz ; Roman Danyliw ; 
oauth-ext-rev...@ietf.org; Daniel Migault ; Jim 
Schaad ; Benjamin Kaduk ; ace@ietf.org; 
drafts-lastc...@iana.org
Subject: Re: [Ace] Requested review for IANA registration in 
draft-ietf-ace-oauth-params

 

Thanks Ludwig,

 

On Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig mailto:ludwig.se...@combitech.se> > wrote:

[snip] 

 

From: Ace mailto:ace-boun...@ietf.org> > On Behalf Of 
Brian Campbell

 

[snip]

   

So in -09 the "cnf" Introspection Response Parameter was the following the 
syntax of the "cnf" claim from PoP Key Semantics for CWTs 
[ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the syntax of 
PoP Key Semantics for JWTs [RFC7800] transitively via [I-D.ietf-oauth-mtls] 
reference. I think I understand that the two PoP key semantics documents are 
conceptually the same or similar. But I don't know that the syntax is the same? 
Figure 5 <https://tools.ietf.org/html/draft-ietf-ace-oauth-params-10#section-6> 
 is pointed to for mapping between CBOR and JSON but it only has mappings for 
the main top level parameters. Maybe I just don't get it or am missing 
something...   

 

[LS] No you are not missing something, I just got sloppy trying to do a 
quickfix.

 

Background: The reason for defining both JSON and CBOR-based interactions is 
that you might have a powerful client communicating with a constrained RS. The 
client does vanilla OAuth interactions with the AS via the token endpoint, but 
is served a CWT and associated ACE parameters (cnf, ace-profile, …) for 
interaction with the RS. 

The pop-key should decode to the same binary representation regardless of 
whether it came in a JSON or CBOR wrapper.

 

Okay, so noting that there is cnf content that doesn't decode to a key, I 
suppose I'll just take it on faith that all the relevant or expected usages 
involve a key that can be represented in both CBOR and JSON. 


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.

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

[Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope

[Jim Schaad]

I have run across an interesting question for doing validation of
subscriptions that I would like to get an opinion on.

When doing a publish, there is not an issue.  One simply takes the set of
values in the scope field as topic filters and checks the publication topic
against the set of permissible publication topic filters in the scope.

When doing a subscribe, there are four distinct cases that can arise:
1.  The subscription is for a single topic and either is or is not
successfully matched against the scope topic filter.
2.  The subscription is for a topic filter and it is identical to the scope
topic filter.
3.  Both are topic filters and are not the same.  Is one supposed to do some
type of subset matching on the two filters or does one always say that this
is not a match.  This is not addressed in the MQTT document and I am not
sure where it would be addressed.   As an example:

Scope value is subscribe_sport/#
Subscription topic is sport/tennis/#

The second is clearly a subset of the first and thus it would seem logical
to include it, but it gets more complicated if one instead asks for

Subscription topic is sport/+

In this case the two wild cards are not the same value.

Jim


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

Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00

[Jim Schaad]

-Original Message-
From: Ace  On Behalf Of Marco Tiloca
Sent: Wednesday, January 8, 2020 8:08 AM
To: Jim Schaad ; 
draft-tiloca-ace-oscore-gm-ad...@ietf.org
Cc: ace@ietf.org
Subject: Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00

Hi Jim,

Thanks a lot for this review!

We have been working on an updated version accessible at [1], which is already 
taking into account your comments on CoRAL.

Please, find below inline some more replies and open points.

Best,
/Marco

[1]
https://gitlab.com/crimson84/draft-tiloca-ace-oscore-gm-admin/blob/v-01/draft-tiloca-ace-oscore-gm-admin.md

On 2019-11-20 00:13, Jim Schaad wrote:
> This is just going to be a high level review on how things are done 
> rather than a detailed review on each line of text.
>
> 1. - Go and read that CoRE Pub-Sub update document - you know the one 
> that Klaus and friends have not managed to get written since the model 
> proposal was done way back when.


Yes, we are now relying on an akin interface, along the lines of the now 
published draft 
https://datatracker.ietf.org/doc/draft-hartke-t2trg-coral-pubsub/


>
> 2.  Re-write this to use CoRAL - Yes I know that this makes another 
> dependency on getting it published from the CoRE group, but I don't 
> want to do things multiple times.


We have now also added examples in CoRAL, for all the interactions between 
Administrator and Group Manager, now also extended with FETCH for filtered 
retrieval.


>
> 3.  I think that this document really needs to be able to be used with
> HTTP/JSON as well as CoAP.   If you can get the JSON version of CoRAL from
> Klaus then this falls out without any work.


We are now saying the CoRAL examples are in text format, but they are in CBOR 
or JSON on the wire, with no particular additional effort. Is this enough?


Sounds good.

>
> 4.  Are you making it a requirement that the group name be the same as 
> the group identifier assigned by the "group_name" parameter?  If so 
> then having some type of title and description would seem to be almost 
> mandatory.


They are in fact the very same thing. The "group_name" parameter specifies the 
group name, as intended to identify the OSCORE group both by the administrator 
and the joining nodes in the other related documents. We can use only 
"invariant name" rather than "invariant identifier". Are we missing something? 
If so, what do you suggest we should give a title and description to?


If you are looking at "group_name":"GP00123", then as a configuration agent it 
is difficult to know just what this group is supposed to be.  In this case some 
type of title or description helps to figure that out.

>
> 5.  There needs to be some parameters around pointing to the correct 
> AS and so forth.  The management API may reject because it does not trust the 
> AS.
> Don't assume that this is a single value for the AS either.


This is good and also aligned with other related drafts.

If we interpret your suggestion correctly:

1) The POST request to /manage may specify also an optional 'as_uri'
parameter, with the link to a suggested AS. The GM may accept the suggestion or 
not. If not, it has to think of an alternative AS, as valid issuer of tokens 
for joining that group.

2) The GM must have one more parameter in the group configuration with the 
effective AS URI, i.e. either one provided by the administrator and accepted, 
or one otherwise decided.

Do you think of any additional related parameters to be included in the POST 
request, other than 'as_uri'? Perhaps the public key of the suggested AS if 
applicable?

Do you think the suggestion in the request should actually be a list of AS, out 
of which the GM may pick up at most one?


I have put something into draft-schaad-core-reef which starts thinking about 
this.  I think that we need to sit down and do a brainstorming session to 
figure out what items should/should not be put into such a structure.

>
> 6.  You are missing a lot of management detail on the POST to the 
> group node.  Some of the things that are missing would be:
> a)  Is the group active or inactive


We can have one more parameter on the group-configuration resource for this.

We are interpreting active/inactive as follows. Ideally, upon creating the 
group, the request can specify the initial status as active or inactive. Upon 
later updating the group by sending a request to the group-configuration 
resource, the administrator can change the status (or read it through a GET).

Then the active/inactive status has two parallel scopes:

1) one scope is for the GM alone, i.e the GM would allow the joining of new 
group members only if the group is set as active.

2) when the group is set as inactive, the current group members should refrain 
from sending and should not expect receiving any mes

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

-Original Message-
From: Benjamin Kaduk  
Sent: Thursday, January 9, 2020 1:22 PM
To: Jim Schaad 
Cc: 'Olaf Bergmann' ;
draft-ietf-ace-dtls-authorize@ietf.org; ace@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

On Thu, Jan 09, 2020 at 12:52:56PM -0800, Jim Schaad wrote:
> 
> 
> -Original Message-
> From: Benjamin Kaduk 
> Sent: Thursday, January 9, 2020 12:17 PM
> To: Olaf Bergmann 
> Cc: Jim Schaad ; ace@ietf.org; 
> draft-ietf-ace-dtls-authorize@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> 
> On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote:
> > Hi Jim,
> > 
> > Jim Schaad  writes:
> > 
> > > -Original Message-
> > > From: Ace  On Behalf Of Olaf Bergmann
> > > Sent: Monday, January 6, 2020 2:03 AM
> > > To: Jim Schaad 
> > > Cc: ace@ietf.org; 'Benjamin Kaduk' ; 
> > > draft-ietf-ace-dtls-authorize@ietf.org
> > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> > >
> > > Jim,
> > >
> > > Jim Schaad  writes:
> > >
> > > [Ben's review]
> > >> We also are potentially in violation of the framework's 
> > >> requirements
> with respect to the independent selection of profiles for client/AS 
> and client/RS interactions -- at present, when DTLS+RPK is used for 
> client/RS, we require that DTLS+RPK is also used for client/AS, in 
> order to prove possession of the key.  We could perhaps weasel our way 
> out by saying that the framework's requirement applies at the profile 
> granularity, and with symmetric PSK we can be fully independent, but 
> we still need to say something about this property and the interaction 
> with the framework's requirements.
> > >>
> > >> [JLS] I am missing where it is saying this.   Can you give a pointer?
> I don't believe that the POP of the RPK is required at the time that 
> the token is obtained.
> > >
> > > The problem is that AS must bind the Access Token to the RPK that 
> > > the
> Client has presented, and the Client must use the very same RPK to 
> establish the DTLS channel with RS. Otherwise, RS cannot be sure that 
> AS has issued the Token to the same entity that is currently communicating
with RS.
> > >
> > > [JLS]  What if I do the following sequence of events:
> > > 1.  The AS is configured with RPK1 for the client and the client 
> > > is
> configured with RPK2 for the AS.
> > > 2.  The client and the AS run some type of POP algorithm, not 
> > > currently
> specified, to configure RPK3 into the AS for a second RPK to work with 
> some set of audiences (AUD1).
> > > 3.  The client then uses RPK1 to authenticate to the AS and asks 
> > > for a
> new token for AUD1 and provides (explicitly or implicitly RPK3).  The 
> AS knows that it is tied to the client due to what happened in step 2.  
> The AS then creates a new token for AUD1 which contains RPK3 for the 
> client (and
> RPK4 for the RS) and returns it.
> > >
> > > The AS does a current POP for RPK1 when the token is being asked for.
> > > The AS did a POP for RPK3 when it was placed into the system.
> > > The AS has not done a POP for RPK4 - that was simply configured 
> > > without
> that step ever being done.  The ACE framework has no ability for the 
> AS to do the POP on RPK4 and ensure that it current.  The client would 
> do a POP when the TLS session is created but has to rely on the AS 
> that it is for the correct RS.
> > >
> > > Note that the client can never generate a brand new RPK9 and send 
> > > it to
> the AS in the token request because the AS will never have seen this 
> before and would need to run the POP algorithm of step 2 in order to 
> assure that it is bound to the correct client and not pulled out of 
> thin air.  RPK9 could not be used to authenticate the token request 
> because the AS has no idea what client it is tied to.
> > 
> > okay, I see you have a valid point here. I will try to come up with 
> > some text that says that the AS must ensure that (in your scenario)
> > RPK1 and
> > RPK3 are bound to the same entity.
> 
> Jim's proposal seems broadly reasonable (though I think in general 
> there needs to be some AS contributory nature in order to get proof of 
> current possession of RPK3 at the time of (2).  I think I would phrase 
> it as "in possession of the same entity" rather than "bound to the 
> same entity", though.
> 
> [JLS] If I w

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

-Original Message-
From: Benjamin Kaduk  
Sent: Thursday, January 9, 2020 12:27 PM
To: Jim Schaad 
Cc: draft-ietf-ace-dtls-authorize@ietf.org; ace@ietf.org
Subject: Re: AD review of draft-ietf-ace-dtls-authorize-09

On Fri, Jan 03, 2020 at 08:36:54PM -0800, Jim Schaad wrote:
> 
> 
> -Original Message-
> From: Benjamin Kaduk 
> Sent: Thursday, January 2, 2020 3:40 PM
> To: draft-ietf-ace-dtls-authorize@ietf.org
> Cc: ace@ietf.org
> Subject: AD review of draft-ietf-ace-dtls-authorize-09
> 
> Hi all,
> 
> Some high-level remarks before delving into the section-by-section
> comments:
> 
> This document is pretty clearly DTLS 1.2-specific -- it talks about 
> particular protocol messages, message fields, and cipher suites that simply 
> do not apply to DTLS 1.3.  In order to use this profile with DTLS 1.3, we'd 
> need to specify the analogous behavior/requirements to these (including 
> standalone signature schemes and key-exchange groups, which are now both 
> separately negotiated from the cipher suite).
> Given that DTLS 1.3 is past WGLC and only a few documents behind this one in 
> my review queue, it seems fairly prudent to spend some time and cover how 
> DTLS 1.3 would work here, since otherwise this document will become stale 
> shortly after (or even before!) its publication as an RFC.
> 
> [JLS] Yes we need to look at this, but we also know who's fault this is 😉  
> Part of me wants to punt this off to the CoRE working group because the way 
> they are currently using DTLS 1.2 is quite restrictive and they really need 
> to do a DTLS 1.3 document.

I hadn't realized that the CoRE usage of DTLS was so restrictive; in that case 
we may have to wait for them, yes.

[JLS] Yeah, I really ought to start writing this document.   The first time I 
read the DTLS section and realized that when a re-key operation occurred that 
all of the current state on the server is to be cleared as if a new session had 
just been negotiated I just about went crazy.  They were worried about the 
security implications on the key roll over which made no sense to me, but then 
I am much more versed in TLS than they were.

> 
> There's probably some additional discussion to include about the usage of key 
> identifiers in this document versus the potential uses described in the core 
> framework.  Specifically, the framework reminds us that "no assumptions 
> should be made that it is unique in the domains of either the client or the 
> RS" yet this document is using the kid as input to a KDF that produces keys 
> that must be unique across all clients, and allowing live/instant 
> authorization updates based on matching "kid".
> How shall we resolve this apparent conflict?
> 
> [JLS] I am having a problem seeing what the conflict is here.  The "kid" is a 
> publicly known value so that fact that it is included in the KDF is not what 
> is going to produce unique keys for all clients no matter what.  It is the 
> secret that is going to make things unique.  There is a potential problem 
> with the fact that the RS may get two different entities that register a 
> token which has the same kid value, but that is a known issue for (D)TLS.  
> This is one of the reasons that the token itself can be used as the "kid" for 
> DTLS.

I think I'm just thinking about what you note as the "potential problem"
where an RS receives two tokens with the same kid value but that are for 
different clients.  For asymmetric PoP we require POST to authz-info, and since 
"POST a new token with the same kid" is the way we update permissions without 
changing DTLS keys, the RS needs to know to scope its lookup/storage based on 
(client,kid) (or more?) and not just 'kid'.  Maybe this is obvious, but I 
wasn't sure.

[JLS] No, "POST a new token with the same KEY" is the way that we update 
permissions without changing the DTLS keys.  For RPK this is easy.  For 
symmetric keys this is a harder sell and you really need to add some additional 
checks to make it something along the lines of same .  There may not 
be a key id if one is using the token as the user identifier when doing the 
DTLS protocol so matching on kid would seem to be difficult there.  What I was 
referring to as the potential problem is that if client 1 posts a token with a 
symmetric key and KID1 and uses KID1 as the user name things are fine.  Now if 
client 2 posts a token with a different symmetric key and KID1.  Client 2 can 
use KID1 as the user name to connect to the server but if client 1 attempts to 
connect with KID1 as the user name it will fail doing the connection.  This is 
a (D)TLS issue as you cannot do  a "retry" easily in TLS 1.2.  (Ding, ding, 
ding, ding.   Jim just realizes tha

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

-Original Message-
From: Benjamin Kaduk  
Sent: Thursday, January 9, 2020 12:17 PM
To: Olaf Bergmann 
Cc: Jim Schaad ; ace@ietf.org;
draft-ietf-ace-dtls-authorize@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote:
> Hi Jim,
> 
> Jim Schaad  writes:
> 
> > -Original Message-
> > From: Ace  On Behalf Of Olaf Bergmann
> > Sent: Monday, January 6, 2020 2:03 AM
> > To: Jim Schaad 
> > Cc: ace@ietf.org; 'Benjamin Kaduk' ; 
> > draft-ietf-ace-dtls-authorize@ietf.org
> > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> >
> > Jim,
> >
> > Jim Schaad  writes:
> >
> > [Ben's review]
> >> We also are potentially in violation of the framework's requirements
with respect to the independent selection of profiles for client/AS and
client/RS interactions -- at present, when DTLS+RPK is used for client/RS,
we require that DTLS+RPK is also used for client/AS, in order to prove
possession of the key.  We could perhaps weasel our way out by saying that
the framework's requirement applies at the profile granularity, and with
symmetric PSK we can be fully independent, but we still need to say
something about this property and the interaction with the framework's
requirements.
> >>
> >> [JLS] I am missing where it is saying this.   Can you give a pointer?
I don't believe that the POP of the RPK is required at the time that the
token is obtained.
> >
> > The problem is that AS must bind the Access Token to the RPK that the
Client has presented, and the Client must use the very same RPK to establish
the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued
the Token to the same entity that is currently communicating with RS.
> >
> > [JLS]  What if I do the following sequence of events:
> > 1.  The AS is configured with RPK1 for the client and the client is
configured with RPK2 for the AS.
> > 2.  The client and the AS run some type of POP algorithm, not currently
specified, to configure RPK3 into the AS for a second RPK to work with some
set of audiences (AUD1).
> > 3.  The client then uses RPK1 to authenticate to the AS and asks for a
new token for AUD1 and provides (explicitly or implicitly RPK3).  The AS
knows that it is tied to the client due to what happened in step 2.  The AS
then creates a new token for AUD1 which contains RPK3 for the client (and
RPK4 for the RS) and returns it.
> >
> > The AS does a current POP for RPK1 when the token is being asked for.
> > The AS did a POP for RPK3 when it was placed into the system.
> > The AS has not done a POP for RPK4 - that was simply configured without
that step ever being done.  The ACE framework has no ability for the AS to
do the POP on RPK4 and ensure that it current.  The client would do a POP
when the TLS session is created but has to rely on the AS that it is for the
correct RS.
> >
> > Note that the client can never generate a brand new RPK9 and send it to
the AS in the token request because the AS will never have seen this before
and would need to run the POP algorithm of step 2 in order to assure that it
is bound to the correct client and not pulled out of thin air.  RPK9 could
not be used to authenticate the token request because the AS has no idea
what client it is tied to.
> 
> okay, I see you have a valid point here. I will try to come up with 
> some text that says that the AS must ensure that (in your scenario) 
> RPK1 and
> RPK3 are bound to the same entity.

Jim's proposal seems broadly reasonable (though I think in general there
needs to be some AS contributory nature in order to get proof of current
possession of RPK3 at the time of (2).  I think I would phrase it as "in
possession of the same entity" rather than "bound to the same entity",
though.

[JLS] If I was to write this out as a real protocol, it would end up
something along the lines of  Sign(RPK1, Sign(RPK3,  RPK1 || RPK3 || AS
Nonce || Client Nonce ))  so that we know that both keys are in the
possession of a single entity (or a cabal collaborating) and it is current
to the run of the POP protocol.

Jim


-Ben

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

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

-Original Message-
From: Ace  On Behalf Of Olaf Bergmann
Sent: Monday, January 6, 2020 2:03 AM
To: Jim Schaad 
Cc: ace@ietf.org; 'Benjamin Kaduk' ; 
draft-ietf-ace-dtls-authorize@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

Jim,

Jim Schaad  writes:

[Ben's review]
> We also are potentially in violation of the framework's requirements with 
> respect to the independent selection of profiles for client/AS and client/RS 
> interactions -- at present, when DTLS+RPK is used for client/RS, we require 
> that DTLS+RPK is also used for client/AS, in order to prove possession of the 
> key.  We could perhaps weasel our way out by saying that the framework's 
> requirement applies at the profile granularity, and with symmetric PSK we can 
> be fully independent, but we still need to say something about this property 
> and the interaction with the framework's requirements.
>
> [JLS] I am missing where it is saying this.   Can you give a pointer?  I 
> don't believe that the POP of the RPK is required at the time that the token 
> is obtained.

The problem is that AS must bind the Access Token to the RPK that the Client 
has presented, and the Client must use the very same RPK to establish the DTLS 
channel with RS. Otherwise, RS cannot be sure that AS has issued the Token to 
the same entity that is currently communicating with RS.

[JLS]  What if I do the following sequence of events:
1.  The AS is configured with RPK1 for the client and the client is configured 
with RPK2 for the AS.
2.  The client and the AS run some type of POP algorithm, not currently 
specified, to configure RPK3 into the AS for a second RPK to work with some set 
of audiences (AUD1).
3.  The client then uses RPK1 to authenticate to the AS and asks for a new 
token for AUD1 and provides (explicitly or implicitly RPK3).  The AS knows that 
it is tied to the client due to what happened in step 2.  The AS then creates a 
new token for AUD1 which contains RPK3 for the client (and RPK4 for the RS) and 
returns it.

The AS does a current POP for RPK1 when the token is being asked for.
The AS did a POP for RPK3 when it was placed into the system.
The AS has not done a POP for RPK4 - that was simply configured without that 
step ever being done.  The ACE framework has no ability for the AS to do the 
POP on RPK4 and ensure that it current.  The client would do a POP when the TLS 
session is created but has to rely on the AS that it is for the correct RS.

Note that the client can never generate a brand new RPK9 and send it to the AS 
in the token request because the AS will never have seen this before and would 
need to run the POP algorithm of step 2 in order to assure that it is bound to 
the correct client and not pulled out of thin air.  RPK9 could not be used to 
authenticate the token request because the AS has no idea what client it is 
tied to.

Jim


Jim
 

Grüße
Olaf

___
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] AD review of draft-ietf-ace-dtls-authorize-09

[Jim Schaad]

-Original Message-
From: Benjamin Kaduk  
Sent: Thursday, January 2, 2020 3:40 PM
To: draft-ietf-ace-dtls-authorize@ietf.org
Cc: ace@ietf.org
Subject: AD review of draft-ietf-ace-dtls-authorize-09

Hi all,

Some high-level remarks before delving into the section-by-section
comments:

This document is pretty clearly DTLS 1.2-specific -- it talks about particular 
protocol messages, message fields, and cipher suites that simply do not apply 
to DTLS 1.3.  In order to use this profile with DTLS 1.3, we'd need to specify 
the analogous behavior/requirements to these (including standalone signature 
schemes and key-exchange groups, which are now both separately negotiated from 
the cipher suite).
Given that DTLS 1.3 is past WGLC and only a few documents behind this one in my 
review queue, it seems fairly prudent to spend some time and cover how DTLS 1.3 
would work here, since otherwise this document will become stale shortly after 
(or even before!) its publication as an RFC.

[JLS] Yes we need to look at this, but we also know who's fault this is 😉  Part 
of me wants to punt this off to the CoRE working group because the way they are 
currently using DTLS 1.2 is quite restrictive and they really need to do a DTLS 
1.3 document.

There's probably some additional discussion to include about the usage of key 
identifiers in this document versus the potential uses described in the core 
framework.  Specifically, the framework reminds us that "no assumptions should 
be made that it is unique in the domains of either the client or the RS" yet 
this document is using the kid as input to a KDF that produces keys that must 
be unique across all clients, and allowing live/instant authorization updates 
based on matching "kid".
How shall we resolve this apparent conflict?

[JLS] I am having a problem seeing what the conflict is here.  The "kid" is a 
publicly known value so that fact that it is included in the KDF is not what is 
going to produce unique keys for all clients no matter what.  It is the secret 
that is going to make things unique.  There is a potential problem with the 
fact that the RS may get two different entities that register a token which has 
the same kid value, but that is a known issue for (D)TLS.  This is one of the 
reasons that the token itself can be used as the "kid" for DTLS.

We also are potentially in violation of the framework's requirements with 
respect to the independent selection of profiles for client/AS and client/RS 
interactions -- at present, when DTLS+RPK is used for client/RS, we require 
that DTLS+RPK is also used for client/AS, in order to prove possession of the 
key.  We could perhaps weasel our way out by saying that the framework's 
requirement applies at the profile granularity, and with symmetric PSK we can 
be fully independent, but we still need to say something about this property 
and the interaction with the framework's requirements.

[JLS] I am missing where it is saying this.   Can you give a pointer?  I don't 
believe that the POP of the RPK is required at the time that the token is 
obtained.

This profile is mostly applicable to the client/RS communications and feels 
like it only provides some of the picture for use with client/AS interactions.  
(It doesn't really say much of anything about RS/AS
interactions.) The introductory discussion does not do a great job of painting 
that picture, and I'd like to see it more clearly introduced that the bulk of 
our coverage is for the client/RS interaction.  We also lean heavily on the 
existing out-of-band configuration and key material shared between client and 
AS to secure the client/AS communications; we could probably tighten up the 
discussion about exactly what parameters of client/AS communication are 
specified by this profile.

[JLS] I think this makes sense.

We do not say anything about DTLS session resumption (or renegotiation, though 
not talking about that one is perfectly fine); that's a fairly core DTLS 
concept that we should give some guidance on.

[JLS] I don't see any reason to talk about renegotiation, either it is done or 
it isn't and a new connection would need to be created.  I am not sure what to 
say about session resumption.   This is something that really needs to be dealt 
with in the CoRE working group before anything can be said here.  Session 
resumption would only resume the TLS session, but any CoRE state above it is 
not going to be restored because it is defined as going away in RFC 7252.  This 
is currently also true for doing a renegotiation.

Looking through Appendix C ("Requirements on Profiles") of the framework, do we 
want to say anything about:

- using the client credentials grant with this profile, as that's IIRC
  the only example we show
- require that DTLS be used in a mode that provides replay protection
- when the client uses the authz-info endpoint instead of the
  "psk_identity" field to convey the token to the RS, how does the RS
  know which cli

[Ace] Review of draft-ietf-ace-mqtt-tls-profile-03

[Jim Schaad]

2.2.2 - para 1, the last sentence seems to imply that the first connection
to publish to authz-info is not being done over a TLS connection.  But the
sentence before that states that a TLS connection MUST be used for this.
Perhaps s/and is expected to try reconnecting over TLS./and reconnects,
potentially using client authentication with TLS./

2.2.2 - I am unclear under what circumstances you could end put with a token
which does not parse when processing a PUBLISH message.  If the token cannot
be parsed at connection time, that I can understand.  However having parsed
the token then it does not make sense that the token becomes not parsable at
the time of publishing.  Am I missing something?

2.2.2 - The last paragraph is causing me confusion.  Is this supposed to be
referencing the RS or the AS?  If it is the AS, then I don't see how there
could be any confusion.  Please expand this so it is clearer.

2.2.4 - I am having a problem with trying to parse the content of the AUTH
property.  I have no problems with 2.2.4.3 because this is a zero length
sequence of bytes.  However for 2.2.4.1 and 2.2.4.2 there is a token
(possibly binary with no length prefix) followed by an optional binary
cryptographic value.  For introspection, I would need to figure out the
length of the token before I could make a guess at the length of the
cryptographic value.  However given that there is no divider this does not
seem possible.  This may also become a problem for the response from the
client in the event that there is a change from an 8-byte nonce to a
variable length one.

2.2.4.1 - In my view it is not the secret, but the content that is being
obtained from the TLS exporter.  That is one is signing (or MACing) the
exporter value not using that value to compute a MAC on something else.
While it is true that only the two parties know that value, exposure to a
third party does not lead to a compromise.

2.2.4.3 - I am not sure if the text is supposed to require an empty
authentication data field or to allow for the authentication data field to
be absent as well.

3 - It might be worth while to put a pointer to section 4.7 of the MQTT V5
spec here so that there is an indication of what the different wild card
characters do.  I had to pop over there to make sure that I could figure it
out.

3.1 - Should you state that for a QoS of 0, the client should close the
connection w/ an '0x87' in the event of an authorization failure?  I think
that this is supposed to happen but you have left it open.

6 - It is not clear to me if the authentication method described in this
section is permitted with MQTT v5 or not.  It does not say, but it appears
to be a true statement.  This should probably be explicit.

2.2.4.3 - What is the name of the user property that is being returned here?


I am going to play with something else.  I am sure I will find other issues
at a different time.

Jim














Nits:
Section 2 Para 1 s/Broker.Figure 1/Broker.  Figure 1/
Section 2 Para 1  s/setup.The/setup.  The/
Section 2.2.2 Last Para s/when the AS/when the RS/


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

Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06

[Jim Schaad]

 

 

From: Ace  On Behalf Of Seitz Ludwig
Sent: Sunday, December 22, 2019 11:52 PM
To: 'elwynd' ; Ludwig Seitz ; Elwyn 
Davies ; gen-...@ietf.org
Cc: last-c...@ietf.org; draft-ietf-ace-oauth-params@ietf.org; ace@ietf.org
Subject: Re: [Ace] [Gen-art] Genart last call review of 
draft-ietf-ace-oauth-params-06

 

Hello Elwyn,

 

Sorry for being a pain. I have one more comment.

 

/Ludwig (now finally from the corporate account)

 

From: elwynd mailto:elw...@folly.org.uk> > 
Sent: den 22 december 2019 19:27
To: Ludwig Seitz mailto:ludwig_se...@gmx.de> >; Elwyn 
Davies mailto:elw...@dial.pipex.com> >; 
gen-...@ietf.org  
Cc: last-c...@ietf.org  ; 
draft-ietf-ace-oauth-params@ietf.org 
 ; ace@ietf.org 
 
Subject: Re: [Gen-art] [Ace] Genart last call review of 
draft-ietf-ace-oauth-params-06

 

Hi, Ludwig.

 

Having had another look at section 3.1 of 
draft-ietf-ace-cwt-proof-of-possession, technically the rules about which keys 
have to be present are not part of the syntax of the cnf claim.  The point can 
be covered by changing '"syntax of the 'cnf' claim"

to "syntax and semantics of the 'cnf' claim"

in each case.

 

[LS] Ok. Will do.

 

However, the second look threw up another point:  Figure 2 in s3.2 gives a 
Symetric key example  - I think this should use an Encrypted_COSE_Key (or 
Encrypted_COSE_Key0) as described in section 3.3 of 
draft-ietf-ace-cwt-proof-of-possession.

 

[LS] Figure 2 in 3.2 gives an example of a AS response to a client requesting 
an access token. As per the requirements from draft-ietf-ace-oauth-authz, this 
communication MUST be confidentiality protected, therefore it is unnecessary to 
additionally encrypt the COSE_Key. 

The provisions in 3.3 of draft-ietf-ace-cwt-proof-of-possession are for access 
tokens in CWT format, containing a symmetric key, that are not encrypted 
themselves (i.e. only MAC:ed or signed).

 

[JLS] I tend to agree with not doing the encryption in the example.  The 
encryption is not required as protection could be done elsewhere and having an 
example that people can read increases the usability of the example.

 

Jim

 

 

Otherwise I think we are done.

 

Eventually we will get to Christmas!  

 

[LS] I promise to leave it be over the holidays.

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

Re: [Ace] FW: [IANA #1157486] Last Call: (Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)) to Proposed

[Jim Schaad]

Personal opinion,

I think that we should be requesting a separate page.  I think we are going to 
have enough different registries that keeping them separate from OAuth is going 
to be useful in preventing confusion.  For the mapping registries, it might be 
useful to see if IANA can give us a link from the mapping registry to the OAuth 
registry.

Jim


-Original Message-
From: Ludwig Seitz  
Sent: Saturday, December 21, 2019 3:26 AM
To: Jim Schaad ; 'Daniel Migault' 

Cc: ace@ietf.org; Benjamin Kaduk ; 'Roman Danyliw' 

Subject: Re: FW: [IANA #1157486] Last Call:  
(Authentication and Authorization for Constrained Environments (ACE) using the 
OAuth 2.0 Framework (ACE-OAuth)) to Proposed Standard

> From: Sabrina Tanamal via RT 
> Subject: [IANA #1157486] Last Call: 
>  (Authentication and Authorization 
> for Constrained Environments (ACE) using the OAuth 2.0 Framework 
> (ACE-OAuth)) to Proposed Standard
>
> (BEGIN IANA COMMENTS)
>
> IESG/Authors/WG Chairs:
>
> The IANA Functions Operator has completed its review of 
> draft-ietf-ace-oauth-authz-27. If any part of this review is inaccurate, 
> please let us know.
>
> The IANA Functions Operator has a question about one of the actions requested 
> in the IANA Considerations section of this document.
>
> The IANA Functions Operator understands that, upon approval of this document, 
> there are fifteen actions which we must complete.
>
> NOTE: We’re asking the ADs how to handle the registrations for which Hannes 
> is the only reviewer.
>
> IANA Question --> Several sections of the current draft propose to create new 
> registries (Sections 8.1, 8.3, 8.4, 8.6, 8.7, 8.9, and 8.11). For each of 
> these requests, IANA asks the authors where the new registries are to be 
> located. Should they be added to an existing registry page? If not, do they 
> belong in an existing category at http://www.iana.org/protocols? For each of 
> the new registries, it is not clear from the context of the request where the 
> new registries should be established.
>
Hello WG chairs (WG and ADs in cc),

I am in need of some guidance here due to my lack of experience in IANA matters.

Do we want to establish a new protocol page for ACE in the IANA registries?

Alternatively we could add them to the OAuth pages under a specific ACE section.

Regards,
Ludwig

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

Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

[Jim Schaad]

A couple of comments below.  See [JLS]

-Original Message-
From: Roman Danyliw via Datatracker  
Sent: Monday, December 16, 2019 2:02 PM
To: The IESG 
Cc: draft-ietf-ace-coap-...@ietf.org; Jim Schaad ; 
ace-cha...@ietf.org; i...@augustcellars.com; ace@ietf.org
Subject: Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with 
COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-ace-coap-est-17: 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-coap-est/



--
COMMENT:
--

* Section 4.  Per “the DTLS connections SHOULD only be kept alive for EST 
messages that are relatively close to each other”, I think the text means that 
some EST messages are more likely to occur one after another.  It would be 
worth being clearer what these would be.

* Section 5.1. Per “These URIs are shorter than the ones in [RFC7030]”, does 
Table 1 imply that when using EST-coaps the “longer names” from RFC7030 
wouldn’t be valid?
[JLS] This is being addressed via Alexey's discuss I think.

* Section 5.2  Per “The latter ones are deemed to expensive …”, was difficult 
to parse as the sentence prior has three things (instead of two).  Is this 
sentence referring to the “not specified functions” only?

* Section 5.3, Per “30% smaller payload for DER-encoded ASN.1”, if you can cite 
this metric, please do.
[JLS] Do you really need a metric on the difference between the size of raw 
binary vs base6 encoded binary?  It is just 3 bytes vs 4 bytes (i.e  4/3)

* Section 5.8.  Per “In summary, the symmetrically encrypted key is included in 
the encryptedKey attribute in a KEKRecipientInfo structure”, if this is done in 
a server-side key generation scenario, where is the client getting the key to 
decrypt the server computed key material?  Should the DecryptKeyIdentifier/ 
AsymmetricDecryptKeyIdentifier attributes be populated in the CSR per Sections
4.4.1.1/4.4.1.2 of RFC7030?
[JLS] That would be the discussion of these attributes in paragraph 3 (about 
the middle)?  Or are you looking for something more?

* Section 10.1.  Per “When server-side key generation is used, the constrained 
device depends on the server to generate the private key randomly, but it still 
needs locally generated random numbers for use in security protocols, as 
explained in Section 12 of [RFC7925].”, is the “security protocols” referenced 
here anything beyond DTLS?

* Section 10.1.  Per “In such occasions, checking the certificate revocation 
status or authorizing the client using another method is important for the 
server to ensure that the client is to be trusted.”

-- does this text suggest that expired+revoked certificates should not be used?
[JLS] Yes, a revoked certificate would most likely not be used.  However, my 
personal expectation is that this would map more directly to a database 
associated with the CA as it is possible that the manufacturer could have gone 
under and not be doing CRLs in any event.

Jim Schaad

-- to word-smith:
s/for the server to ensure that the client is to be trusted/for the server to 
raise its confidence that the client can be trusted/

* Section 10.1.  Per “More information about recommendations of TLS and DTLS
are included in   [BCP195]”, thanks for referencing BCP195.  Could you please
clarify with normative language if these recommendations SHOULD/MUST be 
followed?

* Editorial
- Section 4.  Per “Authenticating and negotiating DTLS keys requires resources 
on low- end endpoints and consumes valuable bandwidth”, I’m not sure this 
sentence is needed.  Technically, “authenticating and negotiating DTLS keys 
requires resources” on any endpoint.

- Section 4.
OLD: Given that after a successful enrollment, it is more likely that a new EST 
transaction will take place after a significant amount of time, NEW: Given that 
after a successful enrollment, it is more likely that a new EST transaction 
will not take place for a significant amount of time,

- Section 5.5. Typo.  s/successfull/successful/

- Section 5.8.  s/Such scenarios could be when it is …/Such scenarios apply 
when it is …/

- Section 5.8.  s/ client, or when the resources/client, when the resources/

- Section 5.8. s/Then the private key/The private key/



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