[Emu] Re: Orie Steele's No Objection on draft-ietf-emu-rfc7170bis-16: (with COMMENT)
On Tue, 21 May 2024 at 02:24, Alan DeKok wrote: > > 896Implementations SHOULD limit the permitted inner EAP methods > to a > > 897small set such as EAP-TLS, EAP-MSCHAPv2, and perhaps > EAP-pwd. There > > 898are few reasons for allowing all possible EAP methods to be > used in > > 899Phase 2. > > ``` > > > > I wonder if there are really any reasons to allow all possible methods, > and > > what impact they have on interop. > > The methods listed above are the most widely implemented, and are thus > expected to work. > > Other EAP methods such as EAP-AKA are intended for use with the 3G+ > telecommunications network. There isn't much point in using them inside of > a TEAP / TLS tunnel. So it's best to suggest that they not be used > I'd say if EAP-TLS is allowed then SIM based EAP should be allowed too. A couple of reasons follow: First, EAP-SIM, EAP-AKA and EAP-AKA' have a bit similar privacy problem that EAP-TLS does with TLSv1.2 and earlier. The SIM based EAPs reveal the user's identity, the IMSI from the SIM, that is unique and can be used for tracking a the SIM user. This happens with the first authentication. With subsequent authentication there three EAPs have ways to use temporary identities for privacy. Even with temporary identity, if an attacker can make the SIM based EAP client to try to authenticate, the attacker can request the real identity. This is allowed because the client can't reliably know when the server has lost the track of temporary identity. Windows, for example Windows 11 on a laptop with a SIM slot, supports EAP-TTLS with SIM based EAP as inner protocol. Similarly Android (WPA supplicant) supports tunnelling SIM based EAPs over PEAP. Plain WPA supplicant likely supports any EAP within TEAP tunnel. Second, considering draft-ietf-emu-aka-pfs, I'd also say this draft gives one more reason to use a tunnelling EAP when use of plain SIM based EAP is a concern. With the above being said, using SIM based EAPs with tunnelling EAP methods is likely rare. I have never seen them used in practice. However, real implementations exist that allow doing this. Maybe, for example, IOT experts could say if they see use for TEAP/PEAP/EAP-TTLS used for tunnelling SIM based EAPs? -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
[Emu] draft-dekok-emu-eap-arpa-01 and WBA unauthenticated EAP-TLS
Draft draft-dekok-emu-eap-arpa-01 has the following text: https://www.ietf.org/archive/id/draft-dekok-emu-eap-arpa-01.html#section-4-3 TBD: The Wireless Broadband Alliance (WBA) has defined an unauthenticated EAP-TLS method, using a vendor-specific EAP type. Get link. This appears to be part of Hotspot 2.0r2 and wpa_supplicant implements it. For example: https://w1.fi/cgit/hostap/tree/src/eap_common/eap_defs.h#n112 https://w1.fi/cgit/hostap/tree/src/eap_server/eap_server_tls.c#n479 Wikipedia has more info about its history and pointers to the first commits from 10+ years ago: https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol#EAP-TLS I haven't seen any use of "WFA-UNAUTH-TLS", though. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
On Fri, 8 Mar 2024 at 08:38, Peter Yee wrote: > We are particularly interested in hearing from parties who are > willing to review the specification. So, if you've got interest in > seeing the work adopted, please formalize that by responding > to the EMU mailing list with your position. > I have read the draft and support its adoption. I will reply with comments separately and help with reviewing the draft -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt
On Tue, 5 Mar 2024 at 09:56, Alexander Clouter wrote: > Using an entire serialiser to support only a map carrying attributes with > 1->3 *predetermined* keys seems a bit of a cannon to deal with a mosquito > solution as they go. As a hypothetical, would people have a stronger > opinion here if CBOR was swapped for protocol buffers or ASN.1 in the > document? > Ok, I'll bite. I've worked recently with ASN.1 (hello GSM world) and found it much easier to work than I initially though. I found the interoperability of different MAP and TCAP (again GSM) implementations to work well together. In other words, the software I made successfully talked to other software from the beginning. This allowed the work to concentrate on the software functionality instead of serialising bits on the line. I'd say the main point is: use encoding that's appropriate for the task. ASN.1 suits for 2G/3G complex things. Simple TLVs have so far worked well with EAP. I haven't worked with CBOR, but I'd be interested to know if, for example, how careful we need to be with serialiser/deserialiser to avoid problems similar to exponential expansions attacks [1], etc. TLVs are known for people working on Radius/Diameter/EAP. With CBOR it would be useful if the draft were to have information to avoid potential problems, especially if the CBOR input can come from untrusted sources. I'm sure this information is available, and it would help the implementers if they're notified about what to look out for, if needed. [1] https://en.wikipedia.org/wiki/Billion_laughs_attack -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] TEAP: PKCS exchange notes
On Mon, 28 Aug 2023 at 21:20, Eliot Lear wrote: > First, section 3.11.1 states that authentication is needed before > provisioning, but C.11. does not show any authentication. Should the > diagram show phase 1 client certificate authentication or phase 2 tunnelled > authentication? Are both valid types of authentication as required by > section 3.1.1? > > C.11 assumes bi-directional certificate exchange OR POK. Perhaps that > should be stated. > Thanks for this and the other clarifications. It's what I was expecting but I thought I'd check. I'll push a pull request to update the examples C.11. and C.13. (EAP-TLS like exchange) so that the both show client certificate. There's also an extra Intermediate-Result in C.13. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Patch: revert some IMSK derivation changes
On Mon, 28 Aug 2023 at 21:09, Alexander Clouter wrote: > On Mon, 28 Aug 2023, at 15:43, Heikki Vatiainen wrote: > > > >> If an inner method supports export of an Extended Master Session Key > >> (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in > >> [RFC5295]. > > > > Why the SHOULD? If something else is done, how could it work with other > > implementations? > > Not to suggest it as a good idea, but maybe someone wants a policy that > forces MSK only? > Hmm, I read it as the recommended way of how IMSK is derived from EMSK not as 'if you decide to use EMSK, then it must be done like this'. In other words, I thought it left door open for other ways to derive the IMSK. Now it makes sense. > So the EMSK is available and you SHOULD use it, but you administratively > have disabled it so both ends just use the MSK. > > No idea why you 'WOULD' do this though... > My colleague just pointed out that a lazy implementation can simply always ignore EMSK and still be compliant. Would being lazy be a good reason? -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] TEAP: PKCS exchange notes
Here are some notes that I thought could be useful to sharpen how PKCS exchange is documented. Example exchange C.11. PKCS Exchange shows how certificate provisioning is done with TEAP: https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-13.html#name-c11-pkcs-exchange Section 3.11.1 "Certificate Provisioning within the Tunnel" describes the process: https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-13.html#section-3.11.1 First, section 3.11.1 states that authentication is needed before provisioning, but C.11. does not show any authentication. Should the diagram show phase 1 client certificate authentication or phase 2 tunnelled authentication? Are both valid types of authentication as required by section 3.1.1? Second, C.11. shows that provisioning ends with Crypto-Binding TLV exchange. What is the EMSK and/or MSK used to calculate the TLVs? Is this a case where IMSK is an all-zeroes MSK? Should Section 3.11.1 define these? Third, the draft does not say that PKCS exchange is an inner method. It's not an inner authentication method, but according to example C.11. the exchange ends with Crypto-Binding and Intermediate-Result TLV exchange similarly to inner authentication methods. Would it be possible to clarify the type of PKCS exchange (inner method, something else). Because it appears to be an inner method, also add text to section 3.11. where the use of the two TLV types is required. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Patch: revert some IMSK derivation changes
On Mon, 28 Aug 2023 at 13:25, Alexander Clouter wrote: > On Sun, 27 Aug 2023, at 18:16, Heikki Vatiainen wrote: > > > https://github.com/emu-wg/rfc7170bis/pull/27 > > > > Alex, please comment. I've discussed this with a colleague and we think > the > > current draft would break compatibility with the existing > implementations. > > Your change describes what I implemented for FreeRADIUS. > > The previous text was wrong. I agree with your amendment. > > Great catch, the other crucial goal of 7170bis was to clear up all the > crypto greyness Journi flagged through all those errata queries. > The diff tool Michael mentioned earlier is very useful. I noticed the difference when I was going through the changes between RFC 7170 and the current draft. The reason why that wasn't noticed earlier is that our implementation was based on RFC 7170. Because the IMSK calculation from EMSK and MSK was not supposed to be changed (apart from the case where the MSK is not available), the small changes in done in January were overlooked as editorial as opposed to functional. Related to EMSK, https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-13.html#name-intermediate-compound-key-d the 3rd paragraph currently says: If an inner method supports export of an Extended Master Session Key > (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in > [RFC5295]. Why the SHOULD? If something else is done, how could it work with other implementations? -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Patch: revert some IMSK derivation changes
RFC 7170 and the current draft have diverged in how IMSK is calculated. In short: 1. RFC 7170 pass EMSK to TLS-PRF whereas the draft passes both EMSK and MSK to TLS-PRF. 2. While RFC 7170 adjusts only MSK to 32 octet length, the draft adjusts both EMSK and MSK. See section 5.2 "Intermediate Compound Key Derivations" in the diff for the current changes: https://author-tools.ietf.org/diff?doc_1=RFC7170_2=draft-ietf-emu-rfc7170bis-13%2F I've created a pull request with more details about which two commits have lead to this change and my suggested fix. https://github.com/emu-wg/rfc7170bis/pull/27 Alex, please comment. I've discussed this with a colleague and we think the current draft would break compatibility with the existing implementations. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-13.txt
On Fri, 25 Aug 2023 at 22:30, Eliot Lear wrote: > I agree with the sentiment, but I think it would be good for the words > to soak a bit, since the paragraphs are a little involved. There may be > a simpler way to say the same thing. > The diff between RFC 7170 and the current draft may help with the proposed change. I just noticed that 'EAP' was used more in the RFC than in the draft: https://author-tools.ietf.org/diff?doc_1=RFC7170_2=draft-ietf-emu-rfc7170bis%2F If one looks at section 5.2, 'EAP method' is simplified in the draft to just 'method'. Then later in section 5.2 and in section 5.3. there's new text that says 'If no inner EAP authentication method is run then no EMSK or MSK will be generated ...'. Since, for example, vendor specific (authentication?) methods are required to support "calculation of the Crypto-Binding TLV (section 3.6)", it seems it's incorrect to state only EAP can generate EMSK or MSK. I've also just pushed a one-line update to git to update the first paragraph of section 5.3 "Computing the Compound MAC" which currently says this: After each successful inner EAP authentication, EAP EMSK and/or MSKs are > cryptographically combined ... The update simply drops the both instances of 'EAP '. I'd say this is in-line with the text already present in the draft sections 5.2 and 5.3 which talk about how all inner methods need to updated the compound values. I've only updated sections 5.2 and 5.3 to complete the s/EAP// changes that were already partially done in the earlier draft versions. Related to this, a closer look at the draft shows that at least the following terms are used in interchangeable manner: - EAP authentication method - EAP method - authentication method - method - inner method - Phase 2 authentications - authentication - conversation (Sequence C.6. with chained EAPs) In terminology section only 'Inner method' is defined and it seems to me that in many cases 'Inner method' would suffice when some of the term is used. There are of course cases when a specific term, such as 'EAP method', is needed. Heikki > Eliot > > On 25.08.23 21:27, Alan DeKok wrote: > > On Aug 25, 2023, at 10:07 AM, Heikki Vatiainen > wrote: > >> I have one small suggestion. > >> ... > >> I've created a pull request that updates the 'EAP authentication' part > to say 'inner authentication' so that in case there's an inner method > (perhaps provisioning?) that's not EAP but that can provide keying > material, the text won't be too restrictive. > >> > >> https://github.com/emu-wg/rfc7170bis/pull/26 > >I think that's reasonable. Unless there are objections, I'll pull it > in. > > > >Alan DeKok. > > > > _______ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > > -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Sat, 26 Aug 2023 at 21:13, Michael Richardson wrote: > > Heikki Vatiainen wrote: > > Test with Windows 11 and eapol_test - EAP-TLS followed by EAP-MSCHAPv2 > > Are you saying that Windows 11 also has implemented (accessible via > "insider > program" only)? > I think TEAP has been generally available with Windows 10 and 11 for some time now. There are, for example, Youtube videos that show how it's configured. Weren't the observed differences against RFC 7170 one the main reasons why the draft was needed? "insider program" refers to this: https://www.microsoft.com/en-us/windowsinsider/about-windows-insider-program That is, it's a public program. No secret handshakes or such was needed to get access to TEAP functionality. I'd guess it's also the latest implementation of TEAP, not that I've seen information that there are differences between versions. Therefore it's likely the best Windows version to ensure testing is done against the latest version. > Bernard could you confirm? > -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Sun, 20 Aug 2023 at 15:58, Alan DeKok wrote: > On Aug 20, 2023, at 5:15 AM, Alexander Clouter > wrote: > > > > On Fri, 18 Aug 2023, at 01:01, Michael Richardson wrote: > >> I'm not sure it's sane to use EAP-TLS for Inner method myself. > > > > If you mean in the general sense, I can imagine placing the user > credential on a hardware key whilst the machine credential is either a > regular software keychain or even more exotic and tied to the TPM. > > Or both user and machine do EAP-TLS. Only one certificate can be sent > over TLS in Phase 1. The other has to be sent in EAP-TLS in Phase 2. > > But I do agree... TLS inside of TLS just seems bad. > I thought the justification for inner EAP-TLS with different tunnelling EAP methods, such as PEAP, is hiding the end user's identity. With TLS 1.3 this is no longer a problem, but with TLS 1.2 client certificate is not encrypted. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Sun, 20 Aug 2023 at 12:09, Alexander Clouter wrote: > On Thu, 17 Aug 2023, at 23:33, Alan DeKok wrote: > >> If I did run EAP-TLS as an Inner method (whether once or twice), could > I use resumption? > > > > Uh... why didn't anyone mention this before? TEAP is a near-endless > > source of surprises and corner cases. > > In fairness I think you could have the same problem with TTLS, PEAP and > FAST too. > > TTLS I suppose can be read as this should not be allowed in RFC5281 > section 7.5. MS-PEAP is mentions resumption of Phase 1, but inner methods > look to just be handwaved to inner TLV methods so I suppose "anything goes". > > Shame it missed the boat, would have been nice to slip this into RFC9427 > section 4 which currently does not deny it. > When the outer TLS-based EAP is processed by a different EAP server than the inner EAP-TLS, then the why inner EAP-TLS resumption shouldn't be simply a matter of the EAP peer and the inner EAP server? In this case the outer EAP server wouldn't even know if the inner EAP-TLS does resumption or not, when the inner EAP is proxied through to a next hop server. I'm not saying this can't be made simpler by banning inner TLS resumption. I'm just wondering why this is an issue. It could even complicate implementations when an EAP method in some cases is allowed to do TLS resumption and in some other cases it's forbidden. A simpler way to do this is a reminder that EAP servers can turn off resumption in the part of the configuration that processes inner EAP-TLS. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Thu, 17 Aug 2023 at 22:11, Michael Richardson wrote: > > wrote: > > Alan has issued -11 of draft-ietf-emu-rfc7170bis. He > > believes it covers all of the outstanding issues that needed to be > > resolved. We held up the WGLC until we could have our session at > IETF > > 117. With post-117 changes incorporated, now's seems like the time > for > > the WGLC to go forward. Please post your comments to the mailing list > > by August 28th. Even a "good to go" is genuinely helpful input. > > If you have, or plan to implement, the document shepherd would like to > know. > We have implemented server side TEAP and tested it with the following inner methods: Test with Windows 11 and eapol_test - EAP-TLS followed by EAP-MSCHAPv2 - EAP-MSCHAPv2 followed by EAP-TLS - EAP-TLS - EAP-MSCHAPv2 Tested only with eapol_test: - PAP - no inner authentication; the case where TEAP looks like EAP-TLS The implementation should be up-to-date against draft version -13. Tests were done over TLS 1.2 and with the same server configuration for Windows and eapol_test. Windows 11 is insider program version and eapol_test (wpa_supplicant) is directly from git for EAP-FAST-MSCHAPv2 and other updates that were added since the latest wpa_supplicant release 2.10. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-13.txt
On Tue, 22 Aug 2023 at 17:57, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This Internet-Draft is a work item of the EAP Method Update > (EMU) > WG of the IETF. > >Title : Tunnel Extensible Authentication Protocol (TEAP) > Version 1 >Author : Alan DeKok >Filename: draft-ietf-emu-rfc7170bis-13.txt > I have one small suggestion. Section 5.2. Intermediate Compound Key Derivations, paragraph 2 says: When a particular authentication method does not provide key material (such > as with password exchange) then a special "all zero" IMSK is used as > described below. Then in the same section and later in section 5.3, the draft says: If no inner EAP authentication method is run then no EMSK or MSK will be > generated I've created a pull request that updates the 'EAP authentication' part to say 'inner authentication' so that in case there's an inner method (perhaps provisioning?) that's not EAP but that can provide keying material, the text won't be too restrictive. https://github.com/emu-wg/rfc7170bis/pull/26 -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] draft-ietf-emu-rfc7170bis-12: minor findings
The list in section 4.2.1 "General TLV Format" includes: 11 PAC TLV (DEPRECATED) I suggest re-adding the subsection for PAC TLV with a brief note that it's deprecated. This would serve as reminder that TLV number 11 did exist and it would also keep the section numbering unchanged making it easier to compare RFC 7170 and its updated version. This is a purely an editorial idea. Section 7.7. "Security Claims": When the draft source is processed, incorrect renumbering happens. First, see this line https://github.com/emu-wg/rfc7170bis/blob/main/draft-ietf-emu-rfc7170bis.md?plain=1#L3363 Then compare it to the processed HTML version. https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-12.html Updating the draft source file from '2.' to 'Note 2.", and similarly for note 1, likely fixes this. Appendix A.4. and A.5. both say that TLS_RSA_WITH_AES_128_CBC_SHA is a mandatory ciphersuite and then refer to section 3.2. for more information. Section 3.2. has the updated information but A.4. and A.5. still have old RFC 7170 ciphersuite. Example flows C.11., C.12. and C.13. are not named. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] TEAP devolved to EAP-TLS update
draft-ietf-emu-rfc7170bis-08 added the following paragraph to section 7.4.1. "User Identity Protection and Verification": https://author-tools.ietf.org/iddiff?url1=draft-ietf-emu-rfc7170bis-07=draft-ietf-emu-rfc7170bis-08=--html Note that the Phase 2 data could simply be a Result TLV with value Success, > along with a Crypto-Binding TLV and Intermediate-Result TLV. This Phase 2 > data serves as a protected success indication as discussed in [RFC9190] > Section 2.1.1 My suggestion is to remove Intermediate-Result TLV from the above paragraph. First, section 3.5.5 "Protected Termination and Acknowledged Result Indication" currently says: A successful TEAP Phase 2 conversation MUST always end in a successful > Crypto-Binding TLV and Result TLV exchange. A TEAP server may initiate the > Crypto-Binding TLV and Result TLV exchange without initiating any EAP > conversation in TEAP Phase 2. ... The Crypto-Binding TLV and Intermediate-Result TLV MUST be included to > perform cryptographic binding after each successful authentication in a > sequence of one or more inner methods. The first part of the above quote says that Crypto-Binding and Result TLVs are enough if there's no EAP conversation in phase 2. Based on the second part of the quote, because there's no inner method, logic says that Intermediate-Result TLV isn't needed. Finally, testing against eapol_test from wpa_supplicant shows that this works: Result-TLV (success) Cryptobinding-TLV where as this makes eapol_test trigger failure: Intermediate-Result TLV (success) Result-TLV (success) Cryptobinding-TLV To summarise. If the last paragraph of draft-12 section 7.4.1. "User Identity Protection and Verification" is updated, it would make the text more consistent with the other parts of the draft and allow EAP-TLS -like behaviour to work with eapol_test (wpa_supplicant). -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Sat, 19 Aug 2023 at 00:26, Michael Richardson wrote: > Heikki Vatiainen wrote: > > Should it be noted that this provisioning method is only available with > > TLS 1.2 and earlier because the method requires anonymous ciphersuites? > > It confirms to the reader that this is the intended case. > > If we are talking about an RFC8995 (BRSKI) mechanism then: > > a) It requires that the Peer defer validation of the Server's certificate >until later on when another signed artifact is received (RFC8366 voucher). > b) The server still validates the Peers' client (IDevID) certificate. > > We don't need or want anonymous ciphersuites here. I had the impression that Server Unauthenticated provisioning requires anonymous ciphersuites. I now see that this is incorrect. TLS 1.2 RFC has the following text: [near the list of anonymous ciphersuites] https://www.rfc-editor.org/rfc/rfc5246#appendix-A.5 Note that using non-anonymous key exchange without actually verifying the key exchange is essentially equivalent to anonymous key exchange, and the same precautions apply. A closer look at the current draft shows that the first paragraph in "Server Unauthenticated Provisioning Mode" section already includes text that kind of matches what the RFC 5246 quote above says: https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-12.html#section-3.10.3 This includes both cases in which the ciphersuite negotiated does not provide authentication and in which the ciphersuite negotiated provides the authentication but the peer is unable to validate the identity of the server for some reason. RFC 5422 "Dynamic Provisioning Using EAP-FAST" requires an anonymous ciphersuite for Server-Unauthenticated Provisioning Mode. This is the reason I thought the same requirement applies for TEAP's Server Unauthenticated provisioning mode too. https://www.rfc-editor.org/rfc/rfc5422.html#section-2 To summarise how I understand this now: In order to choose Server Unauthenticated Provisioning Mode, all TLS versions can skip server certificate validation. In addition to this option, TLS 1.2 and earlier can also make the mode selection clear by using an anonymous ciphersuite. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Fri, 18 Aug 2023 at 19:57, Alan DeKok wrote:
> On Aug 18, 2023, at 12:47 PM, Heikki Vatiainen
> wrote:
> > Should it be noted that this provisioning method is only available
> > with TLS 1.2 and earlier because the method requires anonymous
> > ciphersuites? It confirms to the reader that this is the intended
> > case.
>
> How about this:
>
> Note that server unauthenticated provisioning can only use anonymous
> cipher suites in TLS 1.2 and earlier. These cipher suites have been
> deprecated in TLS 1.3 ({{RFC8446}} Section C.2). For TLS 1.3, the
> server MUST provide a certificate, and the peer performs server
> unauthenticated provisioning by not validating the certificate chain
> or any of its contents.
>
>
> The last sentence is suggested by the RFC8446 Section C.2
>
Good find, looks good. Small fix, though. It's section C.5, not C.2.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Fri, 18 Aug 2023 at 01:34, Alan DeKok wrote: > > On Aug 17, 2023, at 5:02 PM, Michael Richardson wrote: > > section 3.9.: what is "server unauthenticated provisioning" > > (sounds like TEAP-BRSKI?) > > Yes. Should it be noted that this provisioning method is only available with TLS 1.2 and earlier because the method requires anonymous ciphersuites? It confirms to the reader that this is the intended case. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-10.txt
On Thu, 3 Aug 2023 at 21:34, Alan DeKok wrote: The diff is perhaps more interesting: > https://author-tools.ietf.org/iddiff?url1=draft-ietf-emu-rfc7170bis-09=draft-ietf-emu-rfc7170bis-10=--html > > * clarify terminology on inner / outer TLVs as per Eliot's suggestion > Two minor suggestions: 1. Capitalise 'inner' in the section header 2. End the 'Inner TLVs' definition with '... but no Outer TLVs are used'. Here ' are used' is new text. That makes it symmetric with the previous sentence and doesn't hint that Outer TLVs may sometime be encapsulated within TLS records. > * add paragraphs on resumption and provisioning as per recent discussion > on the list. > I like these changes. They give guidance for handling TLS resumption and possible authorisation changes the renewed credentials or other provisioned information may require. > I believe that this addresses all concerns. > I think so too. One thing I thought is the case where re-provisioning is a larger task which begins with TEAP in-band re-provisioning and then continues with, for example, HTTPS based device update in a special VLAN. That is, RADIUS Access-Accept assigns a separate virtual LAN for doing the HTTPS part. In this case the device needs to reconnect, or needs to be disconnected, once it has finished its re-provisioning over HTTPS. The server must invalidate any possible TLS resumption which would put the device back to the (re)-provisioning VLAN. However, I think this is outside of scope of this draft/RFC and is something that the device/application and server software vendor must take care of. The new text in the draft is enough now. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
On Thu, 3 Aug 2023 at 11:10, Eliot Lear wrote: > I don't think EAP Failure should ever really be contemplated during a > housekeeping operation *unless* an intermediate-success is first > generated, because otherwise we can bet that at least some clients will > take that as a signal that the house keeping operation failed, and they'll > loop retrying. > I would also expect retry and loops when EAP Failure is received. EAP-FAST's recommendation (RFC 5422, section 3.5) of denying access with Server-Unauthenticated Provisioning Mode is taken into account, for example, in wpa_supplicant which has code and comment explaining that EAP Failure is expected and it's not an error. Because this is not recommended in RFC 7170 TEAP, a success-but-failure could be communicated by signalling it within phase2 so that the peer knows that an EAP Failure for outer EAP is expected. That would be more new functionality that delays the finishing of this draft. That's also the reason why I wrote earlier that maybe in a future (not this RFC update) revision. As was noted earlier, a lot can be handled already with server policy and flexible configuration for different peer and provisioning requirements. > My suggestion would be something along the lines of the following: > > Under normal circumstances, house keeping operations should complete and > the EAP connection SHOULD successfully complete. If a change of > authorization is required for some reason, the server SHOULD make use of a > Radius COA, and not involve the peer so as to not impose excess operations > on the peer (or itself). In exceptional circumstances, a Radius-Disconnect > MAY be used as a signal to a client directly after such operations to > disconnect and authenticate with the new updated credentials. > An option for disconnect could be sending a short Session-Timeout + Termination-Action=RADIUS-Request with Access-Accept. This doesn't depend on working reverse RADIUS path and it can be more reliable than handling dynauth request. I know at least one current device that doesn't work correctly if RADIUS server sends it a dynauth message right after the RADIUS server has received Accounting-Request/Start from the device. It seems like the device must get the new session clearly going before it's able to process a dynauth message correctly. In a typical dynauth case this isn't likely a problem, but receiving a dynauth request a couple of milliseconds after sending Accounting-Request/Start didn't work well. In both cases (CoA message or Session-Timeout + reauth) the device will gain network access for a short while. Is this a problem when the device is malicious? Can a belt-and-suspenders method be to return a 'deny all' packet filter with Access-Request until the CoA or disconnect takes action? -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)
On Tue, 1 Aug 2023 at 01:00, Eliot Lear wrote: > IoT devices need a way to authenticate as TEAP is EAP-TLS under nominal > conditions. When a certificate is about to expire, then the expectation is > that either the client will issue a PKCS#10 request *or* the server will > issue a request action TLV with PKCS#10, so that the client knows the > server wants it to renew. > Forking this thread a bit. The above TEAP's EAP-TLS -like functionality relates to the comments I had during the last week's meeting. Now that I've had time to think about them more, I'd like to add some clarifications. Using the above as an example case: When a client renews a certificate, should the server mark the current TLS session as non-resumable? With EAP-TLS, the server never knows immediately, because renewal is not in-band, when a certificate is renewed, therefore this is not an issue for EAP-TLS. Here we know that a renewal is in process and can take immediate action. While it's possible that the certificate renewal is for non-TEAP use, it shouldn't harm if the next authentication is full authentication. In general, here are some implementation related thoughts: First, when housekeeping services are run in phase 2, should the current TLS session be made non-resumable? The draft uses password and PIN change as examples of "housekeeping" and I'd say certificate renewal and peer's use of Trusted-Server-Root TLV are also "housekeeping" functions. Most, if not all, of these housekeeping services update or affect peer's credentials and for this reason, it may be desired to force full authentication the next time the peer authenticates again. More exactly: all currently cached TLS sessions with the peer may need to be considered as non-acceptable for resumption. Second, in many cases there's some type of authorisation that follows successful authentication. For example, VLAN assignment may be returned with RADIUS Access-Accept that carries the EAP-Success. Maybe the draft should give implementation guidance on being careful to ensure that authorisation happens in controlled fashion? To put this differently, EAP-Success doesn't happen in vacuum but grants access to something. If housekeeping gets differently authorised access, then the server must be careful to handle correctly those clients that try something that a well-behaved client does not do. For example, if peer authorisation happens differently when housekeeping is done, the server should be careful to decline TLS resumption or otherwise the client may get a shortcut to the housekeeping network. That is: resumption ok => Crypto-Binding TLS + Intermediate-Result TLV + Result TLV all saying success => access to housekeeping network without housekeeping. Another example: If the client does TLS resumption and then proceeds to housekeeping, the server must be careful to ensure that authentication information cached from the last full authentication is still fresh enough for the housekeeping purposes. Third, EAP-FAST Dynamic Provisioning RFC 5422 suggests denying after Server-Unauthenticated Provisioning Mode. https://datatracker.ietf.org/doc/html/rfc5422#section-3.5 Would this type of functionality useful for some housekeeping cases? I've seen that, for example, wpa_supplicant as EAP-FAST client supports this. If TEAP is used in some cases for housekeeping-only functions, a way to ensure that this doesn't always result with client getting network access too, might be useful. Maybe for a future revision? To summarise: Using an authentication protocol for provisioning appears to create interesting scenarios to consider. I hope the above points are found useful. More are likely found when working on implementing the provisioning parts, which we haven't done yet. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [Ace] [suspect] Re: Iotdir early review of draft-ietf-ace-wg-coap-eap-08
On Thu, 27 Jul 2023 at 23:39, Behcet Sarikaya wrote: > +1 to Heikki. > > I think the use of AAA, in particular EAP for IoT is simply not practical, > thanks to Heikki for making this specific. > It could be theoretically beautiful though :) > That was not my intention :) I wouldn't say that EAP for IoT is impractical, rather than there are many EAP methods and some are likely more suitable for constrained devices, and links, than the others. For example EAP-TLSv1.3 with certificates that encode ECC public keys, and without CA certificates sent over EAP, would provide both EAP peer identity hiding and shorter message than what's traditionally used (TLSv1.2 or earlier with full CA chains). EAP-pwd was also mentioned and while it doesn't provide EAP peer identity hiding, it authenticates with 4 short request-response pairs (1 for EAP Identity and 3 for EAP-pwd itself). -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [suspect] Re: Iotdir early review of draft-ietf-ace-wg-coap-eap-08
On Wed, 19 Jul 2023 at 11:45, Dan Garcia Carrillo wrote: On 5/7/23 15:36, Alan DeKok wrote: > > >Given that the EAP packets can be forced to be no more than 1024 > octets, the only difference between EAP methods is the number of packets > exchanged, and the total amount of data exchanged. Current EAP supplicants > and authenticators limit the total number of exchanges to 50 or 100, > depending on various factors. > > > >Is there a similar limit for CoAP? i.e. will CoAP go fail if there > is 64K of data being exchanged in EAP? > > > We tried not to go there in the document, just to acknowledge that CoAP > fits the requirements for an EAP lower layer. In any case, EAP messages > larger than 1024 could be sent using CoAP Block-wise transfer, that will > seamlessly take care of sending payloads larger than CoAP Minimum MTU. > A couple of additional notes about EAP authentication exchange and its data use. First, if look at EAP-TTLS and PEAP but not EAP-TLS, it may seem that the authentication exchange is very asymmetric in how it uses data. The EAP server sends a long certificate chain and the client sends very little with many of client responses being just simple ACKs that tell the server to continue. EAP-TLS, especially with TLSv1.2 and earlier, uses plenty of data for both directions. EAP servers know how to fragment the data but clients sometimes may attempt to send messages that get fragmented by the lower layer and may get lost in transit (firewalls etc. being a problem). The problem with clients is typically that there may not be a setting or a method that tells the client to use a certain EAP message size. In other words, EAP-TLS, for example, supports fragmentation, but the clients especially may now know how small the fragment needs to be when they send out their client certificate and its associated CA certificate chain. Some EAP methods, such as PEAP and EAP-TTLS allow running EAP-TLS as the inner authentication method, which means you have TLS within TLS and client fragmentation becomes even more complex. Servers typically know how to handle this too. This is not the most common thing to do, but with TLSv1.2 is the method to hide client certificate information when using EAP-TLS. To summarise: with EAP-TLS there is typically large amount of data transferred in both directions. With TLSv1.3 it's possible to omit the CA certificates: https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2 ... a certificate that specifies a trust anchor MAY be omitted from the chain ... This can be a large size saver, but please see the whole paragraph too. The CA certificates (trust anchors) would need to be know be the other TLS endpoint if this is done. This is yet another good reason to use TLSv1.3 even though TLSv1.2 and earlier still remain in wide use with TLS based EAP methods. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] System level forward secrecy for EAP+AAA
On Mon, 10 Apr 2023 at 19:20, Karl Norrman wrote: [K]: I have described only one. I also gave a concrete example, which may > have caused confusion. > I will try to describe it again in clearer terms, but shorter. Point 2 > answers the direct question. > > 1. There is an EAP server S and a pass-through authenticator A. For > simplicity, say they are operated > by a single honest organization, which the client trusts. S and A protect > the traffic sent between > them using IPsec. > > 2. An adversary listens to the IPsec encrypted traffic sent between S and > A. The adversary cannot decrypt > the traffic, but records the encrypted traffic anyway. (This is who and > what I meant by having access to the traffic). > > 3. After a successful EAP authentication between a client and S, S will > send the established MSK to A over > the IPsec tunnel. > > 4. The adversary records the (encrypted) MSK. But at this point the > adversary cannot decrypt the MSK. > > 5. The MSK is used to protect a session. The session terminates. If one > cares about PFS, the MSK > and any data from which it can be derived shall be deleted when the > session terminates. Otherwise, > the MSK would not be forward secret. > > 6. If one cares about PFS, then one would worry that the adversary would > hack into the server S, > obtain the IPsec session keys and decrypt the encrypted MSK from step 4. > Wouldn't the solution here be upgrading the MSK users to be PFS enabled? For example, Security Considerations in draft-ietf-emu-aka-pfs says: This extension is most useful when used in a context where EAP keys are used without further mixing that can provide Forward Secrecy. For instance, when used with IKEv2 [RFC7296], the session keys produced by IKEv2 have this property, so better characteristics of EAP keys is not that useful. As I understand the above, when an EAP method generates an MSK that's used with IKEv2, step 6 above would still reveal the MSK but the MSK is not usable to decrypt traffic that was secured with IKEv2. For Wi-Fi authentication, the handshake between the wireless device and WLAN access point could run the kind of 'further mixing' draft-ietf-emu-aka-pfs mentions? We're now at Wi-Fi 7 and the future versions could incorporate these changes, if they'd be needed for Wi-Fi. I haven't checked if any of the 802.* specifications already define something like this that's already used with wired and wireless LANs. How common are the link layer protocols that use MSK in such a way that forward security is not achieved? -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Working group Last Call for RFC 7170bis
On Sat, 25 Mar 2023 at 10:53, Alexander Clouter
wrote:
> Conjuring up a scenario so it can be picked apart and discussed...
>
> Is it possible to build an implementation of something like EAP-TLS backed
> by an external system (ie. TPM/hardward-offload) and the EMSK material are
> not avaliable?
>
> RFC5247 section 1.2 has this to say about the EMSK: "...and is never
> shared with a third party." I read this to include any userspace code
> implementation (ie. Radiator, FreeRADIUS, hostapd, ...) as a 'third party'
> as section 1.5 there also labels the backend authentication server as a
> third party.
>
> If the other end was an implementation though that does provide the EMSK,
> we would have a legitimate split.
>
That might be the case if there's an API that hides TLS-Exporter output and
only hands out MSK while making EMSK unavailable.
With TLSv1.3 that would be even more intentional because the requested
length affects the exporter output.
To refresh everyones recollection of this, when TLS-Exporter is used, MSK
comes first followed by EMSK. Using EAP-TLSv1.3 RFC as an example:
Type = 0x0D
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
Type, 128)
[cut some other definitions]
MSK = Key_Material(0, 63)
EMSK = Key_Material(64, 127)
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Working group Last Call for RFC 7170bis
On Fri, 24 Mar 2023 at 20:42, Alexander Clouter wrote: > That said, in practice other than doing EAP-TLS (EMSK) followed by > EAP-MSCHAPv2 (also EMSK), I think any incompatibilities probably would have > never been triggered. > Microsoft's [MS-CHAP] - v20210625 that covers EAP-MSCHAPv2 does not define EMSK. If it seems they use with TEAP, it may cause some confusion later on, or not. I don't think we've tried it yet but I just got a comment about EMSK not being present in the MS document. The doc says this: The Master Session Key [RFC3748] is derived from the two keys as follows: MSK = MasterReceiveKey + MasterSendKey + 32 bytes zeroes (padding) But it doesn't follow with EMSK definition. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Working group Last Call for RFC 7170bis
On Fri, 24 Mar 2023 at 20:42, Alexander Clouter wrote: > On Fri, 24 Mar 2023, at 17:51, Heikki Vatiainen wrote: > > "A new contestant has entered the arena..." > Indeed. It's about the time we implement this too. > The implementation was done based on the RFC and the draft but required > tailoring to make it interoperable with wpa_supplicant's eapol_test with > certain configurations, but that wasn't the main concern. > > > If you are using eapol_test prior to a few TEAP patches (reversed EAP-FAST > MSK calculation and ordering of the Cryptobinding processing) then it > should just work out the box. > I think the case in question where the inner methods were two Basic-Password-Auths (e.g., machine and user type). eapol_test was from the latest git source exactly of the reasons you mentioned. > Section 5.2 in the RFC and the draft currently says: > > If an inner method supports export of an Extended Master Session Key > (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in > [RFC5295]. > > The SHOULD above would change to MUST. This paragraph could then be > removed completely: > > However, it is possible that the peer and server sides might not have > the same capability to export EMSK. In order to maintain maximum > flexibility while prevent downgrading attack, the following mechanism is in > place. > > > Is this not though why it all exists, because the other end may not have > access to an EMSK? > RFC 7170 is from 2014. It may have been useful at that time, but is this still the case? Is it reasonable to implement TEAP in 2020s but not having EMSK supported for an inner EAP that has EMSK defined. TEAP can be implemented as the draft currently says. Mandatory EMSK would make it simpler, though. I do not think it can in general just be ripped out. > > In other words, EMSK support would be mandatory and there would not be any > need to track _MSK and _EMSK derivations, as defined by end of section 5.2. > > > None of this is here because we want it, it is there as it looks to be how > Windows implemented things. > We haven't tried with Windows yet. Windows doesn't export EMSK for all methods that could support it? > Ending up with different EMSK values > > If the peer and server have different capability of EMSK calculation, > correctly working implementations will end up with an error 2001 'Tunnel > Compromise Error' (or some other error). This can happen, for example, with > two chained methods that are both EMSK capable. If the server doesn't > export EMSK for the first method but both export EMSK for the second > method, the peer and server end up with different values for the EMSK after > the second round. > > > I do not understand why the EMSK calculations would be different for the > same method? > To clarify what I meant: when two independent derivations if IMCK[j] are tracked, the EMSK based tracking would look different on peer and server. Client runs the derivation loop twice and the server only once. This is how I understood it the report I got a couple of days ago while away from the office. In other words, because the peer and server do not know about each other's EMSK capabilities, they can end up calculating different tracking for EMSK derived compound values. Wouldn't this be the case with non-mandatory EMSK support? > The language in sections 5.2, 5.3 and 5.4 have had some churn, and maybe > some more is needed, especially whilst this is all fresh in your colleagues > mind. > Yes, that's the intention. This is very new still and we're in a good position to clarify the findings. I've cut a lot from your reply and will think about it in more detail. Thanks, Heikki -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Working group Last Call for RFC 7170bis
On Fri, 10 Mar 2023 at 17:58, Joseph Salowey wrote: > > This is the working group last call for draft-ietf-emu-rfc7170bis-05 [1]. Please review the draft and send comments to the list or open issues in GitHub [2]. Further discussion on the open issues will be considered as part of the last call. The last call ends March 24, 2023. The chairs would appreciate earlier reviews so we can plan to resolve issues during our Monday meeting on the 27th. My colleague has been working on a TEAP implementation. Earlier this week we had a discussion about what he found out. Here's my summary of what I learnt from him. I'm still working on to fully understand the issues, but I also wanted to not go past the last call end. The implementation was done based on the RFC and the draft but required tailoring to make it interoperable with wpa_supplicant's eapol_test with certain configurations, but that wasn't the main concern. The main concern was about EMSK. Because EAP-FAST doesn't use EMSK S-IMCK calculation, it's easier and more straight forward with its calculation than TEAP. Can this simplicity brought back to TEAP by making EMSK support mandatory as suggested below? Problem: Not mandating EMSK +++ Can EMSK support be made mandatory? Section 5.2 in the RFC and the draft currently says: If an inner method supports export of an Extended Master Session Key (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in [RFC5295]. The SHOULD above would change to MUST. This paragraph could then be removed completely: However, it is possible that the peer and server sides might not have the same capability to export EMSK. In order to maintain maximum flexibility while prevent downgrading attack, the following mechanism is in place. The loop derived in the same section, section 5.2, (pseudo code after 'The derivation of S-IMCK is as follows:') would then be defined to use EMSK if the method supports it and MSK if EMSK is not supported. The end of section 5.2 that starts with 'In practice, ...' would also be removed together with the the last two paragraphs in section '5.4 EAP Master Session Key Generation'. In other words, EMSK support would be mandatory and there would not be any need to track _MSK and _EMSK derivations, as defined by end of section 5.2. Ending up with different EMSK values If the peer and server have different capability of EMSK calculation, correctly working implementations will end up with an error 2001 'Tunnel Compromise Error' (or some other error). This can happen, for example, with two chained methods that are both EMSK capable. If the server doesn't export EMSK for the first method but both export EMSK for the second method, the peer and server end up with different values for the EMSK after the second round. MSK and EMSK track inter-binding Another thing to note with separate MSK and EMSK chains is that there's no binding between the two trackings (MSK vs EMSK tracking). This may also be a concern? Chaining is no longer full chaining +++ Consider two methods: the first supports EMSK and the second supports only MSK. In this case there's no compounding because the first method gets the _EMSK suffixed results and the second gets the _MSK suffixed results. With longer chains there would be jumps to and from MSK and EMSK depending on what the methods support. Each time the next method has different EMSK capability than the previous method, the compound chaining jumps to the different tracking. There's no compound calculation for the full chain. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Call for EMU agenda items for IETF 116
On Thu, 2 Mar 2023 at 03:34, Meiling Chen wrote: > I noticed that Openssl 3.2 support for RFC7250 is being discussed. > Has it been supported now? > It seems OpenSSL 3.1 is going to be released later this month. Based on the pull request related to the Raw Public Key support issue, it still seems to be target for release 3.2 with plenty of current activity: https://github.com/openssl/openssl/pull/18185 Related to implementations; for me OpenSSL support would be required for an implementation. While this seems to be progressing, a client implementation would be needed for testing since I work on the EAP server side. Is there any news on the client side? For example, would wpa_supplicant be a possible client? The IOT use case might be something where a client could be based on wpa_supplicant. Thanks, Heikki > Best, > Meiling > > > *From:* Alexander Clouter > *Date:* 2023-03-01 14:12 > *To:* EMU WG > *Subject:* Re: [Emu] Call for EMU agenda items for IETF 116 > On Wed, 1 Mar 2023, at 01:44, Meiling Chen wrote: > > I would like to discuss EAP-TLS-IBS this time, Since last adoption > process, we are still waiting for more people to be interested. > > > I thought the hold up was OpenSSL does not support RFC7250 without > patching? > > https://github.com/openssl/openssl/issues/6929 > > This makes building and playing with an implementation difficult. > > Get this solved and I suspect there will be a lot more active interest. > > Just my thoughts. > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-13.txt
On Thu, 16 Feb 2023 at 21:16, Alan DeKok wrote: > > This version addresses all outstanding reviews from the IESG. The second paragraph of section '6.1. Handling of TLS NewSessionTicket Messages' ends with this sentence where the end of sentence is repeated: If the server allows the session to resume without verifying that the user had first been authenticated, the malicious client can then obtain network access without ever being authenticated network access without ever being authenticated. Regarding the newly added text, it's good that it's now clearly said that TLS session resumption by itself is not sufficient for EAP success. Here's how the above text continues: As a result, EAP servers MUST NOT assume that a user has been authenticated simply because a TLS session is being resumed. Heikki > > On Feb 16, 2023, at 2:11 PM, internet-dra...@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the EAP Method Update WG of the IETF. > > > >Title : TLS-based EAP types and TLS 1.3 > >Author : Alan DeKok > > Filename: draft-ietf-emu-tls-eap-types-13.txt > > Pages : 23 > > Date: 2023-02-16 > > > > Abstract: > > EAP-TLS (RFC 5216) has been updated for TLS 1.3 in RFC 9190. Many > > other EAP types also depend on TLS, such as EAP-FAST (RFC 4851), EAP- > > TTLS (RFC 5281), TEAP (RFC 7170), and possibly many vendor specific > > EAP methods. This document updates those methods in order to use the > > new key derivation methods available in TLS 1.3. Additional changes > > necessitated by TLS 1.3 are also discussed. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/ > > > > There is also an htmlized version available at: > > https://datatracker.ietf.org/doc/html/draft-ietf-emu-tls-eap-types-13 > > > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-tls-eap-types-13 > > > > > > Internet-Drafts are also available by rsync at > > rsync.ietf.org::internet-drafts > > > > > > ___ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length
On Fri, 27 Jan 2023 at 13:30, Eliot Lear wrote: >> On 27.01.23 12:17, Heikki Vatiainen wrote: >> >> For example, an OTP system could do this: >> - Start authentication with username + static password; if ok then >> - Server prompts for the next method: Choose 1 for push to mobile app, >> 2 for telephone callback, 3 for emergency use pre-printed code. Leave >> password empty for the default method (not mandatory: can always >> choose one of 1-3). >> - The next server response then depends on what was chosen by the user >> >> The above may need to run as one exchange without any >> Intermediate-Result TLV between static password and OTP dialogue >> because it gets proxied as Radius PAP to "Inner Method server" as >> described in section 2.1 of the draft > Hold the phone on this. That's not how Jouni's code works, and that's not > what we just agreed to on the calls. Jouni's code has something of a filler > intermediate-result and CB, and we just agreed that everything should have > that. Now, I am still not a fan of that decision, but it's what we decided. > Do we need to revisit? Revisit was not intended, my intention was to give some examples of why various uses of Basic-Password-Auth-Resp TLV and how it sometimes carries information other than password. I may have gotten the sequencing incorrectly with my example above. My understanding is that the "housekeeping" functionality, or any other variation of multi-round inner password authentication, means that Basic-Password-Auth-Req <--> Basic-Password-Auth-Resp exchange is done multiple times before a single inner password authentication method is considered completed and an Intermediate-Result TLV and Crypto-Binding TLV are needed. I'll need to check the previous discussion about filler Intermediate-Result and CB. When strictly reading the RFC and draft, it doesn't talk about multi-round inner password authentication, but I guess this is supported? -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length
On Wed, 25 Jan 2023 at 03:14, Alan DeKok wrote: > > Section 4.2.14 (Basic-Password-Auth-Resp TLV) defines the length of the > password "PassLen" as "Length of Password field in octets'. However, there > is no requirement that the length be greater than zero. > > The same issue goes for the UserLen field. Mandating non-zero UserLen would be good. Furthermore, let's consider multi-round inner password authentication, such as example flow C1 with "housekeeping": https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis#name-c1-successful-authenticatio Is there a reason why we couldn't prohibit changing the username after the first Basic-Password-Auth-Resp TLV is sent by the peer? That is, after the first Basic-Password-Auth-Resp TLV, the subsequent TLVs for the same sequence must have the same Username. At minimum I would like the updated RFC to say that: - peers are expected to prompt for a username only once, at the beginning, for each password authentication sequence; and - server should ignore Username after the first Basic-Password-Auth-Resp TLV for a sequence and the server is allowed to reject the sequence if Username changes The server must be careful to, for example, use the Username from the first Basic-Password-Auth-Resp TLV for authentication, authorisation, logging and other functionality. This is to avoid, for example, to prevent a peer to log in as Alice and then using Bob with the last Basic-Password-Auth-Resp TLV. If the server isn't careful, Bob may end up in authentication and other logs and any possible authorisation may be done as Bob. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length
On Wed, 25 Jan 2023 at 10:21, John Mattsson wrote: > > That sounds good. Would be good to have text stating that passwords of length > 255 characters (the current max) shall be allowed. Requiring a minimum length > of 8 or a least 6 characters would be good. Basic-Password-Auth-Resp TLV is used for non-password purposes too. The RFC and draft call these "housekeeping" functions. Because the TLV is used for both password authentication and housekeeping functions, I wouldn't say much about minimum length. 4 digit PINs are still used and various OTP systems may use a dialogue where the password field is used to transport a response that directs how the OTP protocol proceeds. For example, an OTP system could do this: - Start authentication with username + static password; if ok then - Server prompts for the next method: Choose 1 for push to mobile app, 2 for telephone callback, 3 for emergency use pre-printed code. Leave password empty for the default method (not mandatory: can always choose one of 1-3). - The next server response then depends on what was chosen by the user The above may need to run as one exchange without any Intermediate-Result TLV between static password and OTP dialogue because it gets proxied as Radius PAP to "Inner Method server" as described in section 2.1 of the draft. The RADIUS, and Diameter, RFC appears not to say empty passwords are not supported, therefore rejecting zero length Password field in Basic-Password-Auth-Resp TLV may be problematic with interoperability. I wouldn't mind being able to mandate non-zero length passwords, but I'm not sure if this is the right place to do it. Regarding interoperability, the Radius and Diameter RFCs restrict User-Password, and therefore unencrypted password, length to less than 253, the maximum User-Password attribute payload length for Radius [1] and [2]. Should we consider Radius and Diameter interoperability if we give guidance for Basic-Password-Auth-Resp TLV password length? [1] https://www.rfc-editor.org/rfc/rfc2865#section-5.2 [2] https://www.rfc-editor.org/rfc/rfc7155.html#section-4.3.1 -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question about rfc7170bis && PAC
On Tue, 17 Jan 2023 at 16:24, Alan DeKok wrote: > > On Jan 16, 2023, at 8:00 PM, Joseph Salowey wrote: > > [Joe] Speaking as a contributor, I would rather see the text deleted if > > no-one plans on implementing it. This would make the document simpler. > > If no one objects in the next week or so, I'll go do that. > > My suggestion is to delete all text on PAC, and on related attributes. The > IANA registries can remain in place, but the TLVs related to PAC can point to > RFC 7170, and the other TLVs can point to this document. I also support deleting the PAC related parts. That would make it clearer which parts of TEAP remain in active use. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-02.txt
On Mon, 9 Jan 2023 at 09:43, Alexander Clouter
wrote:
Section 4.2.12.5 - PAC-Acknowledgement TLV
>
> Unclear how this should be used, it looks like the peer could be expected
> to send:
>
> PAC TLV[PAC-Acknowledgement]
>
> After reading section 3.8.1 and getting confused, I am wondering now if
> this is actually:
>
> PAC TLV[PAC-Info{carbon copy of server sent TLV}, PAC-Acknowledgement]
>
> This would let the client acknowledge PACs out of order. Though this does
> not help the server side provisioning PACs out of order.
>
Section 3.8.1 has this restriction:
A PAC TLV containing a PAC-Acknowledge attribute MUST be sent by the
peer to acknowledge the receipt of the Tunnel PAC. A PAC TLV
containing a PAC-Acknowledge attribute MUST NOT be used by the peer
to acknowledge the receipt of other types of PACs.
Assuming that only one Tunnel PAC is provisioned by the server, then
out-of-order acks from the peer can't happen.
The problem with this assumption is that I couldn't find a limit for the
number of Tunnel PACs that can be provisioned. I'd say it does not make
sense to provision multiple Tunnel PACs, or does it?
In any case, it seems that PAC-Acknowledge does not cause a problem where
the peer and server have a different understanding of which type PAC was
acknowledged: It's always the Tunnel PAC.
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-02.txt
On Tue, 10 Jan 2023 at 03:52, Alan DeKok wrote: > On Jan 9, 2023, at 2:43 AM, Alexander Clouter > wrote: > > > Appendix C.1 - Successful Authentication > [cut] > > For me there is a little confusion caused by "PAC-Opaque in > SessionTicket extension" which leads to a resumed session...which then > leads to a refreshing of a PAC in a resumed session which conflicts with > section 3.2.3 stating "A peer SHOULD NOT request that a new PAC be > provisioned after the abbreviated handshake, as requesting a new session > ticket based on resumed session is not permitted.". > I noticed the same thing. The sentence Alexander quoted above was added in TEAP draft -05. Section 3.2.3 was not changed otherwise: https://author-tools.ietf.org/iddiff?url1=draft-ietf-emu-eap-tunnel-method-04=draft-ietf-emu-eap-tunnel-method-05=--html The other changes between versions seem not to explain why the above sentence was added. My take is that the sentence was added to further enforce this requirement: Section 3.8.1 'PAC Provisioning' reads: The peer MUST successfully authenticate the EAP server and validate the Crypto-Binding TLV as defined in Section 4.2.13 before issuing the request. The example in Appendix C.1 is correct when considering the section 3.8.1 requirement and would also comply with section 3.2.3 if the text in 3.2.3 is updated to consider the following: 1) A server must not issue a session ticket with NewSessionTicket Handshake Message before the section 3.8.1 requirement is met. In other words, the message flow in Figure 2 of Session ticket RFC is seems to never be applicable with TEAP: https://www.rfc-editor.org/rfc/rfc5077#section-3.1 In this flow NewSessionTicket is sent by the server before it sends ChangeCipherSpec to finish the session ticket based handshake. Note that this does not prohibit the use of NewSessionTicket. https://www.rfc-editor.org/rfc/rfc5077#section-5.8 reminds that a TLS session renegotiation can be used to send a NewSessionTicket message. Because both the server and the client can renegotiate, they both need to be careful and ensure that the section 3.8.1 requirement is met. 2) I'd say it would be easiest not to distribute PAC with RFC 5077 NewSessionTicket message. However, TEAP RFC section 3.2.2. 'TLS Session Resume Using a PAC' appears to require NewSessionTicket support. A quote from 3.2.2: Implementations MUST support the TLS Ticket extension [RFC5077] mechanism for distributing a PAC and may provide additional ways to provision the PAC, such as manual configuration. 3) Turning off TLS renegotiation would ensure that NewSessionTicket is not sent after the initial handshake. On the other hand, the TEAP RFC has a number of uses for renegotiation. 4) Based on the above, my understanding is that a TEAP peer must be very careful about when it accepts a NewSessionTicket and the TEAP server must also be careful that it does not send an unexpected NewTicketSession during an initial handshake or renegotiation handshake. > Now I have been blending to mean the same 'resumed' and 'abbreviated > handshake' which probably means other readers will too. Maybe we should > explicitly state somewhere: > > > > 'resumed session' - no inner authentication methods take place > > 'abbreviated handshake' - shorter TLS handshake > > I'll take a note about that. > Maybe something like this: 'abbreviated handshake' is based on TLS session ticket or TLS session id. That is, when TLS state kept on client or server side is used to start an initial (or renegotiated) TLS handshake. This hansdhake may succeed or fail. 'resumed session' a session that is re-established after a successful 'abbreviated handshake'. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-02.txt
On Tue, 10 Jan 2023 at 19:26, Alan DeKok wrote: > On Jan 9, 2023, at 5:17 PM, Heikki Vatiainen > wrote: > Is it known how widely Unauthenticated mode is used? Can this be left as > it is for this round of TEAP update? > > Implementors please speak up. :) > > I think it can be left as-is for this round of TEAP updates. > Realistically speaking, if the client verifies the server identity, then > the connection is secure. And any security issues with MS-CHAP become less > relevant. > > i.e. MS-CHAP is insecure against offline dictionary attacks, for > attackers who can view the MS-CHAP exchange. > With *Server Un*authenticated mode a passive attacker can't view the exchange, but MITM is possible. EAP-FAST allowed EAP-FAST-MSCHAPv2 with this mode but since then requirements seem to have become stricter. > If we're running MS-CHAP inside of TLS, then only the client and server > can observe the MS-CHAP exchange. > > If the client verifies the server identity (certificate. etc), then this > prevents MITM attacks. > With Server Unauthenticated Provisioning Mode client does not verify a certificate and MITM is possible. With an anonymous ciphersuite a certificate is not required in a Server Hello message. Here's an EAP-FAST example where the client ( eapol_test from hostapd) has no PAC and it's configured with anonymous provisioning allowed. Client Hello is not shown, but it only contains two ciphersuites: TLS_DH_anon_WITH_AES_128_CBC_SHA and 0x00ff (RFC 5746 TLS Renegotiation Extension). EAP-FAST server then sends this as response to finish its part of TLS handshake. No certificate is present in Server Hello. Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 89 Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 85 Version: TLS 1.2 (0x0303) Random: 04e834170801843585c851e4fc9a385b9e685e15117e5559820535d1ce9ab0c1 Session ID Length: 32 Session ID: 04e71ab3f6a879a94c0506158fa45b34f2d91b0fa14a79b59a8c074be8d94f89 Cipher Suite: TLS_DH_anon_WITH_AES_128_CBC_SHA (0x0034) Compression Method: null (0) Extensions Length: 13 Extension: renegotiation_info (len=1) Extension: encrypt_then_mac (len=0) Extension: extended_master_secret (len=0) [JA3S Fullstring: 771,52,65281-22-23] [JA3S: ecbb9d4a0a2c120e04934d821ba6cb58] TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 523 Handshake Protocol: Server Key Exchange Handshake Type: Server Key Exchange (12) Length: 519 Diffie-Hellman Server Params TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 4 Handshake Protocol: Server Hello Done Handshake Type: Server Hello Done (14) Length: 0 EAP-FAST dynamic provisioning RFC discusses Server-Unauthenticated Provisioning Mode in detail: https://datatracker.ietf.org/doc/html/rfc5422#section-6.1.2 TEAP RFC has much less text about Server Unauthenticated mode. I'd say this gives even more reason to be clear about why EAP-FAST-MSCHAPv2 is no longer allowed by TEAP with this mode. The server presumably already knows the password, so it gains no > information by observing the MS-CHAP exchange. > > Any client which knows the password gains no information by observing > the MS-CHAP exchange. > > Attackers can only try MS-CHAP with random guess, and get rejected. > They can't do anything other than online guesses. > > Does that sound correct? > For server authenticated operation yes, but with sessions that use anonymous ciphersuite there's the MITM problem. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-02.txt
On Mon, 9 Jan 2023 at 09:43, Alexander Clouter wrote: Section 3.8.3 - Server Unauthenticated Provisioning Mode > > "Phase 2 EAP methods used in Server Unauthenticated Provisioning Mode MUST > provide mutual authentication, provide key generation, and be resistant to > dictionary attack. Example inner methods include EAP-pwd and EAP-EKE." > > As EAP-FAST-MSCHAPv2 is not resistant to dictionary attack[2] we need to > tell people this. > I agree. I also noticed this significant change compared to EAP-FAST. It's not mentioned in RFC 7170 Appendix B that lists the major changes compared to EAP-FAST: https://www.rfc-editor.org/rfc/rfc7170#appendix-B I'd say this is a major change because EAP-FAST-MSCHAPV2 can be directly integrated with Windows AD but EAP-pwd and EAP-EKE can not. This is not to bring back EAP-FAST-MSCHAPv2 but simply a note that Server Unauthenticated Provisioning Mode is not as easy to use than in EAP-FAST. In practice, as anyone seen anything other than EAP-FAST-MSCHAPv2 actually > be used for this? Win10/11 does not; and EAP-AKA/EAP-SIM is not exactly > available to non-telcos, right? The other methods supported you would have > the server (inner) identity available (ie. EAP-TLS) which opens the > question why you would not also know the outer server identity. > Can't comment on what's used with TEAP but this is likely a surprise to those who think they can quicly port EAP-FAST's Server Unauthenticated Provisioning Mode to TEAP. > No idea what to do here. > Is it known how widely Unauthenticated mode is used? Can this be left as it is for this round of TEAP update? -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Resolution for TEAP Errata 5128
On Mon, 9 Jan 2023 at 10:57, Alexander Clouter wrote: Problem is this section has the instruction "generate 64 bytes, use the > first 32..." and after personally getting tripped up[1] on the different > though used with TLS-Exporter which for TLSv1.3 now generates wildly > different outputs depending on the length you request. > > So do we think implementers treat the PRF function as a '(stable) stream > output function' or a 'hashing function'? It works as the former but when > you use it it feels like the latter. > My suggestion: see how the PRF is defined and use it accordingly. For example, with TLSv1.2 default PRF one needs to call P_hash as many times as needed to get at least the number of octets that are required before truncation. Then truncate if needed. As seen below (IMSK definition for TEAP), the length of defined output affects P_hash output therefore it's important to know how much output is needed and what the possible truncation is. Truncation must define clearly what is removed and what is left. For example 'First 32 octets' tells what is used after truncation. I think the TLSv1.2 PRF definition provides the definition and example that is clear enough: https://www.rfc-editor.org/rfc/rfc5246#section-5 > So two options: > > 1. I do like the amendment to use the language "First N octets of > TLS-PRF(..." but it would be helpful to include with it a statement along > the lines that PRF/P_ outputs a stable infinite *stream* of > pseudorandom wonder. > > 2. We update the PRF/P_ function definition updated to include > 'length' (as actual implementations *do* take in a length to know how much > stuff to generate) just so we push it under the noses of implementers and > ready them for the excitement and pitfalls of TLSv1.3. > I'd say it would be enough to tell that successful using PRF requires taking a look at the definition. Such as Section 5 in the TLSv1.2 RFC. With TLS exporter things are easier because length is one of the inputs. > So whilst I prefer the amendment language, I think for communication and > clarity reasons adding 'length' to the PRF/P_ is the better options > as it makes it literally closer to how those functions are in practice > implemented and called; plus TLS-Exporter is now sensitive to length to we > gain some kind of symmetry there too. > > On a related note, whilst we are here, it does raise the question on how > we got: > > "...the length is 64 octets..." and "First 32 octets of TLS-PRF(...)" > > The '0x00 || 0x40' (64 network order 16bit length concatenation) looks > superfluous and I cannot see what they add here (as the label is not > recycled elsewhere) and makes me wonder if it was unintended? > See https://www.rfc-editor.org/rfc/rfc5295#section-3.1 Because IMSK is derived from EMSK I think it has to be defined as currently shown in draft 7170bis-02. One of RFC 5295 requirements is that the derived key, in this case IMSK, has to be at least 64 octets. Maybe this clarifies section 5.2 in the draft (be specific that 64 octets are needed by using [0..63] notation): IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org", 0x00 || 0x00 || 0x40) [0..63] This means that two iterations of TLSv1.2 P_hash(secret, seed) are needed with. o secret=EMSK; and o seed = "teapbind...@ietf.org", 0x00 || 0x00 || 0x40 One iteration would give enough data, but RFC 5295 requires to pull 64 octets. I haven't implemented TEAP yet, but the above is how I'd do to get IMSK. Part of my reasoning is later in the same section we see TLS-PRF(...) with > what is obviously a length field: > > IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" || IMSK[j], > 60) > S-IMCK[j] = first 40 octets of IMCK[j] > CMK[j] = last 20 octets of IMCK[j] > > This makes me believe that originally we were meant to see: > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" || 0x00, > 64) > > This aligns nicely with the 'label | seed' definition seen earlier for > PRF/P_ too. > Not to sure why the '0x00' is still needed, but maybe it was to stop > people messing up the seed with a NULL/empty value rather than a single NUL > byte or vice versa; this way it is explicitly described/read-as "seed is > 0x00" and clear to the implementer. > > Anyway, pondering on history here is mostly irrelevant as Windows, Cisco > ISE, hostapd and now FreeRADIUS all have implemented '... || 0x00 || 0x00 > || 0x40'. > As mentioned above, I think this comes from RFC 5295. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-ietf-emu-aka-pfs and IMSI privacy for Wi-Fi
On Sat, 17 Dec 2022 at 16:43, John Mattsson wrote: > It is always great with more privacy, but the IMSI Privacy Protection for > Wi-Fi seems a bit weird to me. Do anybody know the background and reason > behind the standard? 3GPP standardized a mechanism to encrypt IMSIs already > in 2018. I have a hard time seeing what the WBA standard adds that is not > available in the 3GPP mechanism. > This might be related to timing. When we were asked about implementing IMSI privacy done this way on the Radius server side, it was already known that some Wi-Fi clients were implementing it. In other words, maybe this had started before the 5G privacy protection method was published. Thanks, Heikki -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for RFC 7170bis
I would like to see this draft adopted. I need to work on implementing TEAP. For this I'd like to have a draft that I could use, and while doing the work, help by providing comments. Thanks, Heikki On Fri, 16 Dec 2022 at 00:29, Peter Yee wrote: > This is an adoption call for RFC 7170bis > (draft-dekok-emu-rfc7170bis-00)[1]. > I'd call this mostly a formality since it's pretty clear the WG is > interested in updating TEAP and TEAP was already adopted by the WG (back in > May 2011). With Alan having generated a new working version to host the > update and even preparing a Git repository[2] to that end, I believe we're > in a good place to revise RFC 7170. That said, if anyone has an objection > to > starting off from Alan's kind offering, please let us know by December 22, > 2022. > > Joe and Peter > > 1) https://datatracker.ietf.org/doc/draft-dekok-emu-rfc7170bis/ > 2) https://github.com/alandekok/rfc7170-bis.git > > > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] draft-ietf-emu-aka-pfs and IMSI privacy for Wi-Fi
In the last week's EMU meeting I had a question about draft-ietf-emu-aka-pfs with relation to IMSI privacy protection defined for Wi-Fi networks. As promised, here's more information about the Wi-Fi privacy specification. The Wi-Fi privacy specification is by the Wireless Broadband Alliance (WBA) and it's called 'IMSI Privacy Protection for Wi-Fi'. It's available from here: https://wballiance.com/imsi-privacy-protection-for-wi-fi/ I'm not familiar with draft-ietf-emu-aka-pfs, the first time I thought about these two documents was during the meeting, but I've looked into the WBA specification. What it does is that it tells how to encrypt the permanent identity hiding the IMSI from eavesdropper. Thanks, Heikki -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Fixes and suggestions for draft-ietf-emu-tls-eap-types-09
Please find below some fixes and suggestions
for draft-ietf-emu-tls-eap-types-09
Apart from the first item (TEAP label), which could also be considered a
typo, I think these are clarifications, not functional changes.
Labels used with TEAP
Section 2.2 says:
session_key_seed = TLS-Exporter("EXPORTER: session key seed", Type, 40)
This is missing 'teap ' and should be:
session_key_seed = TLS-Exporter("EXPORTER: teap session key seed", Type,
40)
TLS Finished
Search for 'finished' shows that TLS Finished message is written, and
sometimes used, in different ways. My suggestion is to replace the
variations with: Finished message
'Finished message' is what the TLSv1.3 RFC mostly uses too. This draft
already uses, for example, 'NewSessionTicket message' therefore 'Finished
message' would be a good match.
Other Finished message / CONNECTED state notes
--
The first paragraph in section "3. Application Data" currently says:
Some implementations use a "TLS finished" determination as an indication
...
This might be better written as:
Some implementations use receipt of Finished message as an indication ...
or
Some implementations use transition to "CONNECTED" state as an
indication ...
The second paragraph in section 3. says:
... a transition to "TLS finished" also meant that there was no
application data available ...
Because there's no such TLS state, a fix could be:
... a receipt of Finished message also meant that there was no
application data available ...
or
... a transition to "CONNECTED" state also meant that there was no
application data available ...
The first sentence in the second paragraph of section 3. says '"TLS
finished" method' which is one case where simple 'Finished message' would
work.
Indication vs indicator
++
EAP-TLSv1.3 RFC 9190 does not use 'indicator', it only uses 'indication'.
This draft uses the both, mostly indicator, but it might be clearer to use
'indication' to match RFC 9190.
Spelling of CHAP variations
+++
Suggestion: Search for 'CHAP' and ensure that only 'CHAP', 'MS-CHAP-V1' and
'MS-CHAP-V2' are used for the non-EAP variations.
Section 6.1., inner tunnel replacements
+++
Paragraph starting with 'It is RECOMMENDED ...' does not suggest using
MS-CHAP-V2 or EAP-MSCHAPv2 as a replacements for MS-CHAP-V1. Adding this
would match the previous paragraph.
Other minor suggestions and fixes
+
EAP-Response/Identity could be used as the common notation for the two uses
in section 3.1.
Section 6.1 has '... do not provided ...'. Remove 'ed'.
Section 7 has a typo: tje
--
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WG last call for draft-ietf-emu-tls-eap-types ?
On Sat, 10 Sept 2022 at 11:02, Alexander Clouter wrote: > Section 5 - Implementation Status > - > Again, only if it helps someone come off the fence, I can sprinkle these > proposed changes for TEAP and EAP-FAST into hostapd[3] and FreeRADIUS? > > Radiator also implements EAP-FAST so maybe we can get them onboard here > too for that. > I can take a look at EAP-FAST server side implementation with updates to Radiator. Patches pointed by [3] above are for TEAP, but if there's something that needs to be changed in hostapd for EAP-FAST, please let me know. A quick look shows that it may need something that's not available in its git repository yet. Are there any other clients that could be used for testing? Thanks, Heikki -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] draft-ietf-emu-tls-eap-types-06 comments
with other EAP methods too. 3.1 Identities ++ Paragraph 5 'Implementation MUST NOT ...' has lower case 'eap'. Change to 'EAP'. Paragraph 7 'In general, routing identifiers' has repeated a 'with with'. Change to 'with'. 4. Resumption +++ The paragraph in the draft could benefit from a small sentence reordering and rewording. The original is followed by the suggested version: Note that if resumption is performed, then the EAP server MUST send the protected success result indicator (one octet of 0x00) inside the TLS tunnel as per [RFC9190]. If either peer or server instead initiates an inner tunnel method, then that method MUST be followed, and resumption MUST NOT be used. The EAP peer MUST in turn check for the existence the protected success result indicator (one octet of 0x00), and cause authentication to fail if that octet is not received. Note that if resumption is performed, then the EAP server MUST send the protected success result indicator (one octet of 0x00) inside the TLS tunnel as per [RFC9190]. The EAP peer MUST in turn check for the existence the protected success result indicator (one octet of 0x00), and cause authentication to fail if that octet is not received. If either peer or server instead initiates an inner tunnel method, then that method MUST be followed, and inner authentication MUST NOT be skipped. The rewording changes 'resumption MUST NOT be used' to what's shown above. My understanding is that if TLS resumption is done, then the choice is either to: - use protected success result indication 0x00; or - do full inner authentication; but not both 6. Security Considerations The last sentence of paragraph 3 is shown below with the suggested change following: However, the TLS protocol may send one or more NewSessionTicket after receiving the TLS Finished message from the client, and therefore before the user is authenticated. However, the TLS protocol may send one or more NewSessionTicket messages after receiving the TLS Finished message from the EAP peer, and therefore before the user is authenticated. The changes add 'messages' and change 'client' to 'EAP peer'. The next paragraph ends with these two sentences. The suggested sentences follow: Malicious clients can begin a session and receive a NewSessionTicket. The malicious client can then abort the authentication session, and the obtained NewSessionTicket to "resume" the previous session. Malicious EAP peers can begin a session and receive a NewSessionTicket. The malicious EAP peer can then abort the authentication session, and use the obtained NewSessionTicket to "resume" the previous session. The changes use 'EAP peer' instead of 'clients' and add missing verb 'use'. 6.1 Protected Success and Failure indicators ++ Paragraph 5 says '... TTLS with inner PAP or CHAP.'. I'd change the inner protocols to 'PAP, CHAP or MS-CHAP'. Paragraph 7 says '... do not provided protected ...'. Change 'provided' to 'provide'. Paragraph 7 also suggests replacements for PAP and CHAP to ensure protected indicators can be used. A replacement for MS-CHAP could be EAP-MSCHAP-V2 or possibly EAP-MD5? 8. References +++ [PEAP-MPPE], [PEAP-PRF] and [PEAP-TK] point to different parts of [MSPEAP]. It might be useful to clarify that this is the case in order to minimise the problem with broken links. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3
On Mon, 7 Mar 2022 at 17:45, Hannes Tschofenig wrote: > Maybe it is a terminology issue but TLS at least requires > server-authentication. > Terminology issue, I think. By "only client certificate" I'm thinking of what a client needs to do to authenticate. The use of server-authentication with server certificate remains as it is. EAP-TTLS RFC discusses the possibility of client-authentication with certificate being sufficient for completing the whole authentication dialog without tunnelled (AKA phase2) authentication. As far as I know, this hasn't been used, not at least recently, and now when TLS 1.3 forces changes to implementations it would also provide a good chance to let go of features that are not needed any longer. Thanks, Heikki -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3
On Fri, 4 Mar 2022 at 21:44, Alan DeKok wrote: > I would argue that EAP-TTLS with only a client certificate doesn't make > sense. I'm not sure why it's in RFC 5281. If you want to only use a > client certificate, you should just use EAP-TLS. > > I suggest for this document that we just forbid the case of using only a > client certificate with TTLS. > No objection from me - and it now appears to be in draft version -05. While there may have been client software that supported this, I have not seen any recent clients that support this. The only reason I mentioned this RFC 5281 feature is that it's mentioned in the RFC, not that I have seen it used. I noticed there's also a similar new paragraph in draft -05 for PEAP. This is a good and symmetrical clarification which I see being compatible with [MS-PEAP]. The document Microsoft maintains says very little about client certificates, basically just allowing them to be requested by the server. I don't see anything that changes the use of inner tunnel authentication by the use of them and now the draft confirms this. Thanks, Heikki -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3
On Fri, 18 Feb 2022 at 19:18, Joseph Salowey wrote: This is a working group last call for TLS-based EAP types and TLS 1.3. The > document is available here: > https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/ > > Please review the document and provide comments by March 4, 2022 > Would it be useful to clarify the use of protected success indication, TLS application data 0x00, with resumption. I'm mainly thinking of EAP-TTLS which can end resumption very quickly. For example, this EAP-TTLS resumption sequence diagram shows how resumption typically happens: https://datatracker.ietf.org/doc/html/rfc5281#section-15.3 This EAP-TTLS RFC also mentions that this could happen with client certificate authentication too: https://datatracker.ietf.org/doc/html/rfc5281#section-7.6 The 3rd paragraph in Section 2 in the draft mentions 0x00 octet once and then refers to Section 3. It also could refer to Section 4 where new text could say something like this: If the EAP peer nor EAP server does not initiate an "inner tunnel" method, the EAP server must send 0x00 inside the TLS tunnel. Section 4 in the draft already states that RFC 9190 (EAP-TLS 1.3) defines how resumption is done. Strengthening this by mentioning 0x00 octet would make it clear to the implementation developers that they always have to expect and require at minimum 0x00 octet over a TLSv1.3 tunnel when an EAP-based TLS method is about to skip tunnelled authentication. As an example, wpa_supplicant recognises this and logs 'EAP-TTLS: ACKing EAP-TLS Commitment Message' during EAP-TTLS resumption. Thanks, Heikki -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP-TLS 1.3 Section 2.2 text
On Tue, 25 May 2021 at 07:45, Joseph Salowey wrote: > I made some changes to the pull request to address some of the comments > and make the text clearer: > One note about the TOFU mechanism: What we've seen is that certificate renewal also triggers server certificate re-trust query/prompt/other action. That is, even if the issuing CA, public key and subject/SAN names remain the same, the certificate is deemed as changed by the EAP peer. In other words, if only validity dates have changed in the certified information, users a prompted again. Should TOFU defined more closely in a future document, it could be beneficial to give guidance which changes are accepted without validation. One option is to not allow any changes, but allowing some renewals to be accepted transparently could be useful. This is espcially seen with public root CAs where certificate validity periods are getting shorter. I'm not suggesting changes to the text below. The above is just a consideration for any possible future documents that relate to TOFU. >The process of configuring a root CA certificate and a server name is >non-trivial and therefore automated methods of provisioning are >RECOMMENDED. For example, the eduroam federation [RFC7593] provides >a Configuration Assistant Tool (CAT) to automate the configuration >process. In the absence of a trusted root CA certificate (user >configured or system-wide), EAP peers MAY implement a trust on first >use (TOFU) mechanism where the peer trusts and stores the server >certificate during the first connection attempt. The EAP peer >ensures that the server presents the same stored certificate on >subsequent interactions. Use of a TOFU mechanism does not allow for >the server certificate to change without out-of-band validation of >the certificate and is therefore not suitable for many deployments >including ones where multiple EAP servers are deployed for high >availability. > > -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] EAP-TLS key derivation and interoperability based on draft 13
I'd like to express my support for draft version 13 key derivation. I just recently joined the list so I'm unable to respond directly to Joe's message on May 9th. My main concern from the viewpoint of RADIUS / EAP server maintainer is the potential bifurcation of implementations and the upcoming RFC. Our server implementation interoperates with draft version 13 clients, and because it now seems that Microsoft will ship based a client on draft 13, this will in effect fixate our server to support draft 13. Some list members may remember a bit similar case happening with PEAP. PEAPv1 drafts used 'client PEAP encryption' label with key derivation. However, a number of clients continued to use 'client EAP encryption'. When this happened, the only option on the server side that was available was to have a configuration flag that forced PEAPv1 label to either or. Debugging this was really hard because even if the authentication completed successfully, for example in case of Wi-Fi, the client and WLAN AP encryption keys did not match. All logs looked fine but the radio layer encryption did not work causing eventual timeouts and debugging nightmare. Luckily PEAPv1 usage did not become very wide spread. Based on the above, I think it's extremely important to make sure the implementations and the specifications match. The label problem seen with PEAPv1 would be the same with EAP-TLS/TLSv1.3 too if we let it happen. Fortunately it seems that there are no major reasons to proceed with draft version 13 key derivation. I'm also happy to support TLS application data 0x00 for messaging. I noticed there was recent discussion about this with relation to other options. Radiator first implemented EAP-TLS in 2002 (19 years ago) and is where RadSec (RFC 6614 - TLS Encryption for RADIUS) first originated from. We currently interoperate with a number of clients, Android, Apple, Microsoft and others. Being a server software vendor, we have also been fortunate to gather experience working with different client and server implementations. Radiator is used by individual organisations, roaming federations, such as eduroam, for proxying, authentication and other tasks. I won't go further but I thought it might be useful to say a little about where we are coming from. I'll take a further look at the current draft and past discussion next but I thought I'd start by replying to Joe's call before the May 20th deadline. -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
