Subject: [core] Comments on draft-ietf-core-object-security-00

From: Jim Schaad <[email-masked]>
Date: Thu, 1 Dec 2016 13:00:20 -0800

Section 3 - I like the fact that the security context is being defined,
however I question the wisdom of including the sections on how to derive a
context from a shared secret at this point.  I think it would make more
sense to put this into the EDHOC document, and if you do not do that then to
at least move this into an appendix.  I do not believe that this is/should
be the only method to populate a context.  I would hope that a method of
doing so from a CWT will be defined as that may have the advantage of
getting more controlled random numbers.  From a security analysis point of
view, there is no difference between get the shared secret used here or the
actual keys from a third party.  There is a difference if EDHOC is used.

Section 3.1 - I would think that you might be better off having the Cid be
potentially different between the sender and receiver.  Currently the
closest you get in EDHOC would be to use the nonces, which are too long to
be used here.  

Section 3.1 - Base Key should be Shared-Secret.  The term key generally
indicates that there are some additional restrictions which would not apply
in this case - an example would be key lengths.  It is also possible that
somebody could incorrectly believe that an asymmetric key could somehow
work.

Section 3.1 - In principle, the algorithm could be different between the
sender and receiver context.  I am not sure that I would disallow this in
defining your context structure.

Section 3.1 - If Base Key and the IDs are not needed once the security
context has been setup, remove them from the definition of the context and
just make them pre-requests for the context algorithm creation you are
defining.

Section 3.1 - Do not use the word signed when talking about authenticated
data.  The operations are not even close to being the same thing from a
cryptographic point of view.

Section 3.1 - make the last paragraph look more like 
" The client and server may change roles while maintaining the same security
context.  When this happens, the former server still makes use of its Sender
Context when sending messages and Recipient Context when receiving messages.
The same is also true for the former client.  In other words, changing the
roles does not change the set of keys to be used."

Section 3.2 - The term "in a previous phase" is probably a poor choice of
words.  The term phase implies to me to be part of what we are currently
done, but that is not defined.  Just kill the clause.

Section 3.2 - Why is the replay window an input - this seems to be odd as
you would not pre-fill part of the window.  I assume this is really just the
Replay Window Size.

Section 3.2.1 - The method of creating info is insufficiently defined.  The
current method does not correctly separate the different fields that are
used to build it.

Section 3.2.3 - 64 bits for the Cid seems to be very long.  You are not
being consistent with your discussion in Appendix A.4 where the Cid is only
32-bits.  32-bits is much more likely value to be used, in some cases it may
be only 16-bits.

Section 3.2 - I would like to see a justification of using the Tid as a
value that needs to be authenticated as part of the message.  I don't see it
in this anyplace.  It should be part of a security argument.

Section 3.2.3 - The last paragraph talks about what EDHOC does.  This has
two problems, first this should be in that document rather than here and
second you are talking about using a 256-bit or 512-bit value which is even
longer than you are documenting as being "normal"

Section 3.2.3 - You are getting ahead of yourself.  The only way that the
identifiers would not be unique would be if the sender and recipient
collided.  I do not know that this would be a problem and therefore talking
about it makes no sense.  I am assuming that this is supposed to have
something to do with the multicast work that I have not looked at.  If so it
does not belong here but there.

Section 4 - I do not understand the processing of a Proxy-Uri.  Do you end
up with a Proxy-Uri or not?  The sentence is not clear.

Section 5.2 - Why make code a bstr and not an uint?  It is a small integer
value

Section 52 - Why make alg a bstr and not an (int / tstr)?  This more
directly maps what the value is.

Section 5.2 - why not make the transaction-id be three separate fields?
This makes the field separation clearer.

Section 5 - You have defined a 'sid' and said that it could be placed in the
unprotected field, however you have also said that the unprotected field
must be empty.  These statements are contradictory.

Section 2 - We had a discussion at one point about using the code as the key
for the question of payload being present in a document.  Specifically, one
could do a put with an empty payload.  In that case the version of the
Object-Security Option should be the one with payload. --- This is not done
well in section 2 but is in section 6.2

Section 6.1 - The reject limit on sequence number is defined as algorithm
specific rather than being a fixed constant.

Section 6.1 - If OSCOAP is a challenge-response, how can one observer?  That
would be challenge-response-response-response.  Is the Tid supposed to be
kept until one kills the observation?  If so that should be highlighted.

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 2 Dec 2016 08:50:32 +0100

Hello Jim,

thank you for you detailed review. Some answers and follow-up questions 
inline, I'm sure Göran and Francesca will address the rest.

/Ludwig

> closest you get in EDHOC would be to use the nonces, which are too long to
Not sure what you mean here, if the Cid is different between sender and 
receiver, how does the receiver retrieve the right OSCOAP context?

> just make them pre-requests for the context algorithm creation you are

I don't quite agree, but I'm willing to be convinced otherwise if 
someone has a better idea.

Right now my plan is to use Sender ID + Cid as subject identifier for 
CWTs that use OSCOAP for proof-of-possession. Wouldn't that be a good 
case for keeping this id?

> you would not pre-fill part of the window.  I assume this is really just the
Yes

> up with a Proxy-Uri or not?  The sentence is not clear.
The description is not clear here indeed, I think the text got garbled 
in some update

The idea was this:

If you have Proxy-URI=example.com:5683/sensors/temp.xml?time=90 (and 
Proxy-Scheme=coap, which is left unchanged) this is split into:

Proxy-Scheme=coap           (AAD)
Proxy-Uri=example.com:5683  (AAD)
Uri-Path=sensors       (Encrypted)
Uri-Path=temp.xml      (Encrypted)
Uri-Query=time=90      (Encrypted)

/Ludwig

> would be challenge-response-response-response.

That was indeed the intention, but writing it that way seemed a bit 
silly. We should write it out instead.

-- 
Ludwig Seitz, PhD   SICS Swedish ICT AB
Ideon Science Park, Building Beta 2
Scheelevägen 17, SE-223 70 Lund
Phone +46(0)70-349 92 51

The RISE institutes SP, Swedish ICT and Innventia are merging in order 
to create a unified institute sector and become a stronger innovation 
partner for businesses and society. At the end of the year we will 
change our name to RISE. Read more at www.ri.se/en/about-rise

---

From: Jim Schaad <[email-masked]>
Date: Fri, 2 Dec 2016 00:00:29 -0800

> -----Original Message-----
> From: Ludwig Seitz [mailto:[email-masked]]
> Sent: Thursday, December 01, 2016 11:51 PM
> To: Jim Schaad <[email-masked]>; draft-ietf-core-object-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: Comments on draft-ietf-core-object-security-00
> 
> Hello Jim,
> 

Foreach (Context ctx : AllContexts) {
   If (ctx.receiver.Cid == CidInmessage) TestDecrypt();
}

The difference betwee "ctx.Cid" and "ctx.receiver.cid" is not very big.

> case for keeping this id?

It might be, but I am not sure what you think you are doing here and if you
are planning to put this into this document or into a later document.  I am
less worried about the IDs than the base key under the rubric of kill a
security item as soon as you don’t need it.  It looks like at least one of
the IDs is used are part of the Tid so keeping it might make sense if there
is a valid reason for thinking that is a necessary item to authenticate.

> Uri-Query=time=90      (Encrypted)

I need to re-read how proxies work, but that makes sense to me.

By the way - I did update the JAVA version of COSE, I don't know if you
noticed.

Jim

---

From: Francesca Palombini <[email-masked]>
Date: Fri, 2 Dec 2016 10:42:21 +0000

Jim,

Thank you so much for a detailed review!

Before answering inline, please note that some of these comments were already taken care of in the latest version (commit 30475e3 in the github https://github.com/core-wg/oscoap ), updated yesterday (1st of December).
 
Francesca

> From: core [mailto:[email-masked]] On Behalf Of Jim Schaad
> Sent: den 1 december 2016 22:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: [core] Comments on draft-ietf-core-object-security-00
> 
> Section 3 - I like the fact that the security context is being defined, however I
> question the wisdom of including the sections on how to derive a context
> from a shared secret at this point.  I think it would make more sense to put
> this into the EDHOC document, and if you do not do that then to at least
> move this into an appendix.  I do not believe that this is/should be the only
> method to populate a context.  I would hope that a method of doing so from
> a CWT will be defined as that may have the advantage of getting more
> controlled random numbers.  From a security analysis point of view, there is
> no difference between get the shared secret used here or the actual keys
> from a third party.  There is a difference if EDHOC is used.
> 
> potentially different between the sender and receiver.  Currently the closest
> you get in EDHOC would be to use the nonces, which are too long to be used
> here.
> 

I am still not 100% sure what you mean here. Do you mean discard the use of Cid and only use Sender ID and Recipient ID to retrieve the right contexts? This creates problems with the current text since the Cid should be globally unique and the Sender/Recipient ID only locally unique. What would be the advantage of using Recipient ID instead of Cid?

> indicates that there are some additional restrictions which would not apply in
> this case - an example would be key lengths.  It is also possible that

Good point. What about using Master Secret? (Inspired by TLS terminology, it avoids overlapping with EDHOC terminology)

> defining your context structure.

Point taken. If there is use case/interest for this, we may consider adding this, but for simplicity reasons we think that request and response should be protected with the same algorithm.

> just make them pre-requests for the context algorithm creation you are

About the IDs, the Sender/Recipient ID need to be kept since it is used in the AAD. We can remove the Base Key.

> cryptographic point of view.

Yes, this was removed in latest revision (commit 30475e3)

> Section 3.1 - make the last paragraph look more like " The client and server
> may change roles while maintaining the same security context.  When this
> happens, the former server still makes use of its Sender Context when
> sending messages and Recipient Context when receiving messages.

Ok, we will integrate your proposal into the updated version (at line 237 of the md document).

> done, but that is not defined.  Just kill the clause.

Agreed (true for the 4 occurrences).

> Section 3.2 - Why is the replay window an input - this seems to be odd as you
> would not pre-fill part of the window.  I assume this is really just the Replay
> Window Size.
> 

Ok (changed in updated version)

> current method does not correctly separate the different fields that are used
> to build it.
> 

Ok (also changed)

> Section 3.2.3 - 64 bits for the Cid seems to be very long.  You are not being
> consistent with your discussion in Appendix A.4 where the Cid is only 32-bits.
> 32-bits is much more likely value to be used, in some cases it may be only 16-
> bits.
> 

64 is just a recommendation. We did add text about shorter Cid (line 289 of the md doc).

> Section 3.2 - I would like to see a justification of using the Tid as a value that
> needs to be authenticated as part of the message.  I don't see it in this
> anyplace.  It should be part of a security argument.
> 

We did add some text in line 209 "The Tid is part of the Additional Authenticated Data (AAD, see {{sec-obj-cose}}) of the protected CoAP response message, which is how responses are bound to requests.", is this not enough?

> longer than you are documenting as being "normal"

Right, this was removed.

> identifiers would not be unique would be if the sender and recipient collided.
> I do not know that this would be a problem and therefore talking about it
> makes no sense.  I am assuming that this is supposed to have something to
> do with the multicast work that I have not looked at.  If so it does not belong
> here but there.
> 

The new updated version say "SHALL be unique", as any collisions may lead to loss of both confidentiality and integrity.

> Section 4 - I do not understand the processing of a Proxy-Uri.  Do you end up
> with a Proxy-Uri or not?  The sentence is not clear.
> 

We will try to clarify this. We do reference CoAP processing though, so I don't really see how we could improve here.
 
> Section 5.2 - Why make code a bstr and not an uint?  It is a small integer

Right, we'll change this.

> Section 52 - Why make alg a bstr and not an (int / tstr)?  This more directly
> maps what the value is.
> 

Changed too.

> This makes the field separation clearer.

Done too. Please check section 5.2 again.

> must be empty.  These statements are contradictory.

Now we have moved the 'sid' definition as a COSE Header before. The idea is that we need to define the 'sid' COSE Header, and for security purposes this _can_ be placed in the unprotected Header (as 'kid'), but in our application the 'sid' is protected. I don't see how these are contradictory. 

> could do a put with an empty payload.  In that case the version of the Object-
> Security Option should be the one with payload. --- This is not done well in
> section 2 but is in section 6.2
> 

Right. We will change this.

> specific rather than being a fixed constant.

Yes. Is this a problem? TLS 1.3 also makes this algorithm specific, if I'm not wrong.
And wouldn't make more sense to have all limits in COSE, rather than in OSCOAP?

> Section 6.1 - If OSCOAP is a challenge-response, how can one observer?
> That would be challenge-response-response-response.  Is the Tid supposed
> to be kept until one kills the observation?  If so that should be highlighted.
> 
> 

There are unique responses bound to each challenge. In case of observe, yes, the Tid (in the AAD) is supposed to be the same for all the responses.

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

---

From: Göran Selander <[email-masked]>
Date: Fri, 2 Dec 2016 13:28:45 +0000

The comment we didn’t respond to in the previous mail:

>actual keys from a third party.  There is a difference if EDHOC is used.

In a previous version of the draft we did exactly that - define the
security context but not how to arrive at it. This raised some questions,
and we decided that having essentially a shared base key / master secret
seemed to be a much more natural starting point for OSCOAP, and these
parameters could be obtained from EDHOC, ACE, TLS, or whatever. Since
EDHOC is not the only key exchange protocol that can be used with OSCOAP,
the derivation of the security context must be included in this draft.

I don’t understand the part "getting more controlled random numbers” since
there no element of randomness in the derivation. What is the advantage of
having multiple ways to derive the security context?

Your mentioning of CWT, is that referring to its use as access token in
ACE? If so, the CWT could contain a symmetric POP-key and some other
claims and fit natural into the current writing.

I see more issues from a constrainedness point of view to transport a
large security context than to derive the security context on board.

Assuming that we keep the shared key etc. as starting point for OSCOAP, it
also makes sense to keep the derivation of the security context in the
body.

Göran

---

From: Jim Schaad <[email-masked]>
Date: Fri, 2 Dec 2016 17:50:55 -0800

> From: Göran Selander [mailto:[email-masked]]
> Sent: Friday, December 02, 2016 5:29 AM
> >however I question the wisdom of including the sections on how to
> >derive a context from a shared secret at this point.  I think it would
> >make more sense to put this into the EDHOC document, and if you do not
> >do that then to at least move this into an appendix.  I do not believe
> >that this is/should be the only method to populate a context.  I would
> >hope that a method of doing so from a CWT will be defined as that may
> >have the advantage of getting more controlled random numbers.  From a
> >security analysis point of view, there is no difference between get the
> >shared secret used here or the actual keys from a third party.  There
> >is a difference if EDHOC is used.
> 
> In a previous version of the draft we did exactly that - define the security
> context but not how to arrive at it. This raised some questions, and we decided
> that having essentially a shared base key / master secret seemed to be a much
> more natural starting point for OSCOAP, and these parameters could be
> obtained from EDHOC, ACE, TLS, or whatever. Since EDHOC is not the only key
> exchange protocol that can be used with OSCOAP, the derivation of the security
> context must be included in this draft.
> 
> 

Both EDHOC and TLS (depending on who you talk to) require that you have a level of random numbers that might or might not be well suited to a constrained device where you can get into situations that either you don't have a good source, or when you re-start you end up with the same stream.  Only going with ACE tokens can you be ensured of having a good source of randomness for these cases.  
> 
> 
> Your mentioning of CWT, is that referring to its use as access token in ACE? If
> so, the CWT could contain a symmetric POP-key and some other claims and fit
> natural into the current writing.

Yes, that is what I was thinking of.  I agree that it can hold the symmetric POP-key, however it can also equally well hold the entire security context.  In some cases this will be far more preferred to than doing the key derivation steps.  One case where this would be true is if you are doing multicast.  As part of the join response, the token could return the full set of items that are needed.  This could be either just the receive fields, if no responses are going to need to be sent back, or both the send and receive fields.  If both sets of fields are sent back, then it is not possible for to try and generate a new set of keys for a different end point that is part of the multi-cast.   You have very different security properties in these cases.

> 
> I see more issues from a constrainedness point of view to transport a large
> security context than to derive the security context on board.

It will depend on what security properties you want.

> 
> Assuming that we keep the shared key etc. as starting point for OSCOAP, it also
> makes sense to keep the derivation of the security context in the body.

I think it makes more sense to move to an appendix.

Jim

---

From: Jim Schaad <[email-masked]>
Date: Fri, 2 Dec 2016 19:34:45 -0800

> From: Francesca Palombini [mailto:[email-masked]]
> Sent: Friday, December 02, 2016 2:42 AM
> To: Jim Schaad <[email-masked]>; 'Ludwig Seitz' <[email-masked]>;
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [core] Comments on draft-ietf-core-object-security-00
> 
> Jim,
> 
> Before answering inline, please note that some of these comments were
already
> taken care of in the latest version (commit 30475e3 in the github
> https://github.com/core-wg/oscoap ), updated yesterday (1st of December).
> 
> Francesca
> 
> > Section 3 - I like the fact that the security context is being
> > defined, however I question the wisdom of including the sections on
> > how to derive a context from a shared secret at this point.  I think
> > it would make more sense to put this into the EDHOC document, and if
> > you do not do that then to at least move this into an appendix.  I do
> > not believe that this is/should be the only method to populate a
> > context.  I would hope that a method of doing so from a CWT will be
> > defined as that may have the advantage of getting more controlled
> > random numbers.  From a security analysis point of view, there is no
> > difference between get the shared secret used here or the actual keys
from a
> third party.  There is a difference if EDHOC is used.
> >
> > Section 3.1 - I would think that you might be better off having the
> > Cid be potentially different between the sender and receiver.
> > Currently the closest you get in EDHOC would be to use the nonces,
> > which are too long to be used here.
> >
> 
> I am still not 100% sure what you mean here. Do you mean discard the use
of
> Cid and only use Sender ID and Recipient ID to retrieve the right
contexts? This
> creates problems with the current text since the Cid should be globally
unique
> and the Sender/Recipient ID only locally unique. What would be the
advantage
> of using Recipient ID instead of Cid?
>

Remember that I don't believe in global uniqueness of Cid values.  No I do
not mean to discard the IDs and replace the Cid with them.  I think that you
might be in a situation where you have the same IDs but different Cids when
talking to the same server.  This would be a situation where you have
different ACLs that were established with different secrets.  However, if
the Cid value is locally unique then the value would be different on the two
different sides rather than shared.  Thus EDHOC could send not only IDs,
which would correspond to ACLs but also a locally unique Cid can be enforced
where a global unique one cannot.

> > Section 3.1 - Base Key should be Shared-Secret.  The term key
> > generally indicates that there are some additional restrictions which
> > would not apply in this case - an example would be key lengths.  It is
> > also possible that somebody could incorrectly believe that an
> > asymmetric key could somehow work.
> >
> 
> Good point. What about using Master Secret? (Inspired by TLS terminology,
it
> avoids overlapping with EDHOC terminology)

Works for me.

> 
> > Section 3.1 - In principle, the algorithm could be different between
> > the sender and receiver context.  I am not sure that I would disallow
> > this in defining your context structure.
> >
> 
> Point taken. If there is use case/interest for this, we may consider
adding this,
> but for simplicity reasons we think that request and response should be
> protected with the same algorithm.

I agree that they are almost always going to be the same, but there is a
difference between saying that and enforcing that by where you put the
algorithm in the context.  Another place where this might come in is that
you could have a <recipient encrypt> and a <recipient signer> field in the
context.  In this case the algorithms are going to be going to be different,
but it is still useful to think of them as parts of the same security
context

> > context has been setup, remove them from the definition of the context
> > and just make them pre-requests for the context algorithm creation you
> > are defining.
> >
> 
> About the IDs, the Sender/Recipient ID need to be kept since it is used in
the
> AAD. We can remove the Base Key.

Is there a security reasoning behind this?

> 
> > Section 3.1 - Do not use the word signed when talking about
> > authenticated data.  The operations are not even close to being the
> > same thing from a cryptographic point of view.
> >
> 
> > Section 3.1 - make the last paragraph look more like " The client and
> > server may change roles while maintaining the same security context.
> > When this happens, the former server still makes use of its Sender
> > The same is also true for the former client.  In other words, changing
> > the roles does not change the set of keys to be used."
> >
> 
> Ok, we will integrate your proposal into the updated version (at line 237
of the
> md document).
> 
> > Section 3.2 - The term "in a previous phase" is probably a poor choice
> > of words.  The term phase implies to me to be part of what we are
> > currently done, but that is not defined.  Just kill the clause.
> >
> 
> > Section 3.2 - Why is the replay window an input - this seems to be odd
> > as you would not pre-fill part of the window.  I assume this is really
> > just the Replay Window Size.
> >
> 
> > Section 3.2.1 - The method of creating info is insufficiently defined.
> > The current method does not correctly separate the different fields
> > that are used to build it.
> >
> 
> Ok (also changed)
> 
> > Section 3.2.3 - 64 bits for the Cid seems to be very long.  You are
> > not being consistent with your discussion in Appendix A.4 where the Cid
is only
> 32-bits.
> > 32-bits is much more likely value to be used, in some cases it may be
> > only 16- bits.
> >
> 
> 64 is just a recommendation. We did add text about shorter Cid (line 289
of the
> md doc).

Right, but if 64 is your recommendation then it should be what you in the
appendixes.

> 
> > Section 3.2 - I would like to see a justification of using the Tid as
> > a value that needs to be authenticated as part of the message.  I
> > don't see it in this anyplace.  It should be part of a security
argument.
> >
> 
> We did add some text in line 209 "The Tid is part of the Additional
Authenticated
> Data (AAD, see {{sec-obj-cose}}) of the protected CoAP response message,
> which is how responses are bound to requests.", is this not enough?

Why is <Cid + sequence #> insufficient?

> 
> > Section 3.2.3 - The last paragraph talks about what EDHOC does.  This
> > has two problems, first this should be in that document rather than
> > here and second you are talking about using a 256-bit or 512-bit value
> > which is even longer than you are documenting as being "normal"
> >
> 
> Right, this was removed.
> 
> > Section 3.2.3 - You are getting ahead of yourself.  The only way that
> > the identifiers would not be unique would be if the sender and recipient
> collided.
> > I do not know that this would be a problem and therefore talking about
> > it makes no sense.  I am assuming that this is supposed to have
> > something to do with the multicast work that I have not looked at.  If
> > so it does not belong here but there.
> >
> 
> The new updated version say "SHALL be unique", as any collisions may lead
to
> loss of both confidentiality and integrity.

Need to look, but I don't think I understand.

> 
> > Section 4 - I do not understand the processing of a Proxy-Uri.  Do you
> > end up with a Proxy-Uri or not?  The sentence is not clear.
> >
> 
> We will try to clarify this. We do reference CoAP processing though, so I
don't
> really see how we could improve here.
> 
> > Section 5.2 - Why make code a bstr and not an uint?  It is a small
> > integer value
> >
> 
> > Section 5 - You have defined a 'sid' and said that it could be placed
> > in the unprotected field, however you have also said that the
> > unprotected field must be empty.  These statements are contradictory.
> 
> Now we have moved the 'sid' definition as a COSE Header before. The idea
is
> that we need to define the 'sid' COSE Header, and for security purposes
this
> _can_ be placed in the unprotected Header (as 'kid'), but in our
application the
> 'sid' is protected. I don't see how these are contradictory.
> 
> >
> > Section 2 - We had a discussion at one point about using the code as
> > the key for the question of payload being present in a document.
> > Specifically, one could do a put with an empty payload.  In that case
> > the version of the Object- Security Option should be the one with
> > payload. --- This is not done well in section 2 but is in section 6.2
> >
> 
> > Section 6.1 - The reject limit on sequence number is defined as
> > algorithm specific rather than being a fixed constant.
> >
> 
> Yes. Is this a problem? TLS 1.3 also makes this algorithm specific, if I'm
not
> wrong.

I was just objecting to having the number at this location not the idea of a
limit.

Jim

> > That would be challenge-response-response-response.  Is the Tid
> > supposed to be kept until one kills the observation?  If so that should
be
> highlighted.
> >
> >
> 
> There are unique responses bound to each challenge. In case of observe,
yes,
> the Tid (in the AAD) is supposed to be the same for all the responses.
> 
> >

---

From: Göran Selander <[email-masked]>
Date: Mon, 5 Dec 2016 08:52:30 +0000

On 2016-12-03 02:50, "Jim Schaad" <[email-masked]> wrote:

>>security
>Both EDHOC and TLS (depending on who you talk to) require that you have a
>level of random numbers that might or might not be well suited to a
>constrained device where you can get into situations that either you
>don't have a good source, or when you re-start you end up with the same
>stream.  Only going with ACE tokens can you be ensured of having a good
>source of randomness for these cases.

Yes ..  but I don’t understand how this impacts the step of doing security
context derivation given an pre-established secret key, which is what I
thought was what the comment was about?

>>ACE? If
>Yes, that is what I was thinking of.  I agree that it can hold the
>symmetric POP-key, however it can also equally well hold the entire
>security context.  In some cases this will be far more preferred to than
>doing the key derivation steps.  One case where this would be true is if
>you are doing multicast.  As part of the join response, the token could
>return the full set of items that are needed.  This could be either just
>the receive fields, if no responses are going to need to be sent back, or
>both the send and receive fields.  If both sets of fields are sent back,
>then it is not possible for to try and generate a new set of keys for a
>different end point that is part of the multi-cast.   You have very
>different security properties in these cases.

I don’t understand. In a symmetric multicast setting the “receive fields”
are essentially the "sender fields" of the node which sent the message. So
even if a node has only “receiver fields” it can masquerade as that
sender. Conversely, if additional asymmetric keys are used, then there is
no issue to be able to derive the symmetric sender context, since only the
sender has its private key.

>>large

What security properties are different between transporting a key and
transporting a derived context? Or do you mean as in the sense above, that
the key can entitle to more things than the context?

>I think it makes more sense to move to an appendix.

OK, we consider that.