Re: [Ace] draft-ietf-ace-key-groupcomm review

[Jim Schaad <[e-mail]>]

This is most of them.

 

Jim

 

 

From: Francesca Palombini <[e-mail]> 
Sent: Monday, May 27, 2019 4:43 AM
To: Jim Schaad <[e-mail]>
Cc: Ace <[e-mail]>; [e-mail]
Subject: draft-ietf-ace-key-groupcomm review

 

Hi Jim,

 

Thank you so much for the in depth review. Apologies for the delay, we have had several meetings and back and forth between authors and have finally gone through your comments, and that took a while longer than expected. We have combined below all the mails regarding ace-key-groupcomm, so to keep the discussion in one single thread.

 

For some of the comments, we’d like to get more input from you, while for others we have pointed out the proposal to fix the issue. For the latter, we mark them with AP and we’ll start implementing them in the document, if you don’t object.

 

------------------------

Security Model and other issues for group messaging - 09/04/2019

 

I need to look at this more closely – will respond later

 

I have been going through the design process for getting software running

for Montreal and I have come across the following issues that I think need

some discussion. Some of these may just need clarification in documents but

other are more substantive.

 

It took me a while to determine that one of the strange issues I was having

is that when looking just at the multicast case my mental model of who was

making the decisions on if access was allowed did not seem to make a good

match to what was being documented.

 

I rather expected that all of the ACL

decisions were going to be made on the AS and none on the KDC.

 

This is correct. The model for the ace-key-groupcomm (and consequently ace-key-groupcomm-oscore and ace-coap-pubsub) is that the AS does all of the ACL and KDC does the key distribution.

 

This meant

that the inclusion of scope in all of the messages was redundant if sending

messages to a per group resource.

 

You are correct, scope is indeed redundant in some messages, for example in the Key Distribution Request, as it is present in the token. (See point 12 below)

 

Part of the questions involved here are

who does the configuration for what key groups are associated with what

application groups.

 

I was always thinking of a single key group which was

identified by the AS and sent to the KDC without the KDC needing to know the

details of multiple resources for that key group. This of course does not

match the model in the document. Some text on what model is being laid out

is probably worthwhile.

 

We’d like clarifications here: why do you say that this does not match the current model? That was the objective anyway.

 

There was discussions for the ACE OAuth document about how to handle

multiple access tokens for a single entity that need to be looked at in the

context of a KDC. The current rule is that a resource server needs only to

keep one token for any single supplicant. This was mostly discussed in the

context of adding and subtracting privileges for the supplicant. It may be

that this also needs to be viewed in the context of having completely

disjoint resources on a single RS which are going to have different AS

tokens issued.

 

Thus for example, if there is a KDC which is servicing two

different key groups. The supplicant gets a token for group1, gets the keys

from the KDC. It then asks for a token for group2. Given that the

lifetimes of these different tokens could be radically different does it

really make sense to require that the two AS tokens be merged together

(assuming they are from the same source) or would it make more sense to

relax the RS only needs to keep one token rule. An easy way out of this

might be to say one token per resource, but for constrained devices it could

be one token per RS.

 

We agree with relaxing the “one token per RS per client”. The requirement makes sense when one RS is associated with one AS, but in our case the KDC could be associated with several AS for different scopes.  <https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-24#section-5.1> draft-ietf-ace-oauth-authz-24#section-5.1

says "... the AS in charge of a resource hosted at the RS ..."  So this is a more general problem, as it is allowed in the ACE framework to have multiple ASs covering different resources/scopes at a same RS. We think this requirement should be relaxed in the general case, as merging tokens from different ASs would definitely be a problem. We’d like to raise this issue to the ACE framework authors and get feedback from the WG.

 

Jim

 

------------------------

 

draft-ietf-ace-key-groupcomm - 03/04/2019 03:00

 

I read this document on the flight back with the idea of thinking about

doing an implementation.  In the process I found that it does not seem to be

ready to start on an implementation.

 

Just a note: no, this document is not written to be implemented on its own, but paired with one of the dependent documents, such as ace-key-groupcomm-oscore and ace-coap-pubsub, which give the details that are missing (a bit like framework and profiles).

 

1.  This document is written explicitly in terms of using CBOR as the

encoding format.  Should it be written such that either JSON or CBOR can be

used for the underlying encoding?  While I personally don't care, it may be

that either Hannes or the MQTT authors might find this to be something that

would be useful.

 

We haven’t noticed interest from the WG, but if there is we can definitely define it more generally. For now we will anyway add some note to say that using JSON is possible (conversion specified in Sections 4.1 and 4.2 of RFC 7049) (AP1)

[JLS] That makes sense to me.

2.  Is there a content type that is planned for the messages used in this

document?  If the plan was to use application/ace+cbor then this both needs

to be stated and should be cleared with the group in general.  If there is

no plan to create one then it would be useful to state this.

 

Where ACE is used (3 first messages), the content-format used is the one defined in ACE (application/ace+cbor and possibly application/cwt). In the last 2 messages (Key distribution Request and Response) the content-format is supposed to be application/cbor, as that is the type of the payload: we will explicitly add that. (AP2)

[JLS] Looks good

3.  The document does not have a table which deals with abbreviations, does

this mean that the full text string is what is going to be the key?

Depending on the content type being considered, these values could be

assigned (new registry) or marked as TBD, but if this is supposed to happen

then it needs to be placed in the document.

 

Yes, we need to do this. We will create a new registry for them, and re-use the same number as ACE as much as possible (for parameters that appear in both, such as ‘profile’, ‘exp’) (AP3)

[JLS] Sounds reasonable.  I am currently building a spreadsheet with some of this date and will forward it to you.

4.  Should the references to RFC 7390 be replaced with the new document

being considered for the CoRE working group?

 

Yes, hoping that it moves forward quickly. For now we can mention both. (AP4)

[JLS] Sounds good.

5.   Section 2 - In the last paragraph - should the word "further" be

omitted as there did not seem to be any previous communications discussed.

 

Yes, remains of copy-paste. (AP5)

[JLS] Sounds good.

6.  Section 3.1 - Is there a reason why one cannot request access from the

AS for multiple groups/topics in the same request to the AS? 'scope'

 

This was the case in a previous version of the document. We got feedback that this was too complicated and not a hot need. We can reconsider if more people in the WG want this.

[JLS] I can understand this reaction.  You might also look at the MQTT document which is allowing for this and see if alignment is needed.

7.  Section 3.1 - Is there a definition of the values for "role" that can be

requested.  What is the type of this field for a single value, or for

elements of the array?  Is there a default if role is omitted on the

request?

 

There is no definition in this doc for specific admitted values, that is defined on the additional instances (ace-key-groupcomm-oscore, ace-coap-pubsub). Roles are specific to the applications, so it makes little sense to specify them in general. The default value, if any, would also be defined in the instances. What we will do is to clarify this in the text. Moreover, this will be part of the “Mandatory to define” (see point 39). (AP6)

[JLS] I will need to think about this.  It may make things hard on the AS depending on how it is designed.

8.  Section 3.2 - IN the last paragraph did you mean to say that a new token

would be returned or that the existing token can be returned.

 

That a new token would be returned. How can we clarify?

[JLS] The string “can simply replay with” is what messed me up.  Better would be “the AS replies with an Authorization Response with a new access token.”  The use of “can” is not the same as “will”.

9.  Section 4.1 - If the 'client_cred' field in a request is filled in, and

it is not the same as the public key used to establish the TLS session

between the client and the KDC, what is the procedure to do a POP on this

key?

 

In the specific case you describe, an easy solution would be to require the client to use the same key in ‘client_cred’ and to establish the TLS session, and that would solve the POP. But we do have the open point on POP for the public key in the general case. Until now, we kept that out of the scope of this and dependent documents (see section 8 of ace-key-groupcomm-oscore), but we are looking to include it.

 

One possibility we are considering is to sign the key distribution request together with a nonce that was sent from the KDC (for the sake of freshness),  using the private key paired to the public key sent in ‘client_cred’. Do you have feedback about this?

[JLS] that would be a reasonable solution.  You could potentially also use a TLS exporter value as that would be channel bound.

 

10.  Section 4.1 - What is the data structure for client_cred?

 

We will add that: we propose CBOR bstr. That is the most general format, if for example  COSE_Keys are used, they can be wrapped in a bstr. (AP7)

[JLS] That should work.

11. Section 4.1 - For 'pub_keys_repos' what is the format of this field?

 

We will add that as CBOR array of tstr containing URIs. (AP8)

[JLS] Looks good.

 

12. Section 4.2 - I am not completely sure that I understand what

verification checking means in the first paragraph.

 

The KDC verifies that the ‘scope’ received in the Key Distribution Request is the same as ‘scope’ stored in the access token associated to this client. This scope field is not strictly necessary, as all the info is in the token anyway (which is why it is optional). But implementation feedback was that it is good to have.

[JLS] Does it have to be equal or can it be a subset?

13. Section 4.2 - What is the profile that I am checking for the 'kty'

field?  Was I supposed to have a chance to request a profile someplace?

 

The profile checking is against the ACE Groupcomm Profile registry defined here, i.e. for now either "coap-group-oscore" of "coap-pubsub" (so not the same as the ACE profile). This is to make sure that the correct type of key is used, as defined in the instance document used (such as ace-key-groupcomm-oscore). No, the client do not request the profile, the AS determines it and sends it to the Client in the Key Distribution Response.

[JLS] I’ll have to look at this during implementation. 

 

14. Section 4.2 - Put the fact that the 'key' field is profile dependent on

the 'kty' in the 'key' paragraph.  Is it legal to define a 'kty' which does

not have a 'key' field?  If so then should this field be defined by the

profile?  Ok, I just read the full next paragraph and now I am just

confused.

 

Yes, 'key' format is dependent on 'kty'. Also yes, in theory one profile could define a ‘kty’ for which ‘key’ is empty (Note that the ‘key’ field itself MUST be present in the CBOR map). What is unclear and what paragraph are you referring to?

 

15. Section 4.2 - What is the type of profile?

 

Int, as specified in the "CBOR Value" column of the ACE Groupcomm Profile in Section 9.2.

[JLS] Text gives a type for the other fields, or says is profile specific, but not that one

 

16. Section 4.2 - Is exp supposed to be a UNIX time - if so then it should

say so.  Might be easier to reference this as CBOR Tag 1 w/o the tag.

 

Yes, UNIX time, same as “exp” defined in RFC7519. We will clarify with a direct reference to that. (AP9)

[JLS] sounds good

17.  Section 4.2 - 'pub_keys  "In case public keys are represented as

COSE_KEYS"  Does this mean that other items are legal - if so then how am I

supposed to know this.

 

Good point. We will move the negotiation that is now defined in the ace-key-groupcomm-oscore (see for example 4.1 paragraph 2) to this document, to make it more general. (AP10)

[JLS] Sounds reasonable

18.  Section 4.2 - What is the type of 'group_policies'?

 

We propose a CBOR map. See also point 2 of “Mail regarding draft-ietf-ace-key-groupcomm” for more details about this.  (AP11)

[JLS] Sounds reasonable

19.  Section 4.2 - What is the type of 'mgt_key_material'?

 

We propose CBOR bstr, with specific definition left to the instance document, as it depends a lot on the particular scheme used in the group. (AP12)

 

20.  Section 4.2 - The last paragraph seems to be something of a

non-sequitur.   Perhaps this is better omitted and just put someplace else,

like the next section.

 

Yes, we will move that. Our proposal is to put it in the end of section 4. (AP13)

[JLS] I think that is reasonable

21. Section 5 - Is there some type of requirement for positive delivery of

new keys in the event of a KDC changing the key.  I put this here wrt a node

leaving, but it applies equally to a node getting itself added.

 

We are not sure we understand this question. Are you asking about ACK of (successful) delivery of new keys? In that case, if the rekeying is performed node-by-node as described in this document, using confirmable messages should be enough. Otherwise, it would be mostly left to the single nodes to eventually find out that they are using stale key material and should individually ask for the latest one.

[JLS] For some types of lists, it makes sense that there should be some type of forcing function that a sender is going to understand that there are new keys before sending a message out.  This would require a positive delivery or a policy that says always check before sending.  Doing a multicast message cannot be done confirmable according to the normal specifications so you would not  necessarily do a fast notification if it needs to be done on individual messages.  I am not sure what, if anything, needs to be said here.  This may just be considerations someplace

 

22.  Section 5.1 - There currently is no way for an AS to communicate to the

KDC that an authorization has been revoked.  There is only a way for a KDC

to ask the AS by introspection.  The first sentence is problematic.  Do we

need some type of extension to support this?

 

Right, that is not defined in ACE, we will remove this sentence. We’d also like to get feedback from the WG about this. (AP14)

[JLS] Makes sense.  I think this just needs to be highlighted as introspection.  It might be nice to define a multiple token introspection message at some point to the KDC could, in a single message, get all of the statuses before doing a key update operation.

23.  Section 5.2 - If a topic is provided and the user is authorized for two

topics which use the same group, what happens if the user asks to leave one

of those two topics but wants to say on the other?  

 

See section 5.2: 

 

  Note that the 'role' field is omitted since such a request should

  only be used to leave a group altogether.  If the leaving node wants

  to be part of a group with fewer roles, it does not need to

  communicate that to the KDC, and can simply stop acting according to

  such roles.

 

If two topics (application groups) are covered by the same security group, and a user wants to stop following one topic while still being authorized, it does not need to leave the security group, it can just discard future messages related to that topic. The actual leaving of application groups, e.g. unsubscribing from a topic, is out of the scope of this document.

[JLS] But the scope field is included in the token.  I am not sure that I see any use of the scope field here at all.

24.  Section 5.2 - What is the purpose of providing the 'client_cred' in a

leave request.  It makes more sense to provide the id in the group than this

Field.

 

Just to make it easier for the implementer on knowing which key to remove on the KDC (it is optional and should match the key the KDC has. But we can remove that, as the KDC is supposed to know that. (AP15)

[JLS] Makes sense

25. Section 5.2 -  It is not clear to me that the correct answer to a badly

formatted leave request is to send a bad request error back.  I would think

that as long as the KDC can figure out what is being referred to then the

sender should be removed from the group.

 

Ok, "not formatted correctly" meant that the KDC cannot figure out what it is asked to do. We will rephrase for clarity. (AP16)

[JLS] Sounds good

26. Section 5.2 - It is not clear to me if the last paragraph means that the

KDC can remove the AS access token from it's database when a leave occurs,

or if it can only be removed when it expires.

 

That paragraph was meant to mean that the token can be removed only when it expires (or when you update it). What are we missing?

[JLS] You are not necessarily missing something.  However this could be done by the KDC forgetting the token when the leave occurs and the client supplying the token again when it does a later join.  This means that the KDC only needs to have tokens for currently active members and not for all past members which still have valid tokens.

27.  Section 6 - If the 'exp' parameter is not specified, when does keying

material expire?  This is not covered in the first paragraph.

 

Right, we missed this. We will add this to the Key Distribution Response. (AP17)

[JLS] Sounds good.

28.  Section 6 - in the second paragraph it says that the problem is not

being able to decrypt a message, the correct condition is not being able to

find key material.  A corruption in the message should not require the

entity to looking for a rekey event to be checked.  This is a bad DOS vector

otherwise.

 

Right, we will clarify. (AP18)

[JLS] sounds good

29. Section 6 - Should a KDC employ a best effort to keep the same kid value

when a group is rekeyed so that one could check the signature even if the

key material has moved on as this would provide a potential DOS attack to be

attenuated.

 

Yes, we will add a sentence about that (although we suggest a MAY employ a best effort) after paragraph 2 of section 6. (AP19)

[JLS] As long as the reasoning is included as well, that should be fine.

30.  Section 6 - should a client keep a the decryption failures so that they

can be decrypted after getting new key material or is this to be treated as

a loss of message?

 

This would be up to the application to decide, and more related to specifications about message exchange/processing like Group OSCORE. We will add a sentence about this being application dependent. (AP20)

[JLS] sounds fine

31.  Section 6 - How does the event of sending the re-key material as a

multicast message in general lock out the entity that just left the group?

This should be discussed.

 

We can surely clarify that this is not about one single multicast message containing the key. The point is exactly about using secure rekeying schemes that, by sending also multicast messages, are able to lock out the leaving node and effectively exclude it. (AP21)

[JLS] Sounds good – a reference to such a scheme might be useful

32.  Section 6 - There needs to be a method for a client to say that it

needs a new key id someplace in the protocol which may or may not cause a

new re-key operation in the event that it sends too many messages on the

current content.

 

Ok, we will add text on how to get updated keying material.

 

The proposal is to add a “Type” field to requests, as we have enough types to motivate that (key distribution request, leave request, update key request, new key request). We will register the different types in a new IANA registry. The two new types are intended for current group members and are the following:

 

* “update”: the node can send it to get updated keying material (might get back the same, if it didn't change).

 

* “new”: the node can send it to retrieve a *new* key id, if it needs new keying material (e.g. seq numbers have wrapped around, expiration, etc).

 

We will also remove the “leave” field as that is not needed anymore. (AP22)

[JLS] Sounds reasonable

33.  Section 6.1 - What happens if I ask for a key re-distribution, but

supply a different scope than for the original message < assumes a

multi-topic scope>.  I am not sure what the purpose of the scope is at this

time given that you are not checking roles as well.

 

Role is not checked as the Key Re-Distribution Request is done to retrieve the group keying material, not the public keys for signature verification. For example, in pubsub, the node is re-requesting the symmetric key to protect the communication. The KDC does not need to know nor check if the node is an authorized pub or a sub, but only that it is authorized to that topic. Checking the scope make sure that a node that is authorized for a certain topic does not request the material for another topic.

 

Why would you want to ask key distribution for one scope only when both scopes map to the same security keying material?

[JLS] Because it is easier on the client.  I can ask for the specific token that caused the problem and not have to remember all of the different topics that are associated with the group. 

34.  OUT OF ORDER - Should a KDC have a single resource which allows for it

to return a group based on what the topic/scope is that is passed in without

the client first knowing what the group id is going to be?

 

I interpret your question as follows: you are wondering if the following mechanism is/should be supported: the client sends a request to a well known resource on the KDC asking "what is the sec group for this topic/application group?" (topic could be in the payload for example). The KDC responds with info about the security group (Group ID, etc). If that is the case, that is taken care of by the resource directory, as described in draft draft-tiloca-core-oscore-discovery. The KDC could take that role too. If that is not the correct interpretation of this comment, then could you expand?

[JLS] Actually I was thinking of something more general.  I can post the request to a single common resource name and the KDC would lookup what the correct group id would be for the request and internally dispatch it to the correct internal resource.  Might be easier on clients if only one point is needed and no directory lookup is needed.

35.  OUT OF ORDER - are all of the resource names required to be at the

root?  If I have a KDC which is shared with something else (say a Pub Sub

server) then it would make sense to have post to /KDC/group-id.

 

No, they don’t need to be at the root, they just need to be associated to the group.

[JLS] Take a look at the resource directory and pub sub more the set of templates that they are using.  Would this makes sense to use here to address such issues?

36.  Section 7.1 - what is the format of get_pub_keys when group member ids

are included?

 

We propose bstr as default type. Instances may change that if they need to. (AP23)

[JLS] What would be a case where something else would really make sense?  The group member id is currently define as something set for OSCORE  are you thinking that a different protocol might format them differently?

37.  Section 7.2 - There is a race condition caused by the last paragraph in

this section.  Entity A sends a message, leaves the group, Entity B receives

the message and asks for the public key.  Is this an issue?

 

We don't think this as an issue. In fact, A could wait for a reply from B before leaving the group if it is critical that B receives A's message. Otherwise, we could add some text about a policy for KDC to maintain leaving group members’ Public Keys for a certain amount of time after their leaving, before discarding them. Would that solve the issue? (AP24)

[JLS] If the message is just a broadcast then I would not expect A to wait for a response.  Yes what you suggest would solve the issue, it would also solve the issue if you decided that this is totally reasonable as A should not expect its message to be processed after it has left the group.

38. Section 91. - can the profile column have multiple values?

 

Yes. We will add some text about allowing several profiles in this column. (AP25)

[JLS] Sounds good.

39.  It would be useful to have a section which describes all of the items

that a profile must cover in order to be used.

 

Good idea. We will add that. (AP26)

[JLS] Sounds good.

Jim

 

-----------------------------------------

 

draft-ietf-ace-key-groupcomm - 03/04/2019 03:29

 

Should there be a case described where messages are relatively rare, but

confidentiality is rare.  In this case a simple question to the KDC about

the current group ID would be useful.

 

Could you expand on "confidentiality is rare"? Now we are adding this new paragraph where a node can request the keying material to check if it's been updated (see point 32). That should cover this comment, if I understand you correctly.

[JLS] That was a typo – It should be “Confidentiality is extremely high.”  The above message about having an “update” message to the KDC would deal with this case and provides additional motivation to that message.

Jim

 

-----------------------------------------

 

Mail regarding draft-ietf-ace-key-groupcomm - 04/04/2019 03:42

 

Some additional things that need to be thought about.

 

1.  Someplace as part of the re-key discussions there ought to be some

commentary on the wisdom of rate limiting the frequency of doing re-keying

operations.

 

Ok, we can expand on some considerations that are now just quickly mentioned. Our proposal is to add that other than rekeying due to membership changes (if relevant to the application), periodic rekeying should occur at the minimum rate necessary to discourage an adversary to derive the key material out of brute force and traffic collection/analysis. (AP27)

[JLS] The case that I was actually thinking about was the membership change rekeying.  If you have 30 joins in the course of a minute, you might want to delay the rekey messages slightly or make the presumption that there is not traffic that needs to be protected on a backwards basis to the first join.  Similar issues will arise for leaves.

2. I think that there should be an optional parameter that says "If this

much time has elapsed since the last time you checked, see if the group id

has changed."  This would be combined with a polling client to ensure that

they check for an updated key context before doing some operation.

 

Ok. We propose to implement this mechanism as follow:

 

* We will define the format of ‘group_policies’ as CBOR map.

 

* We will define a new registry for ‘group_policies’.

 

* In this registry, we will define a new parameter that contains the time as you describe. If you have ideas about the name, that would be very helpful.

 

And since we define the registry, we can add the “sync seq number” parameter in it as well, which is listed as an example right now. (AP28)

[JLS] Sounds good – “key update check interval” might be a name

3.  What happens in the following situations:

a) The key context is changed between a request being sent and the server

receiving the request.  This could just be because the sender did not get

the notification of the key context changing.

b) The response takes "a while" to generate and the key context is changed

after the request is received, but before the response is sent.

 

Situations a) and b) are essentially the same, with the difference that they happen either on client or on server (the node receives a message encrypted with old/non recognized context). What happens in that case is that the receiver would contact the KDC to verify that its own keying material has not being updated (using the new “update” method defined in point 32). When it realizes it has the latest one, it discards the message, and optionally sends back an error response (in case a) that would hint that the message did not go through. In case b), when verification fails on the client, I would expect the client to be configured to try again, and this time it should hit the new security context on the server.

 

See also  <https://core-wg.github.io/oscore-groupcomm/draft-ietf-core-oscore-groupcomm.html#rfc.section.8.4> https://core-wg.github.io/oscore-groupcomm/draft-ietf-core-oscore-groupcomm.html#rfc.section.8.4 about keeping old security context for a while. Did you want the same type of considerations in ace-key-groupcomm as well?

[JLS] In the first case it is a simple race condition and some type of configurable keep the last context for a while does deal with this.  The second case is a bit different in terms of – does the response get sent under the new context, the old context or not at all.  I don’t know that I have any idea of what the right answer is and having this described would be useful.

c)  The key context is changed in the middle of a block-wise transfer.

 

To me this is no different than the cases above. If one block fails, the total message would fail. Considerations above apply. Do you think we need additional considerations about blockwise here?

[JLS] One could say that the sender of the blocks just changes the keys and continues.  As long as both sides get the new keying I don’t think that this would cause a problem.  But again yes it has much of the same issues as above although it does have fun that it applies to both the sender and the recipient.  It is more problematic than the above message in that depending on how fast keys are changed, you are going to consume a large amount of the network resending the message from start again and again.  This is more of a problem than it is for case b above.

Jim

 

-------------

 

Thanks,

Francesca and Marco