Re: [Ace] [Lwip] (protocol flows) Re: EDHOC standardization
Hi Rene, These are interesting ideas. As you say, EDHOC is currently optimized for a minimum number of messages and bytes. Spreading out the bytes and computations could be beneficial in some applications. EDHOC is currently based on SIGMA-I. The four-message variant would be based on SIGMA-R with basically the same security properties. The difference would be that SIGMA-I protects the initiator identity against active attackers and the non-initiator identity against passive attackers. SIGMA-R does the opposite. I think protection models are needed in practice, but could also be solved by letting the initiator telling the other party to start SIGMA-I. Party U Party V | C_U, CIPHER_SUITEs_U, CIPHER_SUITE_U, X_U| +-->| | message_1 | | | | C_U, C_V, X_V | |<--+ | message_2 | | | | C_V, AE(K_3; ID_CRED_U, Sig(U; CRED_U, aad_3) ) | +-->| | message_3 | | | | C_U, AE(K_4; ID_CRED_V, Sig(V; CRED_V, aad_4) ) | |<--+ | message_4 | I get the following message sizes for EDHOC when I apply SIGMA-R to version -11 of EDHOC. Flight#1 #2 #3 #4 Total DTLS 1.3 RPK + ECDHE 150 373213 736 DTLS 1.3 PSK + ECDHE 187 190 57 434 DTLS 1.3 PSK 137 150 57 344 EDHOC RPK + ECDHE (SIGMA-I) 39 120 85 244 EDHOC RPK + ECDHE (SIGMA-R) 39 37 85 84 245 EDHOC PSK + ECDHE 44 46 11 101 Regarding computations, I guess the main difference when it comes to asymmetrical crypto computations would be that Party V can compute a shared secret in between flight #2 and flight #3. Or are the any additional benefits? SIGMA-I: Party U Party V generate a key pair +---#1->| generate a key pair (can be done before #1) compute a shared secret sign |<--#2--+ compute a shared secret verify sign +---#3->| verify SIGMA-R: Party U Party V generate a key pair +---#1->| generate a key pair (can be done before #1) compute a shared secret (can be done between #2 and #3) |<--#2--+ compute a shared secret sign +---#3->| verify sign |<--#4--+ verify The optimization to split up the ECDSA Signature (R, S) and send R in the beginning is interesting, but as far as I understand, this only works for ECDSA and there is no similar trick for Ed25519 as both R and S depends on the message M. SIGMA-I: Party U Party V | C_U, CIPHER_SUITEs_U, CIPHER_SUITE_U, X_U, R_U | +-->| | message_1 | | | | C_U, C_V, X
Re: [Ace] Shepard comments on draft-ietf-ace-oscore-profile
Hi Jim, Here is the update including your comments. It also includes minor comments from Marco (thanks!) that we had missed before. https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-ace-oscore-profile.txt&url2=https://ace-wg.github.io/ace-oscore-profile/draft-ietf-ace-oscore-profile.txt Concerning the error caused by unrecognized fields in the OSCORE_Security_Context, I only defined that for the RS: in fact, the client does not validate the token, so stopping the processing because of an unrecognized field would open up for easy DoS attacks by intermediaries. If the AS actually sends unrecognized fields, the RS will anyway stop the process itself when receiving the token. This was the last change, so if you are ok with this, I will go ahead and submit a new version. Francesca On 31/01/2019, 17:46, "Jim Schaad" wrote: > -Original Message- > From: Francesca Palombini > Sent: Thursday, January 31, 2019 6:26 AM > To: Jim Schaad ; draft-ietf-ace-oscore- > prof...@ietf.org > Cc: ace@ietf.org > Subject: Re: Shepard comments on draft-ietf-ace-oscore-profile > > Hi Jim, > > Inline. > > Thanks, > Francesca > > On 31/01/2019, 01:34, "Jim Schaad" wrote: > > > 1. Please update the text for MUST/SHOULD/MAY to include the language > from > RFC 8174. > > FP: Right, thanks. Updated now in the github. > > 2. Section 3.2.1 - What to do is clear if a field is not missing. What is > the correct behavior if a field is present that the client and/or resource > server does not recognize. Is this a fatal error or is it sufficient that > they may not behave the same? > > FP: Assuming you are referring to fields missing in the > OSCORE_Security_Context, (please correct me otherwise) this is a good > point. We currently do not define what happens if the security context has > unrecognized parameters. We don't foresee this happening, as the AS > should know what the client and RS implement. However, to cover this case > (bad implementation or something went wrong), to be on the safe side, we > propose that there is a fatal error in that case. In fact, we don't know what > additional parameters might be registered in the OSCORE_Security_Context, > and although they could be "risk-free" (as in optional additional information > non-necessary for the security context derivation), they could also be input > to the key derivation for example, in which case the endpoint non- > recognizing them would end up storing a "wrong" security context. What do > you think? Sounds good. I had a vague thought that perhaps some of the group items might be added in the future but no hard items to add. Jim > > Jim > > > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Shepard comments draft-ietf-ace-coap-est-08
Hi Jim, thanks for the review. see below. Peter Jim Schaad schreef op 2019-02-16 20:55: > 1. In section 10.1 the last sentence of the first paragraph and the first > sentence of the last paragraph duplicate each other. This should be cleaned > up. > > removed the 2nd instance > > 2. Correct the grammar in the first sentence of section 10.2 - s/registers > a new/registers new/ > done > > 3. The correct example DNS name is est-coaps.example.org not > est-coaps.example.ietf.org. Please correct this. (See RFC 2606) > > sorry about that, corrected that everywhere > > 4. The query in section 5.1 to a resource directory is not correct. It > would not go to /.well-known/core but to /rd-lookup (or what ever name is > used by the RD). If this is not intended to be an RD query, then the > sentence about it above can be omitted. > > removed anchor because query to server and not RD > > 5. Please remove the "anchor" target attribute from the response from the > RD. I believe that this is no longer required and it is just adding noise > without adding value. If this is intended to be from well-known then it is > sufficient to have the anchor but not to have the authority section in the > href. > > ;rt="ace.est";anchor="coaps://2001:db8::123]:61617" > > Removed anchor, see above, but left the authority section because of > port example. > > 6. You have registered 282 and 283 as content types, however you also do > not define anything that uses these types. Either some text about the > content types needs to exist or potentially the registrations should be > abandoned. > > are needed for other future anima documents, but have them removed > > > 7. There is an outstanding review from Klaus that needs to be addressed. > > we are working on it. will discuss answers to-morrow between authors > > > 8. There is still an open issue dealing with content types. I have > requested that this be added to the agenda for the next CoRE interim > meeting. > > Absolutely. we hope for additional text elsewhere > > Jim___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21
Hello, I have a short comment about error responses from an RS in draft-ietf-ace-oauth-authz-21. More specifically, my question is about section 5.8.2. In the second paragraph, it states “The response code MUST be 4.01 (Unauthorized) in case the client has not performed the proof-of-possession, or if RS has no valid access token for the client.” I am assuming this means that if the client is trying to access a resource and sending a pop key id that is not known by the RS, either because the RS has never seen it or because it is associated to a token that has already been removed from the RS, then this is how the RS should reply. If this is the case, I am a bit confused on how to implement this when using the DTLS profile. When using this profile, a client will first try to establish a DTLS session with the RS when accessing a resource. Once the session is established, it will actually try to access the resource over that DTLS connection. The pop key id to be used is sent when establishing the DTLS connection in the DTLS handshake messages, but if the RS does not have a key+token associated to that id for whatever reason, then it will cancel the DTLS handshake. If the DTLS handshake is never completed, then the RS can’t really send a reply at all, much less a 4.01 reply. Thanks, Sebastian Echeverria ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21
> On Feb 18, 2019, at 15:59, Sebastian Echeverria > wrote: > > Hello, > > I have a short comment about error responses from an RS in > draft-ietf-ace-oauth-authz-21. More specifically, my question is about > section 5.8.2. In the second paragraph, it states “The response code MUST be > 4.01 (Unauthorized) in case the client has not performed the > proof-of-possession, or if RS has no valid access token for the client.” I am > assuming this means that if the client is trying to access a resource and > sending a pop key id that is not known by the RS, either because the RS has > never seen it or because it is associated to a token that has already been > removed from the RS, then this is how the RS should reply. > > If this is the case, I am a bit confused on how to implement this when using > the DTLS profile. When using this profile, a client will first try to > establish a DTLS session with the RS when accessing a resource. Once the > session is established, it will actually try to access the resource over that > DTLS connection. The pop key id to be used is sent when establishing the DTLS > connection in the DTLS handshake messages, but if the RS does not have a > key+token associated to that id for whatever reason, then it will cancel the > DTLS handshake. If the DTLS handshake is never completed, then the RS can’t > really send a reply at all, much less a 4.01 reply. Actually, if the DTLS handshake fails, the client can’t even send the request, so the MUST doesn’t apply. (That is probably worth another sentence.) (Another question of course is if the DTLS handshake failure is sufficiently speaking for this case.) Grüße, Carsten > > Thanks, > > Sebastian Echeverria > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Hi Richard, From: Richard Barnes Date: Friday, 15 February 2019 at 17:19 To: Göran Selander Cc: "secdispa...@ietf.org" , "ace@ietf.org" Subject: Re: [Secdispatch] FW: [secdir] EDHOC and Transports On Fri, Feb 15, 2019 at 7:13 AM Göran Selander mailto:goran.selan...@ericsson.com>> wrote: Hi Richard, Thanks, that is a fair question to ask on behalf of those who are new to the subject. The short answer is: Yes, we have counted every byte of the TLS handshake and, no, we don’t think it is possible to support the same radio technologies as EDHOC do, unless you change some assumption which impacts the security analysis of TLS. This is the part that worries me. It would be helpful to be very crisp about what assumptions are being changed here, and why it's OK for them to be changed. Especially given that the Bruni et al. paper seems to have found flaws. Your point about CBOR isn't relevant here. Re-encoding is fine; it's changing the AKE that necessitates a whole bunch of new analysis. Perhaps I was unclear: We are not proposing any changes to (D)TLS 1.3. We believe that making (D)TLS 1.3 AKE fit into small frames requires changing some assumption of the protocol which, as you say, would necessitate a new analysis of TLS. The point about reencoding is about inefficiency or incompatibility, which are both relevant for the overall discussion, but not about security. The paper you mention analyzed version -08 of EDHOC and, essentially, the expected security properties hold. All comments from this analysis are addressed in the updated version of the protocol. Section 4 of the paper describes the security properties. Their main concern was related to the application data sent by party V in message #2 (APP_2 in -08) being encrypted, which may mislead application developers that it is protected for the intended party U, but party U is not authenticated at the time of sending message #2. Later versions of the draft emphasize how to handle data which is not protected (see Section 8.4 in -11) and the APP_2 message field is renamed UAD_2 (Unprotected Application Data). Finally, to be totally honest, I find the EDHOC spec pretty inscrutable. A little more prose to explain what's going on would go a long way toward helping this discussion be productive. What part of the draft did you find difficult to understand? Göran ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Hi Michael, On 2019-02-18, 02:35, "Ace on behalf of Michael Richardson" wrote: Richard Barnes wrote: > Finally, to be totally honest, I find the EDHOC spec pretty inscrutable. A > little more prose to explain what's going on would go a long way toward > helping this discussion be productive. Sure. Find a WG to adopt it, and we can make the text beautiful. I believe this is what the SecDispatch chairs are considering. I know of others sharing your impatience too. The packets are all there, and the references pretty much explain all the crypto. This stuff is not any newer than IKEv2. EDHOC is neither TLS 1.3 nor IKEv2. The similarity with other AKEs comes from being based on same SIGMA protocol. Current version of EDHOC is based on Sigma-I, but the Sigma-R version discussed in a parallel thread is similar to IKEv2: https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ Göran ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports
Hi Valery, On 2019-02-18, 08:07, "Valery Smyslov" wrote: Hi, > Richard Barnes wrote: > > Finally, to be totally honest, I find the EDHOC spec pretty inscrutable. A > > little more prose to explain what's going on would go a long way toward > > helping this discussion be productive. > > Sure. > Find a WG to adopt it, and we can make the text beautiful. > The packets are all there, and the references pretty much explain all the crypto. > This stuff is not any newer than IKEv2. I have only a quick look over the draft, but one thing strikes me - the protocol is claimed not to bound to a particular transport (so I assume that implementing it on top of pure UDP is fine), and it has an odd number of messages. That's OK from cryptographic point of view, but it's a headache for implementations if the transport protocol is unreliable, since in this case retransmissions must be sent by both parties. We learned this lesson from IKEv1 (Aggressive and Quick modes) and in IKEv2 the number of messages in any exchange is always even, that simplifies implementations and makes protocol more reliable. Of course if only reliable transports are considered, then this doesn't matter. Current version of EDHOC is 3-pass to allow traffic data after one round trip, which reduces latency in many applications. A 4-pass version has also been discussed: https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ When EDHOC is used as key exchange for OSCORE, and also in other settings, EDHOC will commonly run on top of CoAP. For example, in 6tisch the join protocol relies on CoAP proxy functionality. CoAP is defined for reliable transport (RFC 8323) as well as UDP (RFC 7252), the latter handles retransmissions by client and server. An example of using EDHOC with CoAP is given in appendix D.1: https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-11#appendix-D.1 It sounds like we should add some considerations for the setting you outline. Do you have an example or pointer explaining the specific problem in more detail? Thanks, Göran ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Shepard comments draft-ietf-ace-coap-est-08
Hi Jim, About > 4. The query in section 5.1 to a resource directory is not correct. It > would not go to /.well-known/core but to /rd-lookup (or what ever name is > used by the RD). If this is not intended to be an RD query, then the > sentence about it above can be omitted. > 5. Please remove the "anchor" target attribute from the response from the > RD. I believe that this is no longer required and it is just adding noise > without adding value. If this is intended to be from well-known then it is > sufficient to have the anchor but not to have the authority section in the > href. ;rt="ace.est";anchor="coaps://2001:db8::123]:61617" The text will now read ~~~ Discoverable port numbers can be returned in the payload An example response payload for non-default CoAPS server port 61617 follows below. Linefeeds were included only for readability. REQ: GET /.well-known/core?rt=ace.est* RES: 2.05 Content ;rt="ace.est", ;rt="ace.est.crts"; ct="281 TBD287", ;rt="ace.est.sen";ct="281 TBD287", ;rt="ace.est.sren";ct="281 TBD287", ;rt="ace.est.att";ct="285", ;rt="ace.est.skg";ct="62 280 284 281 TBD287" ~~~ What do you think? Does it address your two comments 4 and 5? Rgs, Panos -Original Message- From: Ace On Behalf Of Jim Schaad Sent: Saturday, February 16, 2019 2:56 PM To: draft-ietf-ace-coap-...@ietf.org Cc: ace@ietf.org Subject: [Ace] Shepard comments draft-ietf-ace-coap-est-08 1. In section 10.1 the last sentence of the first paragraph and the first sentence of the last paragraph duplicate each other. This should be cleaned up. 2. Correct the grammar in the first sentence of section 10.2 - s/registers a new/registers new/ 3. The correct example DNS name is est-coaps.example.org not est-coaps.example.ietf.org. Please correct this. (See RFC 2606) 4. The query in section 5.1 to a resource directory is not correct. It would not go to /.well-known/core but to /rd-lookup (or what ever name is used by the RD). If this is not intended to be an RD query, then the sentence about it above can be omitted. 5. Please remove the "anchor" target attribute from the response from the RD. I believe that this is no longer required and it is just adding noise without adding value. If this is intended to be from well-known then it is sufficient to have the anchor but not to have the authority section in the href. ;rt="ace.est";anchor="coaps://2001:db8::123]:61617" 6. You have registered 282 and 283 as content types, however you also do not define anything that uses these types. Either some text about the content types needs to exist or potentially the registrations should be abandoned. 7. There is an outstanding review from Klaus that needs to be addressed. 8. There is still an open issue dealing with content types. I have requested that this be added to the agenda for the next CoRE interim meeting. Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Shepard comments draft-ietf-ace-coap-est-08
> -Original Message- > From: Panos Kampanakis (pkampana) > Sent: Monday, February 18, 2019 9:54 AM > To: Jim Schaad ; draft-ietf-ace-coap-...@ietf.org > Cc: ace@ietf.org > Subject: RE: [Ace] Shepard comments draft-ietf-ace-coap-est-08 > > Hi Jim, > > About > > > 4. The query in section 5.1 to a resource directory is not correct. It would > not go to /.well-known/core but to /rd-lookup (or what ever name is used by > the RD). If this is not intended to be an RD query, then the sentence about it > above can be omitted. > > > 5. Please remove the "anchor" target attribute from the response from > the RD. I believe that this is no longer required and it is just adding noise > without adding value. If this is intended to be from well-known then it is > sufficient to have the anchor but not to have the authority section in the > href. ;rt="ace.est";anchor="coaps://2001:db8::123]:61617" > > The text will now read > ~~~ > Discoverable port numbers can be returned in the payload An example > response payload for non-default CoAPS server port 61617 follows below. > Linefeeds were included only for readability. > > REQ: GET /.well-known/core?rt=ace.est* > > RES: 2.05 Content > ;rt="ace.est", > ;rt="ace.est.crts"; ct="281 > TBD287", > ;rt="ace.est.sen";ct="281 TBD287", > ;rt="ace.est.sren";ct="281 > TBD287", ;rt="ace.est.att";ct="285", > ;rt="ace.est.skg";ct="62 280 284 > 281 TBD287" > ~~~ > > What do you think? Does it address your two comments 4 and 5? Yes that would be just fine. The only possible comment is that you should be using 'coaps' not 'coap' to say that this is a DTLS schema. Jim > > Rgs, > Panos > > -Original Message- > From: Ace On Behalf Of Jim Schaad > Sent: Saturday, February 16, 2019 2:56 PM > To: draft-ietf-ace-coap-...@ietf.org > Cc: ace@ietf.org > Subject: [Ace] Shepard comments draft-ietf-ace-coap-est-08 > > 1. In section 10.1 the last sentence of the first paragraph and the first > sentence of the last paragraph duplicate each other. This should be cleaned > up. > > 2. Correct the grammar in the first sentence of section 10.2 - s/registers a > new/registers new/ > > 3. The correct example DNS name is est-coaps.example.org not > est-coaps.example.ietf.org. Please correct this. (See RFC 2606) > > 4. The query in section 5.1 to a resource directory is not correct. It would not > go to /.well-known/core but to /rd-lookup (or what ever name is > used by the RD). If this is not intended to be an RD query, then the > sentence about it above can be omitted. > > 5. Please remove the "anchor" target attribute from the response from the > RD. I believe that this is no longer required and it is just adding noise without > adding value. If this is intended to be from well-known then it is sufficient to > have the anchor but not to have the authority section in the href. > > ;rt="ace.est";anchor="coaps://2001:db8::123]:61617" > > 6. You have registered 282 and 283 as content types, however you also do > not define anything that uses these types. Either some text about the > content types needs to exist or potentially the registrations should be > abandoned. > > 7. There is an outstanding review from Klaus that needs to be addressed. > > 8. There is still an open issue dealing with content types. I have requested > that this be added to the agenda for the next CoRE interim meeting. > > Jim > > > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Shepard comments on draft-ietf-ace-oscore-profile
Looks fine. Jim > -Original Message- > From: Francesca Palombini > Sent: Monday, February 18, 2019 4:55 AM > To: Jim Schaad ; draft-ietf-ace-oscore- > prof...@ietf.org > Cc: ace@ietf.org > Subject: Re: Shepard comments on draft-ietf-ace-oscore-profile > > Hi Jim, > > Here is the update including your comments. It also includes minor > comments from Marco (thanks!) that we had missed before. > > https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-ace- > oscore-profile.txt&url2=https://ace-wg.github.io/ace-oscore-profile/draft- > ietf-ace-oscore-profile.txt > > Concerning the error caused by unrecognized fields in the > OSCORE_Security_Context, I only defined that for the RS: in fact, the client > does not validate the token, so stopping the processing because of an > unrecognized field would open up for easy DoS attacks by intermediaries. If > the AS actually sends unrecognized fields, the RS will anyway stop the > process itself when receiving the token. > > This was the last change, so if you are ok with this, I will go ahead and > submit > a new version. > > Francesca > > On 31/01/2019, 17:46, "Jim Schaad" wrote: > > > > > -Original Message- > > From: Francesca Palombini > > Sent: Thursday, January 31, 2019 6:26 AM > > To: Jim Schaad ; draft-ietf-ace-oscore- > > prof...@ietf.org > > Cc: ace@ietf.org > > Subject: Re: Shepard comments on draft-ietf-ace-oscore-profile > > > > Hi Jim, > > > > Inline. > > > > Thanks, > > Francesca > > > > On 31/01/2019, 01:34, "Jim Schaad" wrote: > > > > > > 1. Please update the text for MUST/SHOULD/MAY to include the > language > > from > > RFC 8174. > > > > FP: Right, thanks. Updated now in the github. > > > > 2. Section 3.2.1 - What to do is clear if a field is not missing. > What is > > the correct behavior if a field is present that the client and/or > resource > > server does not recognize. Is this a fatal error or is it > sufficient that > > they may not behave the same? > > > > FP: Assuming you are referring to fields missing in the > > OSCORE_Security_Context, (please correct me otherwise) this is a good > > point. We currently do not define what happens if the security context > has > > unrecognized parameters. We don't foresee this happening, as the AS > > should know what the client and RS implement. However, to cover this > case > > (bad implementation or something went wrong), to be on the safe side, > we > > propose that there is a fatal error in that case. In fact, we don't know > what > > additional parameters might be registered in the > OSCORE_Security_Context, > > and although they could be "risk-free" (as in optional additional > information > > non-necessary for the security context derivation), they could also be > input > > to the key derivation for example, in which case the endpoint non- > > recognizing them would end up storing a "wrong" security context. What > do > > you think? > > Sounds good. I had a vague thought that perhaps some of the group items > might be added in the future but no hard items to add. > > Jim > > > > > Jim > > > > > > > > > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
