[Emu] Benjamin Kaduk's No Objection on draft-ietf-emu-eap-tls13-20: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-emu-eap-tls13-20: No Objection 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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ -- COMMENT: -- Updating my ballot position from Discuss to No Objection in light of the discussion that we had at the telechat today. Previous Discuss position: == Many thanks for the updates since the -13, the last version I reviewed. I'm happy to report that the structural issues I noted in that version have been addressed, and my new Discuss point is a fairly mundane one. In several sections, we say that the text "updates Section X of [RFC5216] by amending it with the following text", but I'm quite unclear on exactly what that is intended to mean. Are we adding to the end, prepending to the beginning, replacing wholesale, replacing in part, or doing something else to the indicated text of RFC 5216? I expect that just tweaking a few words can resolve the ambiguity, but am not sure which ones yet. It is also interesting to contrast the "amending" language with what we say in Sections 2.1.4 and 2.3 about "replacing" text from RFC 5216 and the various places where we report a "new section when compared to [RFC5216]". == The discussion helped shed some light on the process the WG took to get to the current state of having an amalgamation of new and existing text where the new text amends the existing text in a way that has the reader perform their own synthesis, avoiding a need for specification authors to engage in a tedious exercise of going sentence-by-sentence to check all the details. I would suggest to make a change of the form: OLD: updates Section X of [RFC5216] by amending it with the following text NEW: updates Section X of [RFC5216] by amending it in accordance with the following discussion Original COMMENT section retained unchanged: == I echo the sentiments of other reviewers that constructing EAP-TLS 1.3 as something of a diff against RFC 5216 will make it harder to eventually deprecate/obsolete/etc RFC 5216 and makes it somewhat challenging to read the EAP-TLS 1.3 specification as a whole. That said, this is just the comment section, so I am not strenuously objecting to it. As another general note, in many places the phrasings used to describe TLS 1.3 behaviors feel rather un-idiomatic to me, based on my experience with TLS and TLS specifications. That said, the behavior seems well-specified as is, so I don't propose to make any changes in response to this comment. If there is demand, I could probably be persuaded to suggest alternative text, but I don't expect much demand at this stage in the document's lifecycle. I made a github PR with some editorial suggestions: https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/92 Section 2.1 This section updates Section 2.1 of [RFC5216] by amending it with the following text. [...] TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, much of Section 2.1 of [RFC5216] does not apply for TLS 1.3. Except for Sections 2.2 and 5.7 this document applies only when TLS 1.3 is negotiated. When TLS 1.2 is negotiated, then [RFC5216] applies. There is perhaps some philosophical question of what "this document" means in the context of an updated collection of text that includes RFC 5216 and the text that is being amended as directed here. I hope that the RFC Editor will have some thoughts on this matter, but perhaps s/this document/[RFC]/ would reduce ambiguity. If this change is made, there would be similar/corresponding changes later on as well, e.g., whenever the amended text includes a section reference to this document, it would be "Section 2.1.3 of [RFC]". Also, I think that both Sections 5.6 and 5.7 (not just 5.7) are marked as applying to EAP-TLS in general. * Early Data MUST NOT be used in EAP-TLS. EAP-TLS servers MUST NOT send an early_data extension and clients MUST NOT send an EndOfEarlyData message. Personally, I wouldn't include the last sentence, as both requirements follow naturally from the previous requirement. It feels a little surprising to make reference to the specific message-level requirements on the TLS stack, though I w
[Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-20: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-emu-eap-tls13-20: 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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ -- DISCUSS: -- Many thanks for the updates since the -13, the last version I reviewed. I'm happy to report that the structural issues I noted in that version have been addressed, and my new Discuss point is a fairly mundane one. In several sections, we say that the text "updates Section X of [RFC5216] by amending it with the following text", but I'm quite unclear on exactly what that is intended to mean. Are we adding to the end, prepending to the beginning, replacing wholesale, replacing in part, or doing something else to the indicated text of RFC 5216? I expect that just tweaking a few words can resolve the ambiguity, but am not sure which ones yet. It is also interesting to contrast the "amending" language with what we say in Sections 2.1.4 and 2.3 about "replacing" text from RFC 5216 and the various places where we report a "new section when compared to [RFC5216]". -- COMMENT: -- I echo the sentiments of other reviewers that constructing EAP-TLS 1.3 as something of a diff against RFC 5216 will make it harder to eventually deprecate/obsolete/etc RFC 5216 and makes it somewhat challenging to read the EAP-TLS 1.3 specification as a whole. That said, this is just the comment section, so I am not strenuously objecting to it. As another general note, in many places the phrasings used to describe TLS 1.3 behaviors feel rather un-idiomatic to me, based on my experience with TLS and TLS specifications. That said, the behavior seems well-specified as is, so I don't propose to make any changes in response to this comment. If there is demand, I could probably be persuaded to suggest alternative text, but I don't expect much demand at this stage in the document's lifecycle. I made a github PR with some editorial suggestions: https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/92 Section 2.1 This section updates Section 2.1 of [RFC5216] by amending it with the following text. [...] TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, much of Section 2.1 of [RFC5216] does not apply for TLS 1.3. Except for Sections 2.2 and 5.7 this document applies only when TLS 1.3 is negotiated. When TLS 1.2 is negotiated, then [RFC5216] applies. There is perhaps some philosophical question of what "this document" means in the context of an updated collection of text that includes RFC 5216 and the text that is being amended as directed here. I hope that the RFC Editor will have some thoughts on this matter, but perhaps s/this document/[RFC]/ would reduce ambiguity. If this change is made, there would be similar/corresponding changes later on as well, e.g., whenever the amended text includes a section reference to this document, it would be "Section 2.1.3 of [RFC]". Also, I think that both Sections 5.6 and 5.7 (not just 5.7) are marked as applying to EAP-TLS in general. * Early Data MUST NOT be used in EAP-TLS. EAP-TLS servers MUST NOT send an early_data extension and clients MUST NOT send an EndOfEarlyData message. Personally, I wouldn't include the last sentence, as both requirements follow naturally from the previous requirement. It feels a little surprising to make reference to the specific message-level requirements on the TLS stack, though I won't object to keeping this text if the authors/WG find it important. * Servers MUST NOT request post-handshake client authentication. Do we want to make any statement about the client (not) sending the "post_handshake_auth" extension (which the client must do as a prerequisite of the server requesting post-handshake client authentication)? Section 2.1.1 After the EAP-TLS server has sent an EAP-Request containing the TLS application data 0x00 and received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the EAP-TLS server sends EAP-Success. I think in some sense the EAP-Server also needs to not have additional TLS data do send in order to declare success and send EAP-Success. Section 2.1.3 full handshake. In the case a full handshake is required, the negotiation pr
[Emu] Benjamin Kaduk's No Objection on draft-ietf-emu-eap-noob-05: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-emu-eap-noob-05: No Objection 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/ -- COMMENT: -- Thanks for the many updates to address my Discuss and Comment points. Just a few final thoughts from reading the diff from -04 to -05: Section 5.6 It's interesting to see the eap-noob.arpa registration lose discussion about who should care and why (i.e., the list from RFC 6761). I guess I see how it's not specifically required by 6761 itself, but it seemed useful to think about. Section 7.2 The first and second paragraphs both start with the same sentence, which makes me suspect that there are some editing remnants left. Section 7.7 Many thanks for adding this treatment of channel binding. The actual properties provided are weaker than I'd like, but attempting to diverge from RFC 6677 in this document seems unlikely to actually be useful, so I'll have to accept what is possible. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[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 unre
[Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-emu-eap-tls13-13: 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ -- DISCUSS: -- I'm going to defer this document's evaluation because I think there are several interrelated subtle issues that merit closer consideration than has been given so far. I will also invite the TLS WG to provide input on these issues, since they relate to rather fundamental issues of the operation of the TLS sub-protocols. Most of them concern the Commitment Message, in terms of what goals it aims to achieve, how it is specified, and what mechanism is used to effectuate it. To start with the easy one: currently the way in which the structure of the Commitment Message is described makes reference to many fields of TLS Record Layer structures in order to specify what is fundamentally a message on the TLS Application Data stream. This is a layering violation; I don't see any reason to say more than what was suggested in https://mailarchive.ietf.org/arch/msg/emu/ECgvnq-C_VVXT5bpvOowte8LBjw/ : "the commit[ment] message is a single byte of [value] 0 in the application data stream". All the bits about cryptographic protection and expansion of the plaintext in prepararation for record protection are just adding noise, and the interface between the TLS stack and the application is supposed to be a data-stream abstraction, not a record abstraction. Next, the whole reason for the existence of a Commitment Message seems under-justified -- the only mention I could find in the document is that it serves "to decrease the uncertainty for the EAP-TLS peer". What harm would be caused by a lack of certainty in this area? Why does waiting for an EAP-Success or EAP-Failure not provide a similar level of certainty? The document also suggests in several places that the Commitment Message can or should be sent at 0.5-RTT data in the same flight as the server Finished. The intent, as determined from the mailing list archive, seems to be to save a round-trip compared to a typical full message flow where the server does not send application data until after the client's Finished (and any application data alongside it) is received. In particular, this came out during discussion of how a TLS "close_notify" alert would be unsuitable for the role of the Commitment Message, since sending the "close_notify" in 0.5-RTT would prevent sending an alert if the client authentication failed, and the diagnostic value of such alerts is significant. This is where the issues start to become interrelated -- the Commitment Message as a new application-data construct is for the objective of reducing the number of round trips. However, TLS session resumption is also designed to reduce the number of round-trips (including by no longer needing to send potentially large TLS Certificate messages that get fragmented at the EAP layer, with the cost of a round trip per fragment), and there is a nasty interaction between the two mechanisms. Specifically, TLS 1.3 session resumption requires the use of a NewSessionTicket message, which is associated with a resumption secret; the resumption secret, in turn, is not available in the key schedule until the client Finished (and client authentication messages, if any) is available. While it is possible in many Web scenarios for NewSessionTicket to be issued in the 0.5-RTT flight, this is because the server can precompute what the valid client Finished would be and use that in the key schedule to precompute the resumption secret. If the client is to be authenticated, as is the case for the vast majority of EAP exchanges, then such precomputation is impossible, and the session ticket cannot be issued until the extra round trip is completed. The document contains no discussion of the inherent tradeoff between sending the commitment message in 0.5-RTT and using resumption, and this tradeoff seems to call into question the merits of choosing this mechanism to implement the commitment message, since... The commitment message as specified seems to itself be a layering violation. The TLS protocol itself consists of a few sub-protocols, e.g., the handshake protocol, record protocol, and alert protocol. The operation of the handshake protocol is supposed to be completely independent of the application-data record protocol (except to the extent that the handshake protocol supplies the keys used for cryptographic protection of appl
[Emu] Benjamin Kaduk's Yes on draft-ietf-emu-eaptlscert-06: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-emu-eaptlscert-06: Yes 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/ -- COMMENT: -- Thank you for responding to the secdir review and thanks to Stefan Santesson for the review -- the changes staged in github are a significant improvement! Though I am balloting Yes, please see my remarks about draft-thomson-tls-sic in the comments on Section 4.2.5 -- it is expired and was not adopted by the TLS WG and we should not imply that it is a current work item there. I also made a pull request at https://github.com/emu-wg/eaptls-longcert/pull/4 with a few editorial fixes/suggestions. Section 3 o Multiple user groups in the certificate. What are "user groups" in a certificate? A certificate chain (called a certification path in [RFC5280]) can commonly have 2 - 6 intermediate certificates between the end-entity certificate and the trust anchor. The '2' here is surprising to me; my understanding was that having just 1 intermediate was quite common, especially on the web. Many access point implementations drop EAP sessions that do not complete within 50 round-trips. This means that if the chain is Earlier we said "40 - 50"; we should probably be consistent about it. Section 4.1 1.3 [RFC8446] requires implementations to support ECC. New cipher suites that use ECC are also specified for TLS 1.2 [RFC5289]. Using nit: RFC 8422 might be a better reference than 5289, here. Section 4.1.3 The EAP peer certificate chain does not have to mirror the organizational hierarchy. For successful EAP-TLS authentication, certificate chains SHOULD NOT contain more than 2-4 intermediate certificates. This seems equivalent to the shorter "SHOULD NOT contain more than 4 intermediate certificates". Section 4.2 by updating the underlying TLS or EAP-TLS implementation. Note that in many cases the new feature may already be implemented in the underlying library and simply needs to be taken into use. Hmm, "many" might be a stretch, given that the majority of the mechanisms we refer to are still at the internet-draft stage. Section 4.2.2 possible. An option in such a scenario would be to cache validated certificate chains even if the EAP-TLS exchange fails, but this is currently not allowed according to [RFC7924]. This is arguably not a strict requirement in 7924; the text in question looks to be: % Clients MUST ensure that they only cache information from legitimate % sources. For example, when the client populates the cache from a TLS % exchange, then it must only cache information after the successful % completion of a TLS exchange to ensure that an attacker does not % inject incorrect information into the cache. Failure to do so allows % for man-in-the-middle attacks. The normative MUST is for "legitimate sources", and "only after successful TLS exchange" uses the lowercase MUST. Of course, 7924 predates 8174, so it's not fully clear-cut, but there may be some ground to stand on for caching validated certificate chains prior to a completed TLS handshake (provided that other validation is performed properly). Section 4.2.4 "known certificates". Thus, cTLS can provide another mechanism for EAP-TLS deployments to reduce the size of messages and avoid excessive fragmentation. cTLS is at a fairly early stage; it might be better to say "could provide" rather than "can provide". Section 4.2.5 handshake increases the size of the handshake unnecessarily. The TLS working group is working on an extension for TLS 1.3 [I-D.thomson-tls-sic] that allows a TLS client that has access to the It is not accurate or appropriate to say that "the TLS working group is working on" an individual I-D that is not adopted by the WG. Suppressing intermediate certificates might be more appopriate in the "new certificate types and compression algorithms" section, that seems to be the home for most of the still-speculative stuff. Section 4.2.6 certificate chains. Deployments can consider their use as long as an appropriate out-of-band mechanism for binding public keys with identifiers is in place. It is also important to consider revocation and key rotation when considering the use of raw public keys. Section 6 We probably want a general disclaimer that the security considerations of the referenced documents apply, in addition to whichever pieces we c
[Emu] Benjamin Kaduk's No Objection on draft-ietf-emu-eap-session-id-05: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-emu-eap-session-id-05: No Objection 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-session-id/ -- COMMENT: -- Thanks for all the updates! It looks like there's one "fast re-authentication" that is split across a line (in Section 2.3) and thus escaped the cleanup pass. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-session-id-04: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-emu-eap-session-id-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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-session-id/ -- DISCUSS: -- Should be a couple easy ones: Section 2.2 discusses the "AT_MAC attribute from the EAP-Request/AKA-Reauthentication" in the context of computing the EAP-SIM Session-Id, but there is no such EAP-Request message for EAP-SIM. Presumably it should be "EAP-Request/SIM/Re-authentication", and a similar change in Session 2.3 (which would need to cover both the AKA and SIM cases)? We need some kind of a reference for PEAP. (Is draft-josefsson-pppext-eap-tls-eap tolerable?) -- COMMENT: -- I'm pretty underwhelmed by the level of security analysis that this document suggests has been done for these new Session-Id constructions. That said, it's probably still worth publishing the document so that everyone agrees on the same construction, and they seem to already be in sufficiently wide use that we'll have a fire drill if there's a problem with the construction, whether or not we hold up the document to get more analysis. RFC 5247 (and 3748) refer to a "fast reconnect" mechanism, not a "fast re-authentication" mechanism as we discuss it here (though it does discuss "fast EAP re-authentication"). Is there a consistent terminology to settle on? Also, some of the attributes we use for the fast re-authentication Session-Id generation are encrypted for transit. Should we say something about the decrypted version being needed for producing the right input? I also want to mention an observation that I made (which may itself be erroneous), and ask how that relates to the Session-Id usage: in EAP-AKA, the full authentication's Session-Id construction uses just the RAND and AUTN, which are server-generated and are related in a way that can be validated using just(?) the peer's identity as additional input. When we start pulling in AT_MAC for the fast re-authentication Session-Id, the MAC can no longer be validated without the context of the full EAP packet it was obtained from. I don't know of any case where there would be a need to do internal consistency checking on a Session-Id in a way that's made difficult by using AT_MAC divorced from the containing EAP packet, but it seemed worth checking. I agree with the genart reviewer that the abstract+introduction should mention that the definition of Session-Id for EAP-SIM full authentication gets some additional clarification. Section 1 The IEEE is defining FILS authentication [FILS], which needs the EAP nit: can we expand Fast Initial Link Setup here? Further, [RFC5247] did not define Session-Id for PEAP. We correct these deficiencies here by updating [RFC5247] with the Session-Id derivation during fast-authentication exchange for EAP-SIM and EAP- AKA; and defining Session-Id derivation for PEAP. Perhaps note that this definition for PEAP is for both the fast-authentication and full-authentication cases? Section 2.2 It's not entirely clear that we need to expend the text to introduce the "RAND1", "RAND2", "RAND3" terminology, that AFAICT is not defined in RFC 4186 itself (though it is used in one example). Also, I'm not entirely sure why we copy the Peer-Id/Server-Id paragraph unchanged and put the fast re-auth case after it for EAP-SIM, when we ignored that paragraph for EAP-AKA. Section 2.3 re-authentication case. Based on [RFC4187] Section 5.2, and similar text in [RFC4186], NONCE_S corresponds to RAND and MAC in EAP- The RFC 4186 text is its section 5.2 (as well), which might be worth mentioning more clearly. Request/AKA-Reauthentication corresponds to AUTN. That would seem to imply that the Session-Id could be defined using NONCE_S and MAC instead of RAND and AUTN/NONCE_MT. This "would seem to imply" language is not terribly confidence inspiring. Perhaps we want to talk about providing a random value contributed by the server and a value derived from that random value with inclusion of secret key material and the peer's identity, which seem to be the relevant "corresponding properties" to this reader. My question above about independent validation still stands, though. Section 3 Protected EAP (PEAP). For consistency with EAP-TLS the definition given in [RFC5216] Section 2.3, we def
[Emu] Benjamin Kaduk's No Objection on draft-ietf-emu-rfc5448bis-07: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-emu-rfc5448bis-07: No Objection 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ -- COMMENT: -- I mostly only read the diff and skimmed the rest. Section 1 The rest of this specification is structured as follows. Section 3 defines the EAP-AKA' method. Section 4 adds support to EAP-AKA to prevent bidding down attacks from EAP-AKA'. Section 5 specifies requirements regarding the use of peer identities, including how EAP- AKA' identifiers are used in 5G context. Section 6 specifies what I'm not sure if it's "EAP-AKA' identifiers being used in 5G context" or "5G identifiers being used in an EAP-AKA' context" -- which way does the causality go? Section 4 Note that we assume (Section 7) that EAP-AKA' is always stronger than EAP-AKA. As a result, there is no need to prevent bidding "down" attacks in the other direction, i.e., attackers forcing the endpoints to use EAP-AKA'. I'd prefer to say something like "we do not provide" rather than "there is no need". Section 5.2 I agree with the IoTdir reviewer's concerns about over-stating the need for a secure PRNG in pseudonym generation. Section 5.3.1 In all other cases, the following applies: The identity used in the key derivation formula MUST be exactly the one sent in EAP-AKA' AT_IDENTITY attribute, if one was sent, regardless of the kind of identity that it may have been. If no AT_IDENTITY was sent, the identity MUST be the exactly the one sent in the generic EAP Identity exchange, if one was made. Again, the identity MUST be used exactly as sent. If no identity was communicated inside EAP, then the identity is the one communicated outside EAP in link layer messaging. In this case, the used identity MUST be the identity most recently communicated by the peer to the network, again regardless of what type of identity it may have been. Just to check: there's a strong message sequencing, so that there cannot be ambiguity between peers about the "most recently communicated" identity? Section 5.3.1.1 23415099...@nai.5gc.mnc015.mcc234.3gppnetwork.org Should this be using an example domain name instead of 3gppnetwork.org? (I think "no", but have to check.) Section 5.3.2.1 For the null-scheme: type0.rid678.schid0.userid09@nai.5gc.mnc015. mcc234.3gppnetwork.org For the Profile protection scheme: type0.rid678.schid1.hnkey27.ecckey. cip.mac@nai.5gc. mnc015.mcc234.3gppnetwork.org [ditto] Section 6 The EAP-AKA' Session-Id is the concatenation of the EAP Type Code (0x32, one byte) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute: Session-Id = 0x32 || RAND || AUTN When using fast re-authentication, the EAP-AKA' Session-Id is the concatenation of the EAP Type Code (0x32) with the contents of the [...] nit: the second paragraph contradicts the first, since the first one does not disclaim that it's only for "regular authentication" (non-fast-reauthentication). Section 7 In general, it is expected that the current negotiation capabilities in EAP-AKA' are sufficient for some types of extensions and cryptographic agility, including adding Perfect Forward Secrecy ([I-D.ietf-emu-aka-pfs]) and perhaps others. But as with how EAP-AKA' itself came about, some larger changes may require a new EAP method type. Could we mention that we are not agile with respect to the use of SHA256/HMAC-SHA256? Section 7.2 Basin et al [Basin2018] have performed formal analysis and concluded that the AKA protocol would have benefited from additional security requirements, such as key confirmation. This feels a bit like a teaser -- what would be gained/prevented by using key confirmation? Is there a path towards performing key confirmation in the future? Section 7.3 As described Section 7.2, after the publication of RFC 5448, new nit: "As described in" In particular, it is crucial that manufacturers limit access to the secret information and the cards only to necessary systems and personnel. It is also crucial that secure mechanisms be used to communicate the secrets between the manufacturer and the operator that adopts those cards for the
[Emu] Benjamin Kaduk's No Objection on charter-ietf-emu-05-02: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for charter-ietf-emu-05-02: No Objection 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-emu/ -- COMMENT: -- Can we consider just saying "forward secrecy" rather than "perfect forward secrecy"? The "perfect" nature comes with many caveats in general... What's the relationship between "identifiers for fast re-authentication" and "creation of long-term credentials for the peer based on initial limited-use credentials"? There's a lot of stuff set to happen in Nov 2019; is that all staged and ready to go? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
