Subject: [Ace] Looking at COSE based unicast and multicast

From: "Jim Schaad" <[email-masked]>
Date: Sun, 13 Sep 2015 21:16:36 -0700

I have been looking at some of the issues that have come up with COSE and
the question of how messaging could do the same type of thing as what the
multi-cast DTLS solutions are looking at.  In order to do this I am going to
do a fast review of what happens for "real" DTLS and then start looking at
the equivalent of DTLS using the same model as what the ACE DTLS solutions
are looking at - specifically that the key management is done externally.

For "real" DTLS, the context is always identified by the set of <source IP,
source port, destination IP, destination port>.  This set of 4 values may
not be the same on both the client and the server due to NATs being on the
path between the two ends.  All of the NAT mapping is taken care of
correctly since the key setup is done using DTLS so that the mapping can be
created in all intervening routers and will be kept for the duration of the
DTLS session.

Looking at UDP for CoAP, in a "clean" system with no NAT translation it
might be possible to using the same 4-tuple of values at each end to know
what the cryptographic context is.  Looking at the source and destination
values (which would be the same) it will be fine independent of how the
contexts are created.  The biggest issue that I can see is that the use of
something like DHCP might cause problems if addresses are changed when
devices go to sleep.  

Looking at UDP for CoAP in the case of a NAT doing address translations
gives a different set of cases.  The problem here is that the introduction
function would need to know what the routing is going to be in order to give
the correct set of endpoints to each of the entities.  Additionally, that
would need to be locked down for the duration of the security context.  This
is not really a viable option.  It is more viable for dealing with CoAP
proxy agents as they are going to have a better idea of both which ones
exist, also the proxies would have a better idea of how long a mapping would
need to be maintained.  As with "real" DTLS, changing the routing would
cause a break in the mapping and thus lead to communication failures.
Depending on how things are setup, this might be more of an issue for a CoAP
world than the normal UDP world.

>From this, it seems to me that does support the position that some
information about context needs to be passed on the initial message.
Depending on how this is presented I would expect this to be done with the
current COSE encrypted message structure.  It is potentially different in
the case where the client is being used to relay information to the server
about the authorization information.

The response does not appear to need a context identifier as there is
already information in the CoAP message that can be used for determining the
context.  Specifically the Token and Message ID fields can be used to
associate requests and responses.  This means that a client can use this to
determine what context was used by the server to encrypt the message that
was returned.  (Specifically, the same context and the client used to
encrypt the request.)  This means that we can say that there is an implicit
context for encrypted messages in this case the new encryption structure w/o
recipients would make sense.  This analysis would apply to the observe
dialog structure as well, the token can be used to associate all items in
the same context.

For a subscription model to a third party, there are a couple of different
ways to look at how it can be setup.  The big question is if the context is
going to be unique to the originator, or it is unique to the subscription.
In either case, the client is going to end up using two different contexts
in this situation.  The first case is for setting up the original
subscription.  In that case a context associated with the data storage
server is going to be needed.  However, once information starts flowing back
to the client from the data storage service, the context associated with the
origination server is going to be used.  It is not clear that the action of
doing the subscription would need to be encrypted,  this simplified things
as only one encryption context is now needed.  Otherwise either two contexts
need to be tried, or the type of message needs to be known so that the
client understand where the encrypted content originates.

For the case of multicast, it appears to me that the context can be inferred
in most cases.  I would assume that a context is going to be signed to each
multicast address, port pair.  I would also assume that this would be a
unique assignment in that multiple contexts would not be assigned.  This
does allow for any node which has the context to send out a multicast
message without a problem.  The more interesting question is what to do with
the unicast responses to a multicast message.  Should they be encrypted with
the multicast group context, in which case the message id/token on the
message is sufficient to identify the context.  Or should they be encrypted
with a unicast key pair between the replier and the original message sender?
This implies that such a key context needs to be setup for each such link
which may or may not be the case.  In this event it might be necessary to
identify the context that was used to encrypt the unicast message.  I have
not managed to think this through far enough.

In any event, there appear to be enough cases where the encryption context
can be inferred from the message to make it reasonable to have a version of
COSE messages which do not have any recipient information attached to them.
In the case of pure unicast, it would be used for at least 50% of the
messages (a higher percentage for observing state).  And for multicast it
might be used either for 50% or all of the messages depending on how
responses are handled.

I am interested in people looking at my analysis and tell me if I am right,
wrong or unclear.

Jim

---

From: Göran Selander <[email-masked]>
Date: Mon, 14 Sep 2015 09:48:07 +0000

>about the authorization information.

Using the current COSE encrypted message structure is not addressing the
concerns about message size as has been discussed previously. From the
proposed ACE architecture I can reference two categories of formats:

1. One category which assumes that there is essentially only a “base key”
established between sender and receiver, and where the message provides
means to derive the security context to use with the message.

2. Another category which is highly optimized for the setting that the
security context is available at the receiver.

I think the distinction between COSE_Enveloped and COSE_Encrypted
structure is a good step in the right direction, but the latter should
allow for the desired identification and optimization for the most common
settings. Something like:

[ message type, protected headers, cipher text, tag ]

where protected headers can identify the security context and the
nonce/sequence number.

In fact, to get replay protection of request, and of response if no prior
request bound to the response, one of the fields in the protected header
must be nonce/sequence number/timestamp, right?  Thus the format would
anyway carry some information about security context. It seems odd to not
allow an identifier of what context this nonce/etc. refers to.

>context.  

>Specifically the Token and Message ID fields can be used to
>associate requests and responses.

Message ID is not a reliable identifier for associating request to
response.

>  This means that a client can use this to
>encrypt the request.)

The context may be different for request and response, and always is in
OSCOAP.

> This means that we can say that there is an implicit

Even if there are cases where leaving out context in response could be
performed, I think it should be allowed to specify context as an option.
This would also relieve the settings where multiple contexts needs to be
tried.

>client understand where the encrypted content originates.

The data store need not be trusted. Information about binding between
different contexts needs to be obtained from a trusted party, such as the
authorization server. I believe the presence of a context identifier would
simplify the processing where this type of binding needs to be established
after the message has been received, compared to the case of receiving an
encrypted structure without any handle whatsoever.

>I am interested in people looking at my analysis and tell me if I am

There are cases where optimized message and context identification are
needed, or where a context identifier could simplify the processing. In
both cases allowing optional header in the COSE_encrypted format would
solve the problem. For replay protection, some context information such as
sequence number/nonce needs anyway to be transferred, so I would say that
the context cannot be completely implicit.

Göran

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 14 Sep 2015 09:09:03 -0700

> -----Original Message-----
> From: Göran Selander [mailto:[email-masked]]
> Sent: Monday, September 14, 2015 2:48 AM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Subject: Re: [Ace] Looking at COSE based unicast and multicast
> 
> 
> 

> >Depending on how this is presented I would expect this to be done with
> >the current COSE encrypted message structure.  It is potentially
> >different in the case where the client is being used to relay
> >information to the server about the authorization information.
> 
> 2. Another category which is highly optimized for the setting that the security
> context is available at the receiver.
> 
> 
> I think the distinction between COSE_Enveloped and COSE_Encrypted structure
> is a good step in the right direction, but the latter should allow for the desired
> identification and optimization for the most common settings. Something like:
> 
> In fact, to get replay protection of request, and of response if no prior request
> bound to the response, one of the fields in the protected header must be
> nonce/sequence number/timestamp, right?  Thus the format would anyway
> carry some information about security context. It seems odd to not allow an
> identifier of what context this nonce/etc. refers to.
> 
> 
> >
> >already information in the CoAP message that can be used for
> >determining the context.
> 
> >Specifically the Token and Message ID fields can be used to associate
> >requests and responses.
> 
> Message ID is not a reliable identifier for associating request to response.

First, please note that I said both Token and Message ID.  Are there cases that between these two fields the request and the response cannot be associated?

> 
> >  This means that a client can use this to determine what context was
> >used by the server to encrypt the message that was returned.
> >(Specifically, the same context and the client used to encrypt the
> >request.)
> 

Please note that I am using context in the same way that TLS uses this term.  This means that the information is going to be different for the two directions, but the context identifies a single set of information.   

I don't see anything called OSCOAP in either core or ace.

> 
> 
> > This means that we can say that there is an implicit context for
> >encrypted messages in this case the new encryption structure w/o
> >dialog structure as well, the token can be used to associate all items
> >in the same context.
> 
> This would also relieve the settings where multiple contexts needs to be tried.

Please identify situations where multiple contexts would need to be tried.  I have only come up with one so far, assuming that one is going to use distinct address/port pairs for the multi-cast case.  That would be the case of subscribing.

> 
> >
> >For a subscription model to a third party, there are a couple of
> >different ways to look at how it can be setup.  The big question is if
> >the context is going to be unique to the originator, or it is unique to
> >the subscription.
> >In either case, the client is going to end up using two different
> >contexts in this situation.  The first case is for setting up the
> >original subscription.  In that case a context associated with the data
> >storage server is going to be needed.  However, once information starts
> >flowing back to the client from the data storage service, the context
> >associated with the origination server is going to be used.  It is not
> >clear that the action of doing the subscription would need to be
> >encrypted,  this simplified things as only one encryption context is
> >now needed.  Otherwise either two contexts need to be tried, or the
> >type of message needs to be known so that the client understand where
> >the encrypted content originates.
> 
> authorization server. I believe the presence of a context identifier would simplify
> the processing where this type of binding needs to be established after the
> message has been received, compared to the case of receiving an encrypted
> structure without any handle whatsoever.

In my analysis I did not make any assumptions that the data store was trusted to do anything more than its assigned job.  I did not make any assumptions that it would do cryptography except for messages sent directly to it.  

I do not see any difference in needing to obtain the keys/context information either before or after receiving the first message.  However, since we do not have a sketched protocol for getting keys yet it is hard to be sure.  Even if you have current keys you will still need to be able to get updated keys when the epoch rolls over to the next value.  This means that the two cases are going to be very similar.

> 
> >
> >For the case of multicast, it appears to me that the context can be
> >inferred in most cases.  I would assume that a context is going to be
> >signed to each multicast address, port pair.  I would also assume that
> >this would be a unique assignment in that multiple contexts would not
> >be assigned.  This does allow for any node which has the context to
> >send out a multicast message without a problem.  The more interesting
> >question is what to do with the unicast responses to a multicast
> >message.  Should they be encrypted with the multicast group context, in
> >which case the message id/token on the message is sufficient to
> >identify the context.  Or should they be encrypted with a unicast key
> >pair between the replier and the original message sender?
> >This implies that such a key context needs to be setup for each such
> >link which may or may not be the case.  In this event it might be
> >necessary to identify the context that was used to encrypt the unicast
> >message.  I have not managed to think this through far enough.
> >
> >In any event, there appear to be enough cases where the encryption
> >context can be inferred from the message to make it reasonable to have
> >a version of COSE messages which do not have any recipient information
> >attached to them.
> >messages (a higher percentage for observing state).  And for multicast
> >it might be used either for 50% or all of the messages depending on how
> >responses are handled.
> >
> >I am interested in people looking at my analysis and tell me if I am
> >right, wrong or unclear.
> 
> 
> needed, or where a context identifier could simplify the processing. In both
> cases allowing optional header in the COSE_encrypted format would solve the
> problem. For replay protection, some context information such as sequence
> number/nonce needs anyway to be transferred, so I would say that the context
> cannot be completely implicit.

Yes, some input into an IV needs to be transferred, but I would not consider that to be part of the saved context.   This is not needed for replay protection as much as it is needed for making sure that IVs are not re-used.  This could potentially be different from the sequence number used for replay protection but generally would not be.

I would expect that you would never want to send information you do not have to since it only adds size.  But still trying to figure out where it is and is not needed to have a context identifier to begin with.  Then we can figure out where and if it makes sense to include it.  But at that point you are already talking about taking size hits.

Jim

---

From: Göran Selander <[email-masked]>
Date: Tue, 15 Sep 2015 06:20:23 +0000

Comments inline.

My summary: 

The request in general needs a context identifier. Your proposal is to use
the COSE_enveloped format, my proposal is to allow an optional context
identifier in the COSE_encrypted format, which is more compact.

If you associate the CoAP Token of a request to the context then you can
use that as an index for context identifier in the response and hence use
COSE_encrypted. But now you have two parameters that perform a similar
task: Token and Context Identifier, and which both has to be transferred
in a request. The Token field is variable length 0-8 bytes. Since we
cannot attribute any end-to-end security properties of Token, the object
security scheme is made independent of how the Token is set, analogously
to the case in DTLS. By instead relying on Token to avoid collisions we
may need a larger Token.

I’m not convinced with the difference between how the message is formatted
depending on whether it is a request or response. A given node may send
the same resource representation as PUT request or GET response and thus
would use different COSE message formats.

It is also a matter of how the received COSE object will be subsequently
used. For example, in Information-Centric Networking, if I’m not mistaken,
one of the requirements is that each protected object has a globally
unique name. By shifting focus from a context identifier within the COSE
object to Token which is ephemeral data outside the COSE object, ICN
applications would always have to use the less compact format.

I think we agree that some parameter(s) for replay protection/IV
uniqueness is needed in request and response, so would be in the header of
both COSE_enveloped and COSE_encrypted.

Göran

On 2015-09-14 18:09, "Jim Schaad" <[email-masked]> wrote:

>>structure
>First, please note that I said both Token and Message ID.  Are there
>cases that between these two fields the request and the response cannot
>be associated?

I don’t see how Message ID adds anything. Compare figures 5 and 6 of
RFC7252. I believe matching CoAP Token in request and response would be
sufficient, although the Token in itself can’t be integrity protected in
transfer since it may be changed by a proxy.

>Please note that I am using context in the same way that TLS uses this
>term.  This means that the information is going to be different for the
>two directions, but the context identifies a single set of information.
>

Sorry, abbreviation for the ACE draft "Object Security for CoAP"

>Please identify situations where multiple contexts would need to be
>tried.  I have only come up with one so far, assuming that one is going
>to use distinct address/port pairs for the multi-cast case.  That would
>be the case of subscribing.

Another case is Token collisions.

>In my analysis I did not make any assumptions that the data store was
>trusted to do anything more than its assigned job.  I did not make any
>assumptions that it would do cryptography except for messages sent
>directly to it.  

Fair enough. I triggered on "the client is going to end up using two
different contexts in this situation”,  but as you say there are no
guarantees to what these context provide.

>I do not see any difference in needing to obtain the keys/context
>information either before or after receiving the first message.  However,
>since we do not have a sketched protocol for getting keys yet it is hard
>to be sure.  Even if you have current keys you will still need to be able
>to get updated keys when the epoch rolls over to the next value.  This
>means that the two cases are going to be very similar.

I was thinking of a case when the receiving node actually has the relevant
context, but since there is no context identifier cannot determine this is
the case before doing a look-up of what context is valid for this resource.

>>both
>Yes, some input into an IV needs to be transferred, but I would not
>consider that to be part of the saved context.   This is not needed for
>replay protection as much as it is needed for making sure that IVs are
>not re-used.  This could potentially be different from the sequence
>number used for replay protection but generally would not be.

Agree.

>
>I would expect that you would never want to send information you do not
>have to since it only adds size.  But still trying to figure out where it
>is and is not needed to have a context identifier to begin with.  Then we
>can figure out where and if it makes sense to include it.  But at that
>point you are already talking about taking size hits.

Token could double play as indication of context identifier, but not
always, not for free, and also may lead to some IMHO confusing constraints
such as different message formats for request and response.

As I understood one reason why COSE_encrypted was introduced was to meet a
request for a more compact format in settings where context is already
established. Not sending context identifier may be an optimization in some
settings, but that format would be of much less use if a context
identifier cannot be included.

Göran

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 15 Sep 2015 13:06:50 -0700

> Sent: Monday, September 14, 2015 11:20 PM
> The request in general needs a context identifier. Your proposal is to use the
> COSE_enveloped format, my proposal is to allow an optional context identifier
> in the COSE_encrypted format, which is more compact.
> 
> If you associate the CoAP Token of a request to the context then you can use
> that as an index for context identifier in the response and hence use
> task: Token and Context Identifier, and which both has to be transferred in a
> request. The Token field is variable length 0-8 bytes. Since we cannot attribute
> any end-to-end security properties of Token, the object security scheme is made
> independent of how the Token is set, analogously to the case in DTLS. By instead
> relying on Token to avoid collisions we may need a larger Token.

There is no need to explicitly protect the context identifier.  It is implicitly protected as the message will fail to validate if you use the wrong context.  This means that it is protected even if it is not part of the message properties.  Having the context identified by the token is totally legitimate and totally secure.   In the case of unicast DTLS, there is no explicit context identifier anywhere.  It is totally based on the four-tuple of addresses and ports.  This has zero cryptographic security applied to these values, the security is totally implicit. 

> depending on whether it is a request or response. A given node may send the
> same resource representation as PUT request or GET response and thus would
> use different COSE message formats.

Given that the COSE message representation is going to have to be built uniquely for each message sent, I don't know that this is a problem.  How the COSE is created is based on the http-like operation that is being used.  This will be well understood when it occurs and when it does not occur.  

> 
> 
> It is also a matter of how the received COSE object will be subsequently used.
> For example, in Information-Centric Networking, if I’m not mistaken, one of the
> requirements is that each protected object has a globally unique name. By
> shifting focus from a context identifier within the COSE object to Token which is
> ephemeral data outside the COSE object, ICN applications would always have to
> use the less compact format.

If you are correct, and the unique name is always known to both parties, then it is quite possible that you have a situation where the context information can always be implicit and would not need to be carried at all.

> 
> I think we agree that some parameter(s) for replay protection/IV uniqueness is
> needed in request and response, so would be in the header of both
> COSE_enveloped and COSE_encrypted.

I have already said this is true, and it is content related so it fits the current COSE model.  However, there is an interesting question if you want this in the COSE world or in the CoAP world and just protect it in COSE.  Having two different replay protection systems in place may be overkill.

> >> >Depending on how this is presented I would expect this to be done
> >> >with the current COSE encrypted message structure.  It is
> >> >potentially different in the case where the client is being used to
> >> >relay information to the server about the authorization information.
> >>
> >> Using the current COSE encrypted message structure is not addressing
> >> the concerns about message size as has been discussed previously.
> >> From the proposed ACE architecture I can reference two categories of
> formats:
> >>
> >> established between sender and receiver, and where the message
> >>provides  means to derive the security context to use with the message.
> >>
> >> 2. Another category which is highly optimized for the setting that
> >>the security  context is available at the receiver.
> >>
> >>
> >>structure  is a good step in the right direction, but the latter
> >>should allow for the desired  identification and optimization for the
> >>most common settings. Something
> >>like:
> >>
> >> In fact, to get replay protection of request, and of response if no
> >>prior request  bound to the response, one of the fields in the
> >>protected header must be  nonce/sequence number/timestamp, right?
> >>Thus the format would anyway  carry some information about security
> >>context. It seems odd to not allow an  identifier of what context this
> >>nonce/etc. refers to.
> >>
> >>
> >> >
> >> >The response does not appear to need a context identifier as there
> >> >is already information in the CoAP message that can be used for
> >> >determining the context.
> >>
> I don’t see how Message ID adds anything. Compare figures 5 and 6 of RFC7252.
> I believe matching CoAP Token in request and response would be sufficient,
> although the Token in itself can’t be integrity protected in transfer since it may
> be changed by a proxy.
> 
> >
> >>
> >> >  This means that a client can use this to determine what context
> >> >was used by the server to encrypt the message that was returned.
> >> The context may be different for request and response, and always is
> >> in OSCOAP.
> >
> >> >recipients would make sense.  This analysis would apply to the
> >> >observe dialog structure as well, the token can be used to associate
> >> >all items in the same context.
> >>
> >> Even if there are cases where leaving out context in response could
> >>be  performed, I think it should be allowed to specify context as an option.
> >> >different ways to look at how it can be setup.  The big question is
> >> >if the context is going to be unique to the originator, or it is
> >> >unique to the subscription.
> >> >original subscription.  In that case a context associated with the
> >> >data storage server is going to be needed.  However, once
> >> >information starts flowing back to the client from the data storage
> >> >service, the context associated with the origination server is going
> >> >to be used.  It is not clear that the action of doing the
> >> >subscription would need to be encrypted,  this simplified things as
> >> >only one encryption context is now needed.  Otherwise either two
> >> >contexts need to be tried, or the type of message needs to be known
> >> >so that the client understand where the encrypted content originates.
> >>
> >>different contexts needs to be obtained from a trusted party, such as
> >>the  authorization server. I believe the presence of a context
> >>identifier would simplify  the processing where this type of binding
> >>needs to be established after the  message has been received, compared
> >>to the case of receiving an encrypted  structure without any handle
> >>whatsoever.
> >
> Fair enough. I triggered on "the client is going to end up using two different
> contexts in this situation”,  but as you say there are no guarantees to what these
> context provide.
> 
> 
> >information either before or after receiving the first message.
> >However, since we do not have a sketched protocol for getting keys yet
> >it is hard to be sure.  Even if you have current keys you will still
> >need to be able to get updated keys when the epoch rolls over to the
> >next value.  This means that the two cases are going to be very similar.
> 
> context, but since there is no context identifier cannot determine this is the case
> before doing a look-up of what context is valid for this resource.
> 
> >
> >>
> >> >
> >> >inferred in most cases.  I would assume that a context is going to
> >> >be signed to each multicast address, port pair.  I would also assume
> >> >that this would be a unique assignment in that multiple contexts
> >> >would not be assigned.  This does allow for any node which has the
> >> >context to send out a multicast message without a problem.  The more
> >> >interesting question is what to do with the unicast responses to a
> >> >multicast message.  Should they be encrypted with the multicast
> >> >group context, in which case the message id/token on the message is
> >> >sufficient to identify the context.  Or should they be encrypted
> >> >necessary to identify the context that was used to encrypt the
> >> >unicast message.  I have not managed to think this through far enough.
> >> >
> >> >context can be inferred from the message to make it reasonable to
> >> >have a version of COSE messages which do not have any recipient
> >> >information attached to them.
> >> >In the case of pure unicast, it would be used for at least 50% of
> >> >the messages (a higher percentage for observing state).  And for
> >> >multicast it might be used either for 50% or all of the messages
> >> >depending on how responses are handled.
> >> >
> >> There are cases where optimized message and context identification
> >>are  needed, or where a context identifier could simplify the
> >>processing. In both  cases allowing optional header in the
> >>COSE_encrypted format would solve the  problem. For replay protection,
> >>some context information such as sequence  number/nonce needs anyway
> >>to be transferred, so I would say that the context  cannot be
> >>completely implicit.
> >
> >have to since it only adds size.  But still trying to figure out where
> >it is and is not needed to have a context identifier to begin with.
> >Then we can figure out where and if it makes sense to include it.  But
> >at that point you are already talking about taking size hits.
> 
> Token could double play as indication of context identifier, but not always, not
> for free, and also may lead to some IMHO confusing constraints such as
> different message formats for request and response.
> 
> settings, but that format would be of much less use if a context identifier cannot
> be included.
> 
> 
> Göran

---

From: Göran Selander <[email-masked]>
Date: Thu, 17 Sep 2015 07:54:39 +0000

Jim, 

I think we are arguing from fixed positions.

COSE_Encrypted format, without mandatory recipient structure, is a good
step towards a more optimized format. The main disagreement seems to be on
the option to use a context identifier in the header.

We would like to apply this optimized format also to symmetric encryption
+ asymmetric signature, as well as integrity protection only (only one
signature/MAC). All these could be one common format.

Comments inline.

On 2015-09-15 22:06, "Jim Schaad" <[email-masked]> wrote:

>There is no need to explicitly protect the context identifier.  It is
>implicitly protected as the message will fail to validate if you use the
>wrong context.  This means that it is protected even if it is not part of
>the message properties.  Having the context identified by the token is
>totally legitimate and totally secure.   In the case of unicast DTLS,
>there is no explicit context identifier anywhere.  It is totally based on
>the four-tuple of addresses and ports.  This has zero cryptographic
>security applied to these values, the security is totally implicit.

I don’t claim that omitting the context identifier is insecure. But it is
not always feasible e.g. in requests, and it has impact on processing and
size of other parameters such as CoAP Token.

>>the
>Given that the COSE message representation is going to have to be built
>uniquely for each message sent, I don't know that this is a problem.  How
>the COSE is created is based on the http-like operation that is being
>used.  This will be well understood when it occurs and when it does not
>occur.  

It is possible to use different COSE formats for request and response but
in the case I mentioned when the same resource representation for
potentially the same comsumer is using a different format and of different
size depending on whether it is PUT request or GET response, that just
doesn’t sound like a good idea.

>If you are correct, and the unique name is always known to both parties,
>then it is quite possible that you have a situation where the context
>information can always be implicit and would not need to be carried at
>all.

As far as I understand ICN I believe the name should be bound / possible
to derive from the information object. But we could leave this to the ICN
experts to comment on. I just note that there may be a significance
whether identification is provided by the object itself or if it requires
additional data (such as Token and URI).

>>uniqueness is
>I have already said this is true, and it is content related so it fits
>the current COSE model.

If I understand right, this is about the content / recipient paradigm.

Another way to think of this is in terms of sender, which is what we use
context identifier for.
If the sender context is identified, each recipient can find out for
itself if and how to make use of the object. One important assumption is
that the sender does not have to know anything about the recipient. The
sender could rely on a trusted third party, to provide it with the right
security context it will use, and which also will interact with the
recipient.

>However, there is an interesting question if you
>want this in the COSE world or in the CoAP world and just protect it in
>COSE.  Having two different replay protection systems in place may be
>overkill.

The sequence number etc. should be protected in COSE. As far as I
understand, the only place to for sequence number etc. in COSE_encrypted
is in the header. But the verification of replay protection belongs to the
application. Different replay protection mechanisms may be used depending
on application, e.g. sliding window or strict order.

Was this what you were referring to?

Göran

>>RFC7252.
>>different
>>always, not

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 17 Sep 2015 13:19:13 +0200

Hi Jim and Göran,

I'm still trying to understand which problems you are trying to solve
with a context identifier. Here are some problems I can think of:

Security association:
1. The client must know if a received message is a response to its request.
2. If the client sends a new request it might want to use the same
session keys etc, thus the server must be able to identify if the
request belongs to a certain "session".
3. The server needs to know if a received request belongs to an existing
context and use the respective keying material etc for its answer.
Other:
4. Client and server must be able to identify replayed messages.
5. Revocation of authorization information

I don't think we need the context identifier for 1 since CoAP already
provides for that. DTLS provides for 2,3 and 4 within a session. I don't
think we need more context identifiers for that.

For 5 it should be possible to identify the authorization information so
that they can be revoked. For DCAF we are planning to include this
information in the ticket.

In the object security case, an identifier for the "ticket" containing
the authorization information might work to address 2, 3 and 5. We might
additionally need something to prevent 4.

Best regards,
Steffi

---

From: Derek Atkins <[email-masked]>
Date: Thu, 17 Sep 2015 10:46:34 -0400

If you really NEED a context you could just insert one into one of the
headers, protected or unprotected depending.  You could, for example,
use the Key ID (kid) header.

-derek

Stefanie Gerdes <[email-masked]> writes:

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 17 Sep 2015 17:02:48 +0200

Correct. This is what is typically done. Example: With IKEv2 the
security context is established and in IPsec AH/ESP packets you find
this key id in the form of an SPI.

---

From: Göran Selander <[email-masked]>
Date: Thu, 17 Sep 2015 17:42:36 +0000

Right. And that’s exactly what I want to do in the more compact
COSE_encrypted message format.

---

From: Göran Selander <[email-masked]>
Date: Thu, 17 Sep 2015 17:55:27 +0000

Hi Steffi, 

Here is one example: CoAP server serving multiple clients, (forward) proxy
between clients and server. DTLS doesn’t give end-to-end security, so we
use object security. How does the server know from which client the
request comes from? One way is to have an identifier identifying something
like client/key/context/token/ticket/etc.

Hope that helps,
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 17 Sep 2015 20:06:58 +0200

Hi Göran,

> like client/key/context/token/ticket/etc.

Thank you for the example. Okay, so you are only discussing the object
security solution part.

I guess your example refers to item 3 in the list I send: The server
needs to know if a received request belongs to an existing context and
use the respective keying material etc for its answer? Sounds reasonable
to me that we would need some kind of identifier for that. Is that what
you were discussing about?

Best regards,
Steffi

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 17 Sep 2015 14:37:57 -0700

> Sent: Thursday, September 17, 2015 12:55 AM

I must be slipping - normally I argue from about 5 or 6 positions at the same time.

> 
> COSE_Encrypted format, without mandatory recipient structure, is a good step
> towards a more optimized format. The main disagreement seems to be on the
> option to use a context identifier in the header.

That is not really the focus of what I am trying to do right now.  I am mostly responding to your comments about this saying it is not fixed yet.  I want to try and figure out what information is already available, what information has to be transmitted in what messages, what are the  scenarios that I don't understand at this point in time that change the information that is running around already.  This means that I have outlined why I don't think that context identification is required on a number of places.  A response of - but it would be nice to have - is not helping me understand the real problem of when it is required and when it can be inferred.

This is part of why I am trying to see a solid, and complete, architecture document that covers as much as possible.  Understanding what needs to be done and who is going to talk to whom is difficult if it is not in a single (or very small number) of documents that can read.

> signature/MAC). All these could be one common format.

Being only slightly snarky - it sounds as though you should write a competing COSE proposal that can be thoroughly discussed since you apparently do not like the one that I have put forward.  

> >> The request in general needs a context identifier. Your proposal is
> >>to use the  COSE_enveloped format, my proposal is to allow an optional
> >>context identifier  in the COSE_encrypted format, which is more
> >>compact.
> >>
> >> If you associate the CoAP Token of a request to the context then you
> >>can use  that as an index for context identifier in the response and
> >>hence use  COSE_encrypted. But now you have two parameters that
> >>perform a similar
> >> task: Token and Context Identifier, and which both has to be
> >>transferred in a  request. The Token field is variable length 0-8
> >>bytes. Since we cannot attribute  any end-to-end security properties
> >>of Token, the object security scheme is made  independent of how the
> >>Token is set, analogously to the case in DTLS.
> >>By instead
> >implicitly protected as the message will fail to validate if you use
> >the wrong context.  This means that it is protected even if it is not
> >part of the message properties.  Having the context identified by the token is
> >there is no explicit context identifier anywhere.  It is totally based
> >on the four-tuple of addresses and ports.  This has zero cryptographic
> I don’t claim that omitting the context identifier is insecure. But it is not always
> feasible e.g. in requests, and it has impact on processing and size of other
> parameters such as CoAP Token.

I don't understand what you are trying to say.  It does not make any sense to me.

> 
> 
> >
> >>
> >> I’m not convinced with the difference between how the message is
> >>formatted  depending on whether it is a request or response. A given
> >>node may send the  same resource representation as PUT request or GET
> >>response and thus would  use different COSE message formats.
> >
> >uniquely for each message sent, I don't know that this is a problem.
> >How the COSE is created is based on the http-like operation that is
> >being used.  This will be well understood when it occurs and when it
> >does not occur.
> 
> It is possible to use different COSE formats for request and response but in the
> case I mentioned when the same resource representation for potentially the
> same comsumer is using a different format and of different size depending on
> whether it is PUT request or GET response, that just doesn’t sound like a good
> idea.

Are you planning to build these at the same time?  Are you not going to have any other differences in the data than just the content of the encrypted message.  I don't understand why you think this is a big argument.  I don't know how much you are planning to keep this information around on the system and send it under different operations.   I just don't understand why this is a problem

> >> For example, in Information-Centric Networking, if I’m not mistaken,
> >>unique name.
> >>By
> >> shifting focus from a context identifier within the COSE object to
> >>Token which is  ephemeral data outside the COSE object, ICN
> >If you are correct, and the unique name is always known to both
> >parties, then it is quite possible that you have a situation where the
> >context information can always be implicit and would not need to be
> >carried at all.
> 
> As far as I understand ICN I believe the name should be bound / possible to
> derive from the information object. But we could leave this to the ICN experts to
> comment on. I just note that there may be a significance whether identification
> is provided by the object itself or if it requires additional data (such as Token and
> URI).
> 

Yes - but understanding what can and cannot be relied on will affect our discussions and thus needs to be determined.  Are there ICN experts on this list?

> >>uniqueness is  needed in request and response, so would be in the
> >>header of both  COSE_enveloped and COSE_encrypted.
> >
> Another way to think of this is in terms of sender, which is what we use context
> identifier for.
> If the sender context is identified, each recipient can find out for itself if and
> how to make use of the object. One important assumption is that the sender
> does not have to know anything about the recipient. The sender could rely on a
> trusted third party, to provide it with the right security context it will use, and
> which also will interact with the recipient.

Yes from my point of view this is a purity discussion - it is also not one that needs to be made yet.

> 
> 
> >However, there is an interesting question if you want this in the COSE
> >world or in the CoAP world and just protect it in COSE.  Having two
> >different replay protection systems in place may be overkill.
> 
> The sequence number etc. should be protected in COSE. As far as I understand,
> the only place to for sequence number etc. in COSE_encrypted is in the header.
> But the verification of replay protection belongs to the application. Different
> replay protection mechanisms may be used depending on application, e.g.
> sliding window or strict order.

No - please look at the externally suppled data in the COSE spec.

> >> >> >potentially different in the case where the client is being used
> >> >> >to relay information to the server about the authorization information.
> >> >>
> >> >> Using the current COSE encrypted message structure is not
> >> >> addressing the concerns about message size as has been discussed
> previously.
> >> >>should allow for the desired  identification and optimization for
> >> >>the most common settings. Something
> >> >>like:
> >> >>
> >> >> In fact, to get replay protection of request, and of response if
> >> >>no prior request  bound to the response, one of the fields in the
> >> >>context. It seems odd to not allow an  identifier of what context
> >> >>this nonce/etc. refers to.
> >> >>
> >> >>
> >> >> >
> >> >> >The response does not appear to need a context identifier as
> >> >> >there is already information in the CoAP message that can be used
> >> >> >for determining the context.
> >> >>
> >> >cases that between these two fields the request and the response
> >> >cannot be associated?
> >>
> >> I believe matching CoAP Token in request and response would be
> >>sufficient,  although the Token in itself can’t be integrity protected
> >>in transfer since it may  be changed by a proxy.
> >>
> >> >
> >> >>
> >> >> The context may be different for request and response, and always
> >> >> is in OSCOAP.
> >> >
> >> >Please note that I am using context in the same way that TLS uses
> >> >this term.  This means that the information is going to be different
> >> >for the two directions, but the context identifies a single set of information.
> >> >
> >> >> >observe dialog structure as well, the token can be used to
> >> >> >associate all items in the same context.
> >> >>
> >> >> Even if there are cases where leaving out context in response
> >> >>could be  performed, I think it should be allowed to specify
> >> >>context as an
> >>option.
> >> >tried.  I have only come up with one so far, assuming that one is
> >> >going to use distinct address/port pairs for the multi-cast case.
> >> >That would be the case of subscribing.
> >>
> >> >> >different ways to look at how it can be setup.  The big question
> >> >> >is if the context is going to be unique to the originator, or it
> >> >> >is unique to the subscription.
> >> >> >original subscription.  In that case a context associated with
> >> >> >the data storage server is going to be needed.  However, once
> >> >> >information starts flowing back to the client from the data
> >> >> >storage service, the context associated with the origination
> >> >> >server is going to be used.  It is not clear that the action of
> >> >> >doing the subscription would need to be encrypted,  this
> >> >> >simplified things as only one encryption context is now needed.
> >> >> >Otherwise either two contexts need to be tried, or the type of
> >> >> >message needs to be known so that the client understand where the
> >> >> >encrypted content
> >>originates.
> >> >>
> >> >> The data store need not be trusted. Information about binding
> >> >>between different contexts needs to be obtained from a trusted
> >> >>party, such as the  authorization server. I believe the presence of
> >> >>a context identifier would simplify  the processing where this type
> >> >>of binding needs to be established after the  message has been
> >> >>received, compared to the case of receiving an encrypted  structure
> >> >>without any handle whatsoever.
> >> >
> >> >In my analysis I did not make any assumptions that the data store
> >> >was trusted to do anything more than its assigned job.  I did not
> >> >make any assumptions that it would do cryptography except for
> >> >messages sent directly to it.
> >>
> >> >However, since we do not have a sketched protocol for getting keys
> >> >yet it is hard to be sure.  Even if you have current keys you will
> >> >still need to be able to get updated keys when the epoch rolls over
> >> >to the next value.  This means that the two cases are going to be
> >> >very
> >>similar.
> >>
> >> I was thinking of a case when the receiving node actually has the
> >>relevant  context, but since there is no context identifier cannot
> >>determine this is the case  before doing a look-up of what context is
> >>valid for this resource.
> >>
> >> >
> >> >>
> >> >> >
> >> >> >For the case of multicast, it appears to me that the context can
> >> >> >be inferred in most cases.  I would assume that a context is
> >> >> >going to be signed to each multicast address, port pair.  I would
> >> >> >also assume that this would be a unique assignment in that
> >> >> >multiple contexts would not be assigned.  This does allow for any
> >> >> >node which has the context to send out a multicast message
> >> >> >without a problem.  The more interesting question is what to do
> >> >> >with the unicast responses to a multicast message.  Should they
> >> >> >be encrypted with the multicast group context, in which case the
> >> >> >message id/token on the message is sufficient to identify the
> >> >> >context.  Or should they be encrypted with a unicast key pair
> >> >> >between the replier and the original
> >>message sender?
> >> >> >This implies that such a key context needs to be setup for each
> >> >> >such link which may or may not be the case.  In this event it
> >> >> >might be necessary to identify the context that was used to
> >> >> >encrypt the unicast message.  I have not managed to think this
> >> >> >through far
> >>enough.
> >> >> >
> >> >> >In any event, there appear to be enough cases where the
> >> >> >encryption context can be inferred from the message to make it
> >> >> >reasonable to have a version of COSE messages which do not have
> >> >> >any recipient information attached to them.
> >> >> >I am interested in people looking at my analysis and tell me if I
> >> >> >am right, wrong or unclear.
> >> >>
> >> >>
> >> >>COSE_encrypted format would solve the  problem. For replay
> >> >>protection, some context information such as sequence  number/nonce
> >> >>needs anyway to be transferred, so I would say that the context
> >> >replay protection as much as it is needed for making sure that IVs
> >> >are not re-used.  This could potentially be different from the
> >> >sequence number used for replay protection but generally would not be.
> >>
> >> Agree.
> >>
> >> >
> >> >I would expect that you would never want to send information you do
> >> >not have to since it only adds size.  But still trying to figure out
> >> >where it is and is not needed to have a context identifier to begin with.
> >> >Then we can figure out where and if it makes sense to include it.
> >> >But at that point you are already talking about taking size hits.
> >>
> >>always, not  for free, and also may lead to some IMHO confusing
> >>constraints such as  different message formats for request and
> >>response.
> >>
> >> As I understood one reason why COSE_encrypted was introduced was to
> >>meet a  request for a more compact format in settings where context is
> >>already  established. Not sending context identifier may be an
> >>optimization in some  settings, but that format would be of much less
> >>use if a context identifier cannot  be included.
> >>
> >>
> >> Göran
> >

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 17 Sep 2015 14:40:32 -0700

Derek,

Yes you can, but it needs to be checked how much this will change the security analysis by doing thing which might be unexpected.

I cannot prevent them from doing this, I can only say that it is not the way that I designed the system.  I am far more worried about the fact that I am not sure that they currently understand the problem that is being solved, what the needed security properties are and what the required, as oppose to nice to have, information is in all cases.   I.e. what can be inferred as oppose to being explicit.

Hopefully the solution space will be easier to fill in once the actual set of use cases and architecture is understood. 

Jim

> From: Derek Atkins [mailto:[email-masked]]
> Sent: Thursday, September 17, 2015 7:47 AM
> To: Stefanie Gerdes <[email-masked]>
> Cc: Göran Selander <[email-masked]>; Jim Schaad
> <[email-masked]>; [email-masked]
> If you really NEED a context you could just insert one into one of the headers,
> protected or unprotected depending.  You could, for example, use the Key ID
> (kid) header.
> 
> -derek
> 
> > 3. The server needs to know if a received request belongs to an
> > existing context and use the respective keying material etc for its answer.
> > Other:
> > provides for that. DTLS provides for 2,3 and 4 within a session. I
> > don't think we need more context identifiers for that.
> >
> > For 5 it should be possible to identify the authorization information
> > so that they can be revoked. For DCAF we are planning to include this
> > the authorization information might work to address 2, 3 and 5. We
> > might additionally need something to prevent 4.
> >
> > Best regards,
> > Steffi
> >

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 17 Sep 2015 14:41:54 -0700

> From: Stefanie Gerdes [mailto:[email-masked]]
> Sent: Thursday, September 17, 2015 11:07 AM
> To: Göran Selander <[email-masked]>; Jim Schaad
> > Here is one example: CoAP server serving multiple clients, (forward)
> > proxy between clients and server. DTLS doesn’t give end-to-end
> > security, so we use object security. How does the server know from
> > which client the request comes from? One way is to have an identifier
> > identifying something like client/key/context/token/ticket/etc.
> 
> Thank you for the example. Okay, so you are only discussing the object security
> solution part.
> 
> I guess your example refers to item 3 in the list I send: The server needs to know
> if a received request belongs to an existing context and use the respective
> keying material etc for its answer? Sounds reasonable to me that we would need
> some kind of identifier for that. Is that what you were discussing about?

This is part of the discussion.  You are current in the original analysis that DTLS has this implicitly known.  I believe that in many cases this will also be true for the object version as well.  

Jim

---

From: Göran Selander <[email-masked]>
Date: Fri, 18 Sep 2015 07:50:31 +0000

>I must be slipping - normally I argue from about 5 or 6 positions at the

:-)

>>step
>That is not really the focus of what I am trying to do right now.  I am
>mostly responding to your comments about this saying it is not fixed yet.
> I want to try and figure out what information is already available, what
>information has to be transmitted in what messages, what are the
>scenarios that I don't understand at this point in time that change the
>information that is running around already.  This means that I have
>outlined why I don't think that context identification is required on a
>number of places.  A response of - but it would be nice to have - is not
>helping me understand the real problem of when it is required and when it
>can be inferred.

Say we are going to implement a security protocol for a sensor
device/resource server. Should we restrict to a particular deployment? Or
would we like the code to work even if there is more than one client and
potential intermediate nodes (as in the example just mentioned)? I think
both these cases are valid. If we go for the latter, then following your
reasoning we cannot use the compact COSE_encrypted format in the requests.

Is this a real problem? I think it is a problem if we design a compact
format such that is not supposed to be used in a reasonable set of use
cases.

>
>This is part of why I am trying to see a solid, and complete,
>architecture document that covers as much as possible.  Understanding
>what needs to be done and who is going to talk to whom is difficult if it
>is not in a single (or very small number) of documents that can read.
>
>> 
>Being only slightly snarky - it sounds as though you should write a
>competing COSE proposal that can be thoroughly discussed since you
>apparently do not like the one that I have put forward.

Well, I think I said several times that I do like the message formats. I’m
not arguing against COSE_enveloped as the generic protocol. I’m commenting
about details of the optimized format. And I think a similar format as
COSE_encrypted could more or less directly apply to the other settings,
such as integrity-only. Assuming the compact format is something like:

[ message_type, header, body, tag ]

then body=ciphertext would cover the case of encryption + integrity
protection, as in COSE_encrypted, whereas body=payload would cover the
case of integrity protection only. Or making these two separate message
types to allow a proxy to understand from message type if it can read the
body.

>I don't understand what you are trying to say.  It does not make any

I was trying to summarize the explanation above, that relying on Token as
an indication of context takes away some of the effects of optimization
given by the compact format of COSE_encrypted. But you can disregard that
if you like.

>Are you planning to build these at the same time?  Are you not going to
>have any other differences in the data than just the content of the
>encrypted message.  I don't understand why you think this is a big
>argument.  I don't know how much you are planning to keep this
>information around on the system and send it under different operations.
> I just don't understand why this is a problem

An endpoint could change between publishing values and respond to specific
access requests. It would thus have to use use different message formats.
Is this a real problem? I think this difference in message formats that
are allowed to use for request and response creates unnecessary complexity.

>Yes - but understanding what can and cannot be relied on will affect our
>discussions and thus needs to be determined.  Are there ICN experts on
>this list?
>
>
>> >
>> >>
>>itself if and
>>understand,

I was actually going to comment on that first paragraph of section 4.1.
You are right that integrity protecting some unencrypted CoAP options was
the reason for using detached content. But there are no existing or
proposed CoAP options containing transaction identifiers or nonces. This
data is proposed (in the object security draft) to go into the COSE
protected header. 

What might have confused you is that the transaction identifier of the
*CoAP request* is externally supplied data (not sent) of
the CoAP response, to achieve the secure binding between request and
response.  But the response contains its own transaction identifier in the
COSE protected header.

---

From: Olaf Bergmann <[email-masked]>
Date: Sun, 20 Sep 2015 11:44:38 +0200

>> Subject: Re: [Ace] Looking at COSE based unicast and multicast

[...]

>> needs to know
> This is part of the discussion.  You are current in the original
> analysis that DTLS has this implicitly known.  I believe that in many
> cases this will also be true for the object version as well.

This would also be my goal as a COSE user as it not only saves precious
bandwidth but also helps minimizing complexity.

Grüße
Olaf