[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 sp
[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 ha
[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
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 > ass
[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
Re: [Emu] Protected Result Indicators in EAP-TLS 1.3
On Wed, Feb 10, 2021 at 10:48:10AM +, John Mattsson wrote: > With Alan's comments, I think we are down to 3 alternatives: > > (1a). Use close_notify alert as protected success. > Use error alerts as protected failure. > > - Forbid close_notify except as success indication > - Mandate Error alert before EAP-Failure > - Forbid all use of user_cancelled > > (1b). Use close_notify alert as protected success. > Use all other alerts as protected failure. > > - Forbid close_notify except as success indication > - Mandate Error alert or user_cancelled before EAP-Failure > > (2). Use application data as protected success. > Use all alerts as protected failure. > > - After sending application data in an EAP-Request the EAP-TLS server > MUST send only EAP-Success. > - Mandate alert (closure, error) before EAP-Failure > > I think it is important to discuss what the ongoing EMU consensus call will > mean in practice. Previous discussions was mostly about not sending more > handshake messages. Protected result indicators are quite different. > > It would we very good with early feedback from Ben and the TLS WG if they see > problems with any of the alternatives. On first look it seems like all of those will be able to achieve the required properties. In some sense it is "probably" going to be "easier" for an application using TLS to use TLS application data (as opposed to alerts) to affect its behavior, though I believe that TLS implementations generally do provide the needed information about received alerts and flexibility in what alert to send that's needed for the (1) variants. Another potential factor that I'm not (currently) equipped to evaluate is the reusability of the machinery defined by EAP-TLS for use by other EAP mechanisms. E.g., if we say that for EAP-TLS any application data is a protected success, would that be in conflict with any scenarios for the EAP mechanisms that do have to send some data on the TLS application data stream? I'd be happy to hear some more voices from the TLS WG chiming in to corroborate (or contradict) my conclusions in the first paragraph. Thanks, Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Mon, Feb 01, 2021 at 07:09:14AM -0500, Alan DeKok wrote: > On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk wrote: > > That's a scenario that I was starting to puzzle over this weekend as well > > -- with EAP-Success "completely unauthenticated", it would be fairly easy > > for an on-path attacker to send the EAP-Success the EAP peer was expecting > > and make the EAP peer think things succeeded even if the server had > > rejected the client cert. > > Yes. > > > Now, a server that has rejected the client cert > > is hopefully not going to be exporting the keys and continuing to run the > > next steps of protocol operation, but to some extent it seems that the > > security of the system as a whole relies on the server operating correctly > > in this regard. > > The TLS exporter keys are used for 802.1X / MacSec. But they're not always > used. Somehow I had convinced myself that the EMSK was only sometimes used, but MSK was always used. If MSK is always used, then key confirmation of the MSK can play the role of handshake (and client authentication) confirmation, but otherwise I seem to be coming around to your "4.5 round trips is unavoidable" conclusion. I'm not sure how clear-cut a distinction there is between cases that use the keys and those that don't, such that the last round trip could be shaved off when the exported key is used for key confirmation... > > ... it > > seems like a lot of what is being described as desired here ends up relying > > on ordering between application data and handshake messages. > > I think there's no implementation issue here. The draft should be clearer > that there's no guaranteed ordering. I was going to stick this in a reply to Joe (at https://mailarchive.ietf.org/arch/browse/emu/), but maybe I can sneak it in here and save a message in everybody's inbox. My understanding (based on https://tools.ietf.org/html/rfc5216#section-2.1.5) is that EAP-TLS fragments TLS records, or in some cases, groups of records, and the first fragment includes a four-byte length field for the total message being fragmented. Recalling that a given TLS record can only have payload of a single content type, in the scenario with a 0x00 confirmation message and a NewSessionTicket, that means one record with inner type application data and another record with inner type handshake. If they are both grouped together to the EAP-TLS fragmentation engine, then I agree that there is no issue and a proper implementation should be waiting to reassemble the whole fragmented bundle, including both records, before finalizing processing. But is it also allowed to fragment the two records separately? I didn't see anything that required the entire TLS flight of messages to be a single fragmentation input, and it's in the case that the 0x00 and NewSessionTicket are fragmented separately that the ordering becomes relevant -- if the 0x00 is fragmented first then the peer gets the complete fragmented message, sees the commitment message, and prepares its authentication flight in the EAP-Response, and based on the supposed commitment semantics would then somehow be expected to reject an EAP-Request with NewSessionTicket as breaking the commitment. (Assuming it had a way to tell it was a handshake message at all, that is...) I'd love to hear what I am missing that makes the above incorrect, and/or that we have a way to require the NewSessionTicket and commitment message to be part of the same fragmentation unit. > > (A lot of my hedging in messages on this thread is because I also don't > > really understand why the message is there.) > > I believe I read somewhere that it stemmed from the change in who speaks > > last in the TLS handshake, but am a bit hazy on how that implies it is > > needed. > > I would like clarification on just what that message *means*. If we want > an explicit EAP layer signal that the server saw the client cert and > authenticated it, then we MUST NOT send any such signal until after the > server has seen the client cert. And because the EAP-Success is sent all > alone, we MUST then have another full round of TLS exchange, before the final > EAP-Success. i.e. > > > EAP-TLS Peer EAP-TLS Server > > EAP-Request/ > < Identity > EAP-Response/ > Identity (Privacy-Friendly) > > EAP-Request/ > EAP-Type=EAP-TLS > <(TLS Start) > EAP-Response/ > EAP-Type=EAP-TLS >(TLS ClientHello)
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Mon, Feb 01, 2021 at 02:52:58PM -0500, Alan DeKok wrote: > On Feb 1, 2021, at 1:30 PM, Joseph Salowey wrote: > > [Joe] This could also address the early export of keys before the peer is > > authenticated. RFC 5216 provides a canonical way to create these IDs, but > > I'm not sure anyone follows it today > > FreeRADIUS does not officially expose Peer-Id or Server-Id. But the > certificate subjectAltNames are available via the policy engine. The greater > difficulty is *which* Id to use. > > RFC 5216 Section 5.2 says: > >It is possible for more than one subjectAltName field to be present >in a peer or server certificate in addition to an empty or non-empty >subject distinguished name. EAP-TLS implementations supporting >export of the Peer-Id and Server-Id SHOULD export all the >subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD also >export a non-empty subject distinguished name field within the Peer- >Ids or Server-Ids. All of the exported Peer-Ids and Server-Ids are >considered valid. I had missed that part of 5216 before. While you're mostly stuck doing that sort of "all names in the cert are deemed valid" for the TLS client certificate, since the server just asks for *some* cert and has to handle what it gets back, that's not the normal pattern for authenticating the server. Consider, e.g., the RFC 6125 procedure, which takes as input to validation the name that the TLS client was attempting to initiate communication towards. Depending on the application protocol that might be a DNS-ID or URI-ID or whatever, but there's still a clear "I initiated communication towards this specific named entity; can the server prove that it is that entity" which is very much not "they proved possession of the private key; all names are verified". Even for the same server and same certificate, the answer can be different for different names in the certificate. (I am about to clear a DISCUSS position on draft-ietf-quic-http for just this topic; the historical HTTP semantics are in line with RFC 6125. It is perhaps not strictly required that the EAP usage do the same, but it is surprising, at least.) > > and it may be difficult to implement in practice due to ordering. It might > > be simpler to just specify that the end entity peer and client certificates > > are used in the key derivation. Most libraries provide APIs to get the raw > > certs. > > Yes. We expose the certs to the policy engine, along with various fields. > Having the TLS exporter use more data should just be about updating some code. I think that you get better security properties if you include the entire certificates, but even just identities are better than nothing (provided there is a clear unique ordering/encoding, as you note). -Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Hi Alan, I'll second the thanks for putting this together; I think it covers the important open points. I did belatedly remember one more thing that is perhaps not critical, but would also be good to get an answer for: On Fri, Jan 29, 2021 at 03:00:51PM -0500, Alan DeKok wrote: [...] > > DISCUSS: other than word-smithing the above points, are there serious > objections to the behaviour documented in -13? i.e. does the IETF want to > recommend that EAP-TLS alpha testing begins *now*, or should it wait until > 2022? I think that an exchange between Martin and Mohit raised the question of whether the EAP server-id and peer-id would be available for use in the 'context' argument of the TLS Exporter, as that would help strengthen the binding between keys and the authentication exchange. I do recall a mention that WolfSSL doesn't support a context argument for the exporter, but I don't know how prohibitive that limitation would be in practice. -Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Mon, Feb 01, 2021 at 06:21:16AM +, Peter Gutmann wrote: > Alan DeKok writes: > > >OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages > >*after* the Finished message. i.e. the Session Ticket, etc. When an > >application calls SSL_Read(), all of the TLS data is processed, instead of > >just the "TLS finished" message. They've made this the default, because most > >applications get it wrong. > > Asking as the author of a TLS library that has always done this, why would you > stop immediately after the Finished and leave metadata messages sitting unread > in the input stream? Was it just some arbitrary implementation decision, or > is there a technical reason for it? I expect (but did not attempt to validate) that this was SSLeay-vintage logic involving only reading a single record from the wire per call to SSL_read(). If that record was a handshake record and not application data, well, then the SSL_read() didn't do something useful and so the special "try again" code was returned and the application was supposed to call SSL_read() again. There's no technical reason that I'm aware of. -Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Hi Alan, With my apologies to everyone on the thread for so many mails in succession... On Fri, Jan 29, 2021 at 02:09:09PM -0500, Alan DeKok wrote: > On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk wrote: > > With respect to the exporter usage, I do see you had asked about using the > > type-code as the exporter context value that Martin didn't see much value > > in, but I am willing to accept that as a boon for safety of portability to > > other TLS-using EAP mechanisms. > > OK. > > > (I do note that the current editor's copy > > shows calls to TLS-Exporter() with only two arguments, but three are > > required; the construction there also seems to include a propspect for > > violation of the requirement that "one label is not a prefix of any other > > label" when both regular one-byte and extended type codes are used, but if > > the type code is meant to be the context argument I believe that risk goes > > away.) > > The EAP type codes are one octet: 0x00 through 0xfd. The "expanded" type > codes begin with 0xfe. So there is no prefix issue, even if the type codes > form part of the label. Ah, of course I should have realized that the 0xfe octet separates them. You are correct; there is no issue with prefixes, and sorry for the confusion. Thanks, Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Hi Mohit, The quoting in your note is not coming across usefully in my MUA, so I'm trimming to (what I think are) just your remarks without other history. On Fri, Jan 29, 2021 at 07:34:42PM +, Mohit Sethi M wrote: > Hi Ben, > > RFC 5705 says: > >If no context is provided, it then computes: > >PRF(SecurityParameters.master_secret, label, >SecurityParameters.client_random + >SecurityParameters.server_random >)[length] > >If context is provided, it computes: > >PRF(SecurityParameters.master_secret, label, >SecurityParameters.client_random + >SecurityParameters.server_random + >context_value_length + context_value >)[length] > > > We use only two arguments and say "No context data is used in the TLS > exporter interface.". We could show the context argument as empty in the > calls to make things clearer. By the way, this is what is done by TEAP also. > RFC 7170 says "TEAPv1 makes use of the TLS Keying Material Exporters defined > in [RFC5705] to derive the session_key_seed. The label used in the > derivation is "EXPORTER: teap session key seed". The length of the session > key seed material is 40 octets. No context data is used in the export > process." We're using the TLS 1.3 exporter, though, so the RFC 8446 (https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5) three-argument form seems most relevant. Note that there is no difference in TLS 1.3 between an absent context and a zero-length context. > The change of moving the type-code from the context to the label was made > based on your review (comments from Martin) and the fact that some libraries > such as wolfssl don't support passing a context (so far). See: > https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996 I'm not going to get super hung-up on label vs context (but it's clearly a bug if WolfSSL doesn't support contexts). I guess Martin even wanted the type code to be in the label part in the first place, so having it in the label is "better"; we just need to actually show that there's an empty context argument. > I think there was a misunderstanding that an authenticated signal of > authentication completed was needed. Only a signal of no more post handshake > messages was needed. I think Alan's summary might also explain the situation > better. I note that Alan seems to also be a bit unclear about exactly what purpose the commitment message serves; I look forward to seeing how the questions he has listed get answered. Thanks, Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote: > On Jan 29, 2021, at 5:00 PM, Joseph Salowey wrote: > > DISCUSS: the EAP-TLS draft should also explain that session tickets may be > > sent either before or after the 0x00 octet. Does the packet flow look any > > different for the two cases? If so, what does that mean? > > > > [Joe] I believe the flow of the message flights would be the same, but the > > on-the-wire format of those flights could be reversed. I don't think this > > will necessarily cause a problem since the application data is consumed by > > the EAP TLS and the NewSessionTicket is consumed by TLS, However I think > > the draft should be clear that this can happen. > > I think so, too. I think we should talk about that, yes. But I haven't managed to convince myself yet that it is 100% safe in the face of fragmentation -- can we rule out a case where we end up delivering an EAP-TLS message that ends exactly at the end of the application data record (say, if bundled along with the tail end of the server handshake flight) and there is a NewSessionTicket queued that would get fragmented into the next EAP-TLS message? > > DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that > > this examples does not include Session Tickets. Section 2.1.2 should be > > updated to note that there are more rounds than for the previous section. > > > > [Joe] Yes. It might be helpful to say that the commitment message may be > > sent before or after the client authentication is verified, but in the case > > that resumption is used it will always be after. > > I think that's a good idea. The current draft doesn't make this explicit. > > But... if the commitment message is sent before the client certificates > have been authenticated, what does that commitment message *mean*? > > i.e. can the server send the commitment message, ignore the client cert > information, and send an EAP-Success? Even if the client certs have expired, > been revoked, etc.? Can the client detect a rogue server which always > answers "yes"? That's a scenario that I was starting to puzzle over this weekend as well -- with EAP-Success "completely unauthenticated", it would be fairly easy for an on-path attacker to send the EAP-Success the EAP peer was expecting and make the EAP peer think things succeeded even if the server had rejected the client cert. Now, a server that has rejected the client cert is hopefully not going to be exporting the keys and continuing to run the next steps of protocol operation, but to some extent it seems that the security of the system as a whole relies on the server operating correctly in this regard. Strictlys speaking, it need not do so -- we could have defined a mechanism where the exported keys depend, cryptographically, on the client authentication flight such that the TLS layer will not produce the needed keys on failed authentication. [0] I'm assuming that people will not be terribly keen on switching to such a scheme given that (AFAIK) it would require defining a new TLS 1.3 Exporter variant that includes the full transcript hash, [1] not just up to Server Finished, which would incur at a minimum several months' delay. It might be worth asking the teams that did formal analysis work on TLS 1.3 how they modelled client authentication and what assumptions on server behavior they made. So, if we do not wait for a cryptographic method to assure successful client authentication, and thus are going to be stuck requiring some amount of trust that the server is doing the right thing with the keys, how is it different to say that the server is going to not export the keys if the client authentication fails vs saying that the server is going to not export the keys if it is not done sending handshake messages? There is perhaps some detail in terms of how EAP-TLS interacts with the TLS layer and what information is available when, but it seems that if you have an interface with TLS of "provide input bytes; get output bytes out" [2] you could achieve this by not exporting keys until you've sent all those bytes into EAP-TLS messages. > RFC 4137 (https://tools.ietf.org/html/rfc4137) describes a state machine > for EAP peer and server. Does this work follow that? A good question! > > [Joe] If we are going to make a change in the key derivation we should do > > it now. Personally, I think we should update the key derivation to > > separate the MSK and EMSK, but it is workable as is. > > I think there are potential issues around the ordering of the 0x00 octet > > and other messages, but I don't think this will require changes to > > implementations in the short term, but the spec needs to clarify this. > > I agree. I wonder if (assuming that 0x00 goes forward instead of "close_notify") we should also go further and say that this mechanism does not use stock TLS 1.3, but rather a variant of the protocol that imposes an
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Hi Alan, I see that the thread is continuing and that perhaps my reply will even become stale as I write it, but I'm replying to your note instead of the tip of the thread because it has good context for making some broader points that I would like to make. On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote: > We're approaching 2 weeks since the last discussion of this topic. This > document has been in development for 3 years. We desperately need to finish > it. IMHO waiting another 6 months is not an option. Even 3 would be > worrying. My understanding of the discussions involving the TLS WG are that we forked off into two sub-threads: one about the use of TLS Exporters for key derivation (the one this is a reply to), that largely concluded with agreement on a simple change to make, and the other sub-thread about the protocol element known in -13 as the "commitment message". With respect to the exporter usage, I do see you had asked about using the type-code as the exporter context value that Martin didn't see much value in, but I am willing to accept that as a boon for safety of portability to other TLS-using EAP mechanisms. (I do note that the current editor's copy shows calls to TLS-Exporter() with only two arguments, but three are required; the construction there also seems to include a propspect for violation of the requirement that "one label is not a prefix of any other label" when both regular one-byte and extended type codes are used, but if the type code is meant to be the context argument I believe that risk goes away.) With respect to the "commitment message", I thought we had a discussion that revealed that the mechanism in the -13 could not fulfil its stated purpose, and that also called into question whether that stated purpose was actually the right thing that the protocol needed. My understanding, therefore, was that the TLS WG could not contribute further insight until there was a revised proposal from people who understand the needs of the EAP-TLS protocol from TLS that would both satisfy the needs of EAP and actually be achievable. > We have multiple inter-operable implementations which have implemented > draft-13. That work over the last few months have resulted in implementors > making plans to do beta testing in the next few weeks. Those plans have been > put on indefinite hold, due to the recent request for changes. > > I understand getting feedback from the TLS WG is useful. But I would > prefer to have consensus on a *solution*. Right now, we just have a series of > proposed changes, with little to no discussion. I think this is becaues the TLS WG members (in aggregate) do not have a clear picture of what property or properties EAP-TLS will require from TLS that led to the need for an additional message when using TLS 1.3 as opposed to the RFC 5216 case with TLS 1.2. The prospect of an "authenticated signal from TLS to EAP-TLS that the authentication completed successfully" was mentioned, but I did not have the sense that there was universal agreement of that as the sole relevant property. > We're getting to the point where we have to ship code as promised to > customers soon (weeks, not months). We therefore need consensus, as soon as > possible. > > My preference is to implement draft-13. We know the code works. People > are ready to ship it. Any changes will add not just more months of standard > discussion, but more months of interoperability testing. > > If there is no progress in EMU, we're looking at September for first betas. > With no guarantee that there won't be further changes made after that. > > So the question is: > > * are the draft-13 0x00 byte and exporter *terrible* enough to delay the > standard another 6 months? Well, the text of the -13 contains a protocol mechanism that cannot deliver its stated purpose, so I will continue to hold a Discuss position if that remains. One Discuss ballot does not have to block the work indefinitely (the shepherding AD can request a different IESG balloting procedure be used), and I leave it between the WG and Roman whether to attempt that route. It is perhaps possible that (as John noted downthread) the text about the commitment message was badly written, and that just changing the surrounding description could work, but that gets back to the question I mentioned above of what properties EAP-TLS actually requires from TLS. -Ben > * if the answer is "no", then we can ship now. > > * if the answer is 'yes", then the next question is "when can we get this > finalized?" "March" would be late. "July" is a major problem. > > > On Jan 12, 2021, at 10:22 AM, Alan DeKok wrote: > > > > On Jan 11, 2021, at 7:08 PM, Martin Thomson wrote: > >> I was not exactly. I was thinking that EAP-TLS uses the unadorned string > >> and other usages (that need a different MSK) define their own string as > >> needed. > > > > Which is largely what was done for <= TLS 1.2.
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote: > On Jan 5, 2021, at 4:47 AM, Mohit Sethi M wrote: > > What I am gathering is that this commitment message should instead be > > made into a confirmation message, i.e. it should only be sent after > > receiving TLS Finished from the client? This would result in one extra I forget if it has been explicitly mentioned in the thread so far, but https://tools.ietf.org/html/rfc8446#section-4.4.4 is pretty clear that "Servers MAY send data after sending their first flight, but because the handshake is not yet complete, they have no assurance of either the peer's identity or its liveness (i.e., the ClientHello might have been replayed)." In particular, "no assurance of the peer's identity" means that the server is at this point sending to an unauthenticated client. If the goal of EAP-TLS is to ascertain that there is in fact an authenticated client, it may be ill-advised to send indications of overall success to an unauthenticated client. Part of what Martin alluded to with the situation being lousy overall is that there are basically two things that can cryptographically confirm that the client has authenticated: successful processing of the client Finished, and values derived from the resumption master secret. In "normal" TLS usage the server will bail out if the client Finished doesn't validate, so continued receipt of application data, including application data bearing application-protocol responses to data the client sent in 1-RTT after client Finished, effectively implies that the server validated the client Finished, but the EAP-TLS usage is quite different from that. There's not a cryptographic way to tell whether 0x00 application data was generated before or after the client Finished was processed. > > round trip to both figure 1 and 3 in the current draft. So we would end > > up with the same number of messages as RFC 5216 for full authentication > > (https://tools.ietf.org/html/rfc5216#section-2.1.1) and actually do > > worse than RFC 5216 (one extra round trip) in case resumption > > (https://tools.ietf.org/html/rfc5216#section-2.1.2). > > That sounds right. While counting arrows in the diagram like this is definitely useful, part of my concerns related to the need (in non-resumption flows) to convey the entire (enlarged) server Certificate chain in individual 1020-byte EAP-Requests. My understanding was that the server had to send a single 1020-byte EAP-Request and wait for the corresponding EAP-Response before sending the next chunk of the certificate chain. It was in that scenario that I expected a substantial difference between resumption and non-resumption. > > Maybe this is acceptable? The draft anyway notes that "Sending the > > Commitment Message in a separate EAP-Request adds an additional > > round-trip, but may be necessary in TLS implementations that only > > implement a subset of TLS 1.3.". In which case, I am not sure if the > > reasons against using close_notify apply anymore. > > I won't offer opinions on TLS internals, as I'm out of my depth there. > > As an implementor, the priority is getting TLS alerts (expired cert, etc.) > back from the EAP server to the EAP peer. Those messages can then be used to > debug deployment issues. > > The exact method of doing this is less important. The "0x00" octet works > now, so I'm happy with it. But if TLS review decides that should change, > that's fine, too. It's pretty much guaranteed that we can get the TLS alerts if we always wait for client Finished to be processed (whatever signal we end up choosing to send after that occurs). Have we reached agreement on whether we should always wait for client Finished? -Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Tue, Jan 05, 2021 at 11:12:21AM -0500, Alan DeKok wrote: > On Jan 5, 2021, at 11:05 AM, Michael Richardson wrote: > > > > Alan DeKok wrote: > >> Therefore, we need an explicit signal to the EAP-TLS layer that the > > > > Do you mean, "to the EAP layer"? > > s/EAP-TLS layer/EAP/ ?? > > If the EAP-TLS layer allows TLS negotiation OR EAP-Success, then it's > possible to bypass TLS by spoofing an EAP-Success. So the EAP-TLS layer > needs to have a way to say "we're done, EAP-Success is now OK". > > It's really nested: EAP ( EAP-TLS ( TLS ) ) > > We can't finish EAP until we know that EAP-TLS is finished. We can't > finish EAP-TLS until we know that TLS is finished. Okay. What step suffices to determine that "TLS is finished" for your use case. The natural definition is "the handshake is complete", which would be incompatible with the text currently in the draft (and with 0.5-RTT entirely). -Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Mon, Jan 04, 2021 at 02:44:01PM +1100, Martin Thomson wrote: > > I would instead either prohibit the use of application data outright or say > that it carries no semantics unless otherwise negotiated. The current design > has the effect of rendering application data unusable, so perhaps the former > is best. The "rendering application data unusable" bit is something that bothered me a lot as well. While banning application data is okay for EAP-TLS itself (AIUI), the document implies that other TLS-based EAP mechanisms do need to convey application data, and I think that the responsible thing to do is ensure that the machinery we use here would be compatible with those other EAP mechanisms with no, or only minimal, changes. > # Key Schedule > > The other thing I observe is the way that this slices up the exporter output. > This was something that old versions of TLS did, but TLS 1.3 did away with. > Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to. This could - > and should - do the same. All it means is having more exporter labels. > > I appreciate that this uses exporters now rather than abusing the internal > PRF. That's good. The next step is to dispense with the intermediate values > (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS > exporter for each of the six values that the protocol requires. I also note > that the 0x0D value is used multiple times, unnecessarily, both as a context > strong to the exporter and as a prefix to the session ID. I think Alan explained the dual purpose of the Type-Code here. (I myself had missed the connection of where the 0x0d value came from, and a reference for that seems like it would be helpful, as setting up this machinery for reuse by other mechanisms in a way that provides key separation.) -Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Tue, Jan 05, 2021 at 10:26:40AM +1100, Martin Thomson wrote: > On Mon, Jan 4, 2021, at 21:01, Mohit Sethi M wrote: > > > I have a much simpler one: the EAP layer has a signal that the > > > protocol is complete: EAP-Success > > Alan Dekok explained in a separate email thread why this is not the > > case > > (https://mailarchive.ietf.org/arch/msg/emu/uMNKV_vfov7ASob6_Qu3FlCNcT0/). > > He wrote: "The EAP-Success and EAP-Failure messages are *not* protected. > > i.e. they are 4-bytes of data which can be spoofed rather trivially.". > > I specifically addressed that point in my original email. My assertion was > that this is not an significant concern. > > Your point about reliability is confusing. I've read Section 4.2 of RFC 3748 > and while it says "A peer MUST allow for this circumstance as described in > this note.", I see no explanation of how to concretely make that allowance. > Are you saying that EAP methods don't really use EAP-Success and condition > their behaviour on other signals? For TLS 1.3, where the server indicates > success before the client, I can see how you might want a reliable > confirmation that the server has accepted the client Finished. > > As an aside, this makes is clear that the signal does not exist for the > reason implied by the draft. It does not exist to signal that the TLS > messages are done; it exists to signal that the server has received and > accepted the client Finished. To that end, it's not really a layering > violation in the sense that Ben describes. The layering violation exists > only because of the language constraining what TLS does thereafter; in that > case, a language cleanup might be enough to address the concerns. > > Note however, that the proposed design does not guarantee that a Confirmation > Message acknowledges the client Finished. The server can send the proposed > Confirmation Message before the client completes the handshake. > > Echoing the client Finished might help, but that's a layering violation too. > Ideally you would be able use something like exporters to help, but those > have problems (see below). I know it's a knee-jerk, but the idea of making > EAP-Success reliable is far more appealing to me than anything you suggest. > > > I also think that this should not be treated as an issue for EAP-TLS > > only. I can imagine other deployments which use TLS for making > > authorization decisions but do not use the TLS for sending message. So > > I am glad that Ben has brought this to the TLS working group for > > further discussion. Whether we use this 1-byte of application data (as > > done in this draft) or some other mechanism (such as close_notify), we > > need a reliable way of telling that no further post handshake messages > > will be sent. > > EAP has the privilege of being the first to grapple with this. > > I'm going to suggest something slightly scandalous: TLS 1.3 exporters are not > the ideal design. They should have included the full handshake transcript, > just like the resumption secret. There were good reasons at the time for > designing them as they are, and there are likely reasons to retain the > current design as an option (it's stronger than the early exporter and there > might be use cases), but those original reasons are less relevant. The > current design gives short shrift to client authentication, to the detriment > of use cases like EAP. I was just grappling with this topic recently in a different context. I agree that it would be good to have at least some version of an exporter available that includes the full transcript's hash in the context. It seems to have made some implicit assumptions about how TLS is used (to carry application data, not as a key-exchange or authentication mechanism) and how TLS records are carried (over TCP, which serializes handshake messages and application data; not the case for QUIC) that are causing problems for us now. That said, it doesn't seem like it would be *terribly* complicated to specify a new type of exporter interface that does use the full transcript. It might have to be TLS 1.3+ only, and getting the IANA considerations right might be gnarly, but the core of it seems pretty simple. > Having exporters depend on the entire transcript would serve EAP better. In > this case, you could provide an application-level signal using an exported > value. > > Without that sort of in-TLS affordance, confirming receipt of the client > Finished might do. You still have the possibility that the server doesn't > depend on client authentication and so predicts the value, but that would be > true of a full-transcript exporter too, so arguably that doesn't matter. If there truly is a need for a signal from TLS to not generate more handshake messages (including to tear down the connection if KeyUpdate would be needed), that seems like it is arguing for a new TLS handshake message. I am not 100% sure whether
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Hi Martin, Thanks for chiming in here; your insight has been quite helpful already. (I am going to reply to the thread in reverse order so as to not duplicate what you've already said.) On Tue, Jan 05, 2021 at 02:50:15PM +1100, Martin Thomson wrote: > Hi Alan, > > On Tue, Jan 5, 2021, at 14:05, Alan DeKok wrote: > > On Jan 4, 2021, at 6:26 PM, Martin Thomson wrote: > > > Your point about reliability is confusing. I've read Section 4.2 of RFC > > > 3748 and while it says "A peer MUST allow for this circumstance as > > > described in this note.", I see no explanation of how to concretely make > > > that allowance. Are you saying that EAP methods don't really use > > > EAP-Success and condition their behaviour on other signals? > > > > EAP-Success by itself is *not* a reliable indication of Success. See > > RFC 3748 Section 4.2: > > > >Success and Failure packets MUST NOT be sent by an EAP authenticator > >if the specification of the given method does not explicitly permit > >the method to finish at that point. > > This is fine. What you might be concerned about is the nature of the signals > that the EAP authenticator is receiving from TLS. What you had in the case > of TLS 1.2 was the stack providing bytes to send (which were to go in > EAP-Request) and then, after everything is done, a positive signal saying > that the handshake was complete and satisfactory. That latter signal is the > important one. Yes. Part of what had me so unhappy about this document is that the Commitment Message is discussed only as a "promise to not send more handshake messages", not "an indication that the handshake is complete and the TLS layer is happy". (Furthermore, what Alan writes below about "cannot distinguish a "finished authentication" EAP-Success from a "spoofed" EAP-Success" really needs to make its way into the document.) > TLS 1.3 muddies things by allowing bytes to be sent *after* the > complete+satisfactory signal from TLS. That's what you are grappling with > here. What I'm suggesting is that you don't rely on looking at what bytes > hit the wire, but wait until two conditions are complete: > > 1. The TLS stack says that it is content: the handshake is complete and it is > OK with whatever the other side has provided. > 2. The TLS stack has no more bytes to send. > > The latter is likely where the confusion comes from, but if the stack doesn't > produce bytes when you give it bytes, then you don't need to keep waiting. > For what you depend on, that's enough. I agree that this is probably good enough. There may be some complications depending on how badly the availability of session resumption is desired (I know OpenSSL provides an API to let the application requst a new session ticket regardless of whether any were sent with the initial handshake -- I wrote it -- though I need to tweak it so that it will not always wait for application data to send before sending the ticket), but I believe this provides the key functionality. > The mistake with sending application data is that there is no obligation on > the part of the TLS stack to order its sending of NewSessionTicket relative > to the application data. Nor is is possible for you to correctly distinguish > TLS data that contains your Confirmation Message from a record that just > contains a little bit of a session ticket. But you don't need to worry about > that. > > An example might help illustrate: > > 1. ... many steps occur > 2. Client sends EAP-Response ending in a TLS Finished. > 3. Server reads that message, processes it and determines that the handshake > is complete and acceptable (e.g., checks the client certificate against its > policy). > 4. As the server is happy, it writes the Confirmation Message to TLS. > 5. Server asks TLS stack for outstanding data to write; TLS stack provides a > bunch of application_data records. (In particular, this is the TLSCiphext content type that is "application_data", and the inner content type could be handshake or application data. The application doesn't have visibility into it.) > 6. Server writes TLS records into an EAP-Request and sends it. > 7. Client receives this and sends an empty EAP-Response. > 8. Server sends EAP-Success. > > This is, I assume what you intend here, with a little more detail around > steps 3-5. But what happens if the TLS stack prioritizes application data > above its own maintenance such that at step 5 the Confirmation Message is > written to the wire before the TLS NewSessionTicket? Is that a problem? > What validation is the client expected to perform at step 7? I would like to see a more precise description of what properties are actually needed by peer and responder here, yes. I agree that TLS 1.3 has changed things compared to 1.2, but the text currently in the draft doesn't do very well to motivate why this information is important, and (at least to me) doesn't give a strong enough justification to
[Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Hi TLS WG, I'm forwarding my ballot comments on the (now-deferred) EAP with TLS 1.3 draft here, since they relate to some rather core TLS protocol concepts, and I'd like to get some broader feedback with the extra time given by deferring the ballot. Please ensure that comments reach the EMU WG list (cc'd). Thanks, Ben On Wed, Dec 16, 2020 at 02:36:50PM -0800, Benjamin Kaduk via Datatracker wrote: > 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 m
[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 th
Re: [Emu] Benjamin Kaduk's Yes on draft-ietf-emu-eaptlscert-06: (with COMMENT)
On Wed, Nov 04, 2020 at 04:41:07PM +, Mohit Sethi M wrote: > Hi Ben, > > This should hopefully address your feedback: > https://github.com/emu-wg/eaptls-longcert/commit/d39c1411c908844cc74bc0a6fa689a73ecd5b7a8 > > Answers in-line. Thanks Mohit! I left one wording tweak (s/defines/proposes/) on the github commit, but otherwise this all sounds fine to me. -Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[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 dis
Re: [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06
Hi Stefan, Thanks for the review; it raises some good topics. Replying on a couple points... On Thu, Oct 29, 2020 at 04:13:02PM -0700, Stefan Santesson via Datatracker wrote: > Reviewer: Stefan Santesson > Review result: Has Nits > > The document in general is good and well written. > > Some nits needs attention before publication as the general review also points > out. Ex in the abstract "This document looks at the this problem" > > Some abbreviations needs to be spelled out at first usage, such as MTU > (Maximum > Transmission Unit) MTU may actually be okay; per https://www.rfc-editor.org/materials/abbrev.expansion.txt it is marked as "well-known" and does not always need to be expanded. > On the content itself I have two questions: > > - Wouldn't it be relevant to also discuss the risks with regard to > introduction > of quantum safe crypto, if that leads to significantly increased key sizes? It > could be troublesome if transition to a safer crypto is made impossible due to > size limitations. - Would it be relevant to discuss usage of AIA extension as > means of possibly excluding intermediary certs from the path as they could be > located using AIA? > > Finally, I agree with the general review that this document reference quite > some work in progress. If this document is to be published before these > referenced works are concluded, are there alternatives to make the same point? They seem to mostly be informative references, and so would not require us to hold publication of this document. It is probably still worth considering if there are alternatives anyway, though. -Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
Hi Mohit, Sorry for the slow response. On Fri, Jul 31, 2020 at 02:08:44PM +, Mohit Sethi M wrote: > Dear all, > > Thanks all for the discussion on the commitment message. > > draft-ietf-emu-eap-tls13-10 > (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10) in figure 2 shows > the ticket establishment and commitment message: [snip] > > and the relevant text on commitment message: > > When an EAP server has sent its last handshake message (Finished or a >Post-Handshake), it commits to not sending any more handshake >messages by sending a Commitment Message. The Commitment Message is [reordering] > > I couldn't parse the comments about the "KeyUpdate" message. Perhaps having > the discussion over email will help me understand the issue. > I was referring to the specific promise to not send any more *handshake* messages here -- the only currently defined handshake messages that the EAP server could be sending are NewSessionTicket and KeyUpdate. (Okay, or EKTKey from draft-ietf-per-srtp-ekt-diet, but EAP is not using that at all.) I was not sure if the need was to avoid sending KeyUpdate vs. NewSessionTicket, and why the application layer needed to be concerned with it at all -- to some extent both can be handled internally by the TLS implementation. The application probably wants to get involved if it wants to resume using a session ticket, but it's permitted to just drop the tickets on the floor and never use them. >a TLS record with application data 0x00 (i.e. a TLS record with >TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and >TLSPlaintext.fragment = 0x00). Note that the length of the plaintext >is greater than the corresponding TLSPlaintext.length due to the >inclusion of TLSInnerPlaintext.type and any padding supplied by the >sender. EAP server implementations MUST set TLSPlaintext.fragment to >0x00, but EAP peer implementations MUST accept any application data >as a Commitment Message from the EAP server to not send any more >handshake messages. The Commitment Message may be sent in the same >EAP-Request as the last handshake record or in a separate EAP- >Request. Sending the Commitment Message in a separate EAP-Request >adds an additional round-trip, but may be necessary in TLS >implementations that only implement a subset of TLS 1.3. This construction feels weird to me because it's using application data to try to make a promise about the TLS layer, which is a fragile construction and could break if there are changes to the TLS implementation without corresponding changes to the application code. In general, the application will not even know when/whether the TLS implementation is going to send more messages (though it would be fairly surprising for the TLS implementation to spontaneously send stuff in the absence of other application messages). Using close_notify as we seem to be agreeing upon feels better since it's the TLS-layer mechanism for doing so and the TLS implementation is expected to do the right thing in terms of not sending more messages, once it's sent or received. -Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] bootstrapped TLS authentication and TLS key schedule
Hi all, I'm not 100% sure if I'll be present for the whole session on Friday, so just in case I'm not: it looks like there's a figure in the slides to adjust the TLS 1.3 key schedule and put another input slot in place. I don't expect any of these comments to be a big surprise (especially given the chair overlap!), but mention them just to be sure that everyone's on the same page: please coordinate with the TLS WG if there are key schedule changes, and the TLS WG would rather there not be a proliferation of key schedule changes. We had some work presented yesterday on a TLS "extended key schedule" and it is looking fairly likely that we'll end up with a generic "one place to shove extra stuff in" that can take multiple different "extra stuff" at once. I'd be surprised if that wasn't workable here, so please keep an eye out for it. Thanks, Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[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
Re: [Emu] [Iot-directorate] Iotdir early review of draft-ietf-emu-eap-noob-01
On Sat, Jul 11, 2020 at 03:40:25PM +0200, Carsten Bormann wrote: > Hi Mohit, > > > > On 2020-07-11, at 15:27, Mohit Sethi M > > wrote: > > > > EAP-NOOB also relies on the JWK specification for encoding public keys. > > While CBOR equivalent is defined in RFC 8152, it is a rather large document > > that contains all the functionality of JWK, JWS, JWA (as far as I > > understand). Following smaller modular specifications was somehow easier at > > the time. > > RFC 8152 does have a section structure, so you don’t need to read all of it > to just get the equivalent of JWK. draft-ietf-cose-rfc8152bis-struct and draft-ietf-cose-rfc8152bis-algs have section structure, too :) -Ben ___ 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 Prot
[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 co
Re: [Emu] Murray Kucherawy's No Objection on draft-ietf-emu-rfc5448bis-07: (with COMMENT)
On Sat, Apr 04, 2020 at 10:48:03PM -0700, Murray Kucherawy via Datatracker wrote: > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ > > > > -- > COMMENT: > -- > [...] > > Section 7.3: > Nit: > * "Perfect Forwards Secrecy …" -- s/Forwards/Forward/ > FWIW, we had a recent thread on saag@ that seems to have converged on preferring "Forward Secrecy" to "Perfect Forward Secrecy". -Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [lamps] Using public CA infrastructure for autonomic bootstrapping over EAP.
Hi Michael,
You mention in a couple places that EAP server certificate should be
identifying an rfc822Name DN, and I think I'm confused about what you mean.
(I suspect I'm seeing "rfc822Name" and jumping to what ACP does, which is
wrong.) Could you walk through an example of what that would look like to
help un-confuse me?
Thanks,
Ben
On Fri, Jan 17, 2020 at 05:19:39PM -0500, Michael Richardson wrote:
>
> {I've intentionally broken the thread, and I'm restarting the discussion.
> Please forgive the length}
>
> Alan DeKok wrote:
> >> Certainly, some of the excitement for ACME/Letsencrypt with DNS-01
> challenge
> >> is that it makes it easy to get a certificate for a non-HTTP thing.
> >>
> >> I think we need to fix the lawyers, not the protocol.
>
> > That is likely the best approach. At this point, use of
> > id-kp-serverAuth is wide-spread *outside* of HTTP. EAP / RADIUS is not
> > unique in it's mis-use of that OID.
>
> I went back to your message at:
> https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM
>
> to be sure what the state of the art is today:
> } a) the current practice in TLS-based EAP methods is to use certificates
> with
> } "id-kp-serverAuth" OID set for Extended Key Usage.
> } b) many supplicants check for this OID, and refuse to perform
> authentication
> } if it is missing
> } c) supplicants do not check DNS names or any other field in the
> certificates
> } d) as a result of this lack of verification, supplicants ship with all
> known
> } CAs disabled for TLS-based EAP methods"
>
> [c] is a problem that we partly want to fix.
> [a] LetsEncrypt and other ACME mechanism technically work to get certificates
> from public CAs that can be used for this.
>
> These certificates can, and *ARE* being used for SMTP, XMPP, as well as HTTPS.
> Using these certificates for things other than HTTPS might violate the CSP of
> the CAs involved, one would have to read the relevant CSPs.
> At least one CA is using a certificate that would appear to be a "stock"
> HTTPS certificate on an SMTP server.
> I know dozens of places that have wildcard certificates (which all bind to
> the same private key, which I really rather hate) which are then used for all
> manner of things.
> I think I've seen certificates being advertised for use in email servers, but
> I'd have to go back and be sure.
>
> Let's go back to the start with goals and requirements.
>
> 0) there is nothing broken with manual provisioning of private CAs to be used
>in Enterprise-WPA (EAP-TLS, etc.) uses of EAP/802.1X. This can continue
>as is. The server certificate needs to have id-kp-serverAuth OID set in
>order to be trustable by comododity clients as deployed today.
>There is very little use of additional OIDs, even those some have been
> defined.
>Clients do not insist upon them, and *as a result*, it is technically
>possible to use certificates issued by public CAs here.
>
> 1) we have some protocols that do autonomic onboarding of devices.
>BRSKI is one such protocol. Not the first, but the most public and most
>cross-vertical one. But probably it won't be the last one!
>
>**BRSKI does not require that the domain owner have a public CA**
>
>In fact, BRSKI provides a mechanism that permit a devices to autonomically
>develop trust in a private CA via the pinned voucher artifact.
>One can proceed to do EST/RFC7030 if one wants after and get the local
>list of of private CAcerts.
>
>In some wired situations it is also possible to use *JUST* EST/RFC7030 for
>enrollment, if the client(pledge) is willing to trust the certificate of
>the server, such as because it comes via public trust. I will note that
>EST uses HTTPS, and having a name from a public CA could not reasonably
>break any CSP.
>
>While the CAFORUM rules forbid certificates for private names
>(foobar.corp, foobar.internal), and it also forbids issuance for RFC1918
>addresses, it currently permits certificates for public names
> (foo.example.com), even
>if those addresses have only IP addresses, and it currently makes no
>statement about ULA addresses in public names.
>Whether this is a loophole of intention or omission, I don't know.
>(I have running code)
>
>There are a number of industrial uses for EST/RFC7030 where the interest
>is in validating the IDevID of the pledge in order to detect counterfeit
>products.
>It is not apparent how this (EST-only) can be done over WiFi in an
>autonomic way, and thus this is one of the places for BRSKI protocols like
>BRSKI-TEAP. But, again BRSKI does not require a public CA/name.
>
> 2) BRSKI (-like) protocols suggest that the domain owner (the Registrar) be
>connected to a private CA to issue LDevID. There is a desire to simplify
>this requirement in order to make use of ACME based systems to
Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
A couple things that stand out to me from having basically read the whole thread in one go (this is not intended to be an exhaustive list of open questions): It was implied but not fully clear to me, that Ryan thinks that someone so inclined could, right now, go around trying to connect to wifi using EAP authentication, grab a packet capture of the remote server using its id-kp-serverAuth certificate for authenticating the TLS-over-EAP connection, and report that certificate to its issuing CA as "misuse" requiring prompt revocation, at least for several major CAs. It's quite probably that I missed them as they went by, but specific links to specific CA policy documents that would classify such certificate usage as "misuse" (requiring revocation) would help clarify things, at least for me. Is there anything better for implementations to actually do (as distinct from what we write down as recommendations) than to start setting up a parallel (purpose-specific) PKI now and trusting that in parallel with what they're currently doing, with the hope of being able to have a flag day many years down the line when the new PKI becomes the only thing that's trusted? -Ben On Wed, Jan 15, 2020 at 07:20:37PM -0800, Joseph Salowey wrote: > There has been a lot of discussion on this thread, but I do not see > anything actionable for the EAP-TLS 1.3 specification. > > Joe > > On Wed, Jan 8, 2020 at 12:48 PM Alan DeKok > wrote: > > > On Jan 8, 2020, at 3:00 PM, Michael Richardson > > wrote: > > > > > > > > > Alan DeKok wrote: > > >alan> Many people use private CAs. Many use public CAs. *All* of > > them > > >alan> use id-kp-serverAuth. Common EAP supplicants (MS / Apple / > > etc.) > > >alan> ship with known root CAs. These root CAs are trusted by default > > >alan> for web browsing. None are trusted by default for EAP. > > > > > > How can anyone be using public CAs for EAP, if none are trusted for EAP, > > and no > > > public CAs issue certificates with id-kp-serverAuth? > > > > Every CA is manually enabled. > > > > Either by an end user, or by / on behalf of, an administrator. > > > > The goal I'd like to reach is some method to allow supplicants to > > automatically trust and enable certificates for EAP. > > > > Alan DeKok. > > > > ___ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > > ___ > Spasm mailing list > sp...@ietf.org > https://www.ietf.org/mailman/listinfo/spasm ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Benjamin Kaduk's No Objection on charter-ietf-emu-05-02: (with COMMENT)
On Thu, Oct 31, 2019 at 04:25:57PM +, Mohit Sethi M wrote: >Hi Ben, > >Thanks for the customary careful review. Answers in-line: > >On 10/31/19 4:24 PM, Benjamin Kaduk via Datatracker wrote: > > 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... > >Makes sense! > > > 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"? > >Good question: > >Session-Id is a particular type of identifier that must be exported by EAP >methods according to RFC5247 (https://tools.ietf.org/html/rfc5247). As >implicit from the name, it identifies a particular EAP authentication >session. EAP methods should export this identifier during usual full >authentication as well as abbreviated fast-reauthentication. Some EAP >methods (EAP-SIM, EAP-AKA, EAP-PEAP and EAP-AKA') lacked this information. >There is a draft fixing this (draft-ietf-emu-eap-session-id-00). It is >only dealing with a narrow bug that was discovered during implementation. > >Creation of long-term credentials based on initial limited-use credentials >is not about session identifiers. It tries is trying to address the case >where the initial credentials are time or domain limited (such as device >certificates from manufacturer) and need to be updated with operational >long-term credentials (such as certificates from the local network >operator). Both these credentials can be used for EAP authentication >(albeit with different servers) and will result in different Session-Ids. That makes sense; thanks for setting it out for me. > > There's a lot of stuff set to happen in Nov 2019; is that all staged and > ready to go? > >Yes! Excellent! -Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[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
