Re: [Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)
Hi Mohit, My apologies for the slow response -- I skimmed the diff when it first arrived and it didn't look like I had enough time to process it all at that time, and I didn't get back to it as quickly as I would like. Following up inline only where I have further comments... On Fri, Jul 16, 2021 at 03:52:22PM +, Mohit Sethi M wrote: > Hi Ben, > > Thank you for your usual detailed review. We have uploaded a new version > of the draft: https://tools.ietf.org/html/draft-ietf-emu-eap-noob-05. > Here is the diff for your convenience: > https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-05. > > Answers inline. > > --Mohit > > On 4/22/21 7:26 AM, Benjamin Kaduk via Datatracker wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-emu-eap-noob-04: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ > > > > > > > > -- > > DISCUSS: > > -- > > > > The example JWK for cryptosuite 1 in §5.1 is not well-formed. RFC 8037 > > key-exchange uses a crv of "X25519" and a kty of "OKP". > > (See COMMENT for more quibbles with §5.1.) > > I think Appendix E is also using the wrong "kty" for X25519 (but is > > properly using "X25519" as the "crv"). > > Good catch. This is now fixed in the script used to generate the test > vectors: > https://github.com/tuomaura/eap-noob/commit/a9e8da4ec227b4afe8fb04feb71d76265396882b. > > The example messages in the draft are not yet updated (pending your > feedback on our proposal below). > > > > > I'd also like to discuss our treatment of channel binding, as the > > current mention seems dangerously incomplete. I don't remember if there > > is generic discussion of channel binding in the core EAP RFCs (if so, a > > specific reference would help), but otherwise if we're going to mention > > that protocol elements can be used for channel binding we should give > > some indication of how to actually do so in a secure manner (e.g., what > > protocol element needs to be verified against external channel > > information and what to do if they don't match). > > We have added a section on channel binding which should address all the > issues: > https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05#section-7.7. Thanks, this is really helpful. (I did not know about RFC 6677 previously, so my expectations for what the channel binding was doing were not quite correct.) > > > > > > -- > > COMMENT: > > -- > > > > Thanks for putting together this pretty comprehensive treatment of a > > topic that is simple to understand but has a lot of important details. > > (I do have some comments about a few of those details, just to check > > that we do have them right.) I especially appreciate the strong feature > > set that's been assembled. > > > > In Section 3.5 we discuss a key derivation scheme and say to use the > > one-step KDF from NIST SP 800-56Ar3 §5.8.2.1. In particular, this is > > not the two-step (extract-then-expand) KDF of the following section > > (§5.8.2.2). Since the (EC)DH shared secret Z is not uniformly random, > > my understanding was that generally the two-step KDF was needed, since > > the one-step KDF assumes that the input key is uniformly selected. I am > > not balloting Discuss for this point because I assume it was considered > > in the formal verification, but I would very much appreciate some > > additional insight into this selection. > We did not specifically model the security of the KDF itself. The NIST > specification defines the one-step key derivation function for use with > ECDH shared secrets (NIST calls it 'Z' a byte string that represents the > shared secret). In fact RFC 7518 > (https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.2) uses the > same NIST KDF for deriving keys. The one-step may have stronger > assumptions from the underlying hash function but we thought the hash > functions currently specified in the draft are safe to use with a > one-step function. In future, when we move to KMACs and SHA3 family, we > would not need a two-step KDF. I guess I was misremembering things here. Sorry for the confusion. > > Section 3.1 > > > > The overall protocol starts with the Initial Exchange, which > > comprises four EAP request-response pairs. In the Initial Exchange, > >
[Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-emu-eap-noob-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ -- DISCUSS: -- The example JWK for cryptosuite 1 in §5.1 is not well-formed. RFC 8037 key-exchange uses a crv of "X25519" and a kty of "OKP". (See COMMENT for more quibbles with §5.1.) I think Appendix E is also using the wrong "kty" for X25519 (but is properly using "X25519" as the "crv"). I'd also like to discuss our treatment of channel binding, as the current mention seems dangerously incomplete. I don't remember if there is generic discussion of channel binding in the core EAP RFCs (if so, a specific reference would help), but otherwise if we're going to mention that protocol elements can be used for channel binding we should give some indication of how to actually do so in a secure manner (e.g., what protocol element needs to be verified against external channel information and what to do if they don't match). -- COMMENT: -- Thanks for putting together this pretty comprehensive treatment of a topic that is simple to understand but has a lot of important details. (I do have some comments about a few of those details, just to check that we do have them right.) I especially appreciate the strong feature set that's been assembled. In Section 3.5 we discuss a key derivation scheme and say to use the one-step KDF from NIST SP 800-56Ar3 §5.8.2.1. In particular, this is not the two-step (extract-then-expand) KDF of the following section (§5.8.2.2). Since the (EC)DH shared secret Z is not uniformly random, my understanding was that generally the two-step KDF was needed, since the one-step KDF assumes that the input key is uniformly selected. I am not balloting Discuss for this point because I assume it was considered in the formal verification, but I would very much appreciate some additional insight into this selection. Section 3.1 The overall protocol starts with the Initial Exchange, which comprises four EAP request-response pairs. In the Initial Exchange, the server allocates an identifier to the peer, and the server and Is this a DoS risk for state exhaustion on the server? The server MUST NOT repeat a successful OOB Step with the same peer except if the association with the peer is explicitly reset by the user or lost due to failure of the persistent storage in the server. More specifically, once the association has entered the Registered state, the server MUST NOT delete the association or go back to the ephemeral states 0..2 without explicit user approval. [...] This also looks like a DoS risk, if a malicious device/user completes the OOB step then only deletes the association on the device (without telling the server), then re-registers, deletes again, etc. The server is required to maintain state without bound. However, it MUST NOT delete or merge redundant associations without user or application approval because EAP-NOOB internally has no secure way of verifying that the two peers are the same physical device. [...] No way other than the registered cryptographic key that's used to authenticate the Reconnect Exchange, that is? A special feature of the EAP-NOOB method is that the server is not assumed to have any a-priori knowledge of the peer. Therefore, the peer initially uses the generic identity string "n...@eap-noob.arpa" as its network access identifier (NAI). [...] This looks like codepoint squatting, since we haven't received an early allocation of this entry in .arpa. section 3.2.1 After receiving the EAP-Response/Identity message, the server sends the first EAP-NOOB request (Type=1) to the peer, which responds with the peer identifier (PeerId) and state (PeerState) in the range 0..3. However, the peer SHOULD omit the PeerId from the response (Type=1) when PeerState=0. [...] Why only SHOULD and not MUST? Section 3.2.3 Can we give any guidance for how to set OobRetries? Section 3.2.4 In the request, the server sends the NoobId value, which the peer uses to identify the exact OOB message received by the server. [...] This is the first time we mention the NoobId value, so some more explanation or forward-reference seems in order. value. The recipient of an
