Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
Based on helpful WGLC feedback on draft-ietf-emu-rfc7170bis, we are now at version -14. I'm not aware of any outstanding issues (minor errata stuff aside) and there do not appear to be any objections, sustained or otherwise at the present time. On that basis, your EMU WG chairs are declaring WG consensus in support of draft-ietf-emu-rfc7170bis-14. Thank you to everyone who took the time to read through the draft and comment during WGLC. I genuinely believe the process has improved the document. Joe and I look forward to its passage through IETF LC and onto publication. Joe and Peter From: pe...@akayla.com Sent: Monday, August 14, 2023 2:23 PM To: 'emu@ietf.org' Subject: WGLC on draft-ietf-emu-rfc7170bis-11 Folks, 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. Thanks. Joe and Peter ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Sun, 27 Aug 2023, at 10:57, Heikki Vatiainen wrote: > Weren't the observed differences against RFC 7170 one the main > reasons why the draft was needed? Exactly. In particular it was the use of the EAP-FAST-MSCHAPv2 key derivative (reversed upper/lower bits) that triggered this and the fun around Identity-Type-TLV and all those empty identities when Windows gets grumpy, ... > "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. We even got a CVE/bounty for the TEAP work... https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21539 Triggered by bundling the inner EAP Identity request from the server with the outer TLS session establishment frame to save a round trip. hostap looked to include a workaround for this (eap_teap_method_sequence) independently before it went public, guess he noticed Windows exploding too... Should be all fine now with the optimisation... Cheers ___ 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 Aug 26, 2023, at 3:18 PM, Michael Richardson wrote: > since some things have been clarified, are we sure then that it's on the side > of the new text? > (I'm asking as shepherd to record Implementation Status) I won't speak for Microsoft as such. But all of the implementations do the same things, and they all behave as suggested in 7170bis. The differences between the doc and implementations are: * nothing implements Identity-Hint That can be fixed on the server side during IETF last call * nothing implements the PKCS TLVs I believe any other differences are minor. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
Alan DeKok wrote: > On Aug 26, 2023, at 2:13 PM, Michael Richardson > wrote: >> Are you saying that Windows 11 also has implemented (accessible via >> "insider program" only)? > I believe that TEAP is generally available in Windows 11. since some things have been clarified, are we sure then that it's on the side of the new text? (I'm asking as shepherd to record Implementation Status) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Aug 26, 2023, at 2:13 PM, Michael Richardson wrote: > Are you saying that Windows 11 also has implemented (accessible via "insider > program" only)? I believe that TEAP is generally available in Windows 11. https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensible-authentication-protocol/network-access?tabs=eap-tls%2Cserveruserprompt-eap-tls%2Ceap-sim That page indicates everything after Windows 10 build 19041 supports it. To the best of my knowledge, only the early EAP-TLS 1.3 tests were done via the "insider program". But that work is now also generally available. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
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)? Bernard could you confirm? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Aug 25, 2023, at 2:10 PM, Heikki Vatiainen wrote: > 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 would say that's fine, and put it under the label of "handing off the inner method to someone else". If the EAP server hands off the inner method to another system, then the other system does whatever it wants. My concern is "inventive" interpretations of the specs. I can't think of a reasonable use-case where the same server would disallow outer TLS resumption, but use inner TLS resumption. So instead of making the world more complicated, we can just ban unreasonable things. > 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. If resumption is enabled for the outer TLS session, then the inner methods are bypassed completely. But it's likely worth noting that the if outer resumption is allowed, the inner methods should have resumption disabled. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Fri, 25 Aug 2023, at 19:10, Heikki Vatiainen wrote: > 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. For me, not a technical point, just I perceive it as undermining for me the purpose of resumption. "obliteration of every round trip possible" Of course I may be in the minority here :) Allowing inner methods to resume forces you to always resolve the inner methods; in lieu of some OOB method to communicate otherwise. I like to try to line up my ducks so I can use resumption for authorization, not just authentication. Yes, I know, dragons lurk there, but I'm cleverer than those dragons...definitelyI'm confident in itreallyI am! Maybe my cavalier tendencies should be ignored though. > 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. I think things actually become *less* complicated when you allow inner resumption as now the outer resumption is guaranteed to be decoupled from any policies around authorization. The cost of implementing any form of outer resumption is in the caveats around bubbling up invalidations (eg. password changed, account disabled, ...) and using account expiry as an upper limit for the validity of the resumption keying material. Here lie all the pains of maintaining a cache. The caching part is easy, everyone gets bitten by the invalidation plumbing, even when they know where the bodies are buried. Cheers ___ 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] 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
>> >> https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-12.html#section-3.5.4 >> >> Implementations MUST NOT permit resumption for the inner EAP methods >> such as EAP-TLS. If the user or machine needs to be authenticated, >> it should use a full authentication method. If the user or machine >> needs to do resumption, it can perform a full authentication once, >> and then rely on the outer TLS session for resumption. >> >>• Are we talking about TLS-based inner methods resumptions only? > For now, yes. >> That is not the only case. We can ‘save’ the result of MS-CHAP >> authentication for example and then skip the full authentication next time. I'm not clear how. The peer creates a challenge which is unique to each authentication session. Since that can't be cached, I don't see how any "resumption" here can skip the full authentication. >> Although the term ‘resumption’ might not be 100% correct here I’d like to >> understand what we are talking about in the RFC. >>• I think the paragraph is slightly contradictory. The first sentence >> says ‘MUST NOT’ and the last sentence concludes with . > The paragraph tries to say: >* inner resumption is disallowed >* just use resumption in the outer TLS tunnel I have read again resumption section. What I was trying to achieve and asking for is already mentioned in Section 3.4: If the server agrees to resume the session, Phase 2 is bypassed entirely. That is actually it. Sorry for the confusion. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Aug 20, 2023, at 11:01 AM, Vadim Cargatser (vcargats) wrote: > > https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-12.html#section-3.5.4 > > Implementations MUST NOT permit resumption for the inner EAP methods > such as EAP-TLS. If the user or machine needs to be authenticated, > it should use a full authentication method. If the user or machine > needs to do resumption, it can perform a full authentication once, > and then rely on the outer TLS session for resumption. > > • Are we talking about TLS-based inner methods resumptions only? For now, yes. > That is not the only case. We can ‘save’ the result of MS-CHAP authentication > for example and then skip the full authentication next time. I'm not clear how. The peer creates a challenge which is unique to each authentication session. Since that can't be cached, I don't see how any "resumption" here can skip the full authentication. > Although the term ‘resumption’ might not be 100% correct here I’d like to > understand what we are talking about in the RFC. > • I think the paragraph is slightly contradictory. The first sentence > says ‘MUST NOT’ and the last sentence concludes with . The paragraph tries to say: * inner resumption is disallowed * just use resumption in the outer TLS tunnel > To the best of my knowledge inner method resumption is really desirable and > widely used. Especially if are discussing all inner methods, not just > TLS-based only. Where is inner resumption widely used? I don't recall seeing it. If I had seen it, I would probably have raised this issue earlier, and put text into RFC 9427 to forbid it. > The idea of allowing resumption through the outer TEAP tunnel is also great. > It is simple. > > The obvious caveat here is that will not be achievable in TLS 1.2 (if tickets > are used) since we cannot easily bind the ticket and the result of the inner > authentication. But we could sacrifice that for the over whole simplicity… > Moreover, I guess it is reasonable to assume most TEAP implementations will > have TLS 1.3 in the stack anyway. We don't need to bind the ticket to the result of the inner authentication. The server simply refuses to allow tickets to be used until the inner authentication has completed. This issue has been known for a while. RFC9190 has text on it, for example. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-12.html#section-3.5.4 Implementations MUST NOT permit resumption for the inner EAP methods such as EAP-TLS. If the user or machine needs to be authenticated, it should use a full authentication method. If the user or machine needs to do resumption, it can perform a full authentication once, and then rely on the outer TLS session for resumption. 1. Are we talking about TLS-based inner methods resumptions only? That is not the only case. We can ‘save’ the result of MS-CHAP authentication for example and then skip the full authentication next time. Although the term ‘resumption’ might not be 100% correct here I’d like to understand what we are talking about in the RFC. 2. I think the paragraph is slightly contradictory. The first sentence says ‘MUST NOT’ and the last sentence concludes with . To the best of my knowledge inner method resumption is really desirable and widely used. Especially if are discussing all inner methods, not just TLS-based only. The idea of allowing resumption through the outer TEAP tunnel is also great. It is simple. The obvious caveat here is that will not be achievable in TLS 1.2 (if tickets are used) since we cannot easily bind the ticket and the result of the inner authentication. But we could sacrifice that for the over whole simplicity… Moreover, I guess it is reasonable to assume most TEAP implementations will have TLS 1.3 in the stack anyway. Vadim ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
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. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Aug 20, 2023, at 5:09 AM, 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. Yes. Unfortunately it's too late for that, so I'll make a note of it here. Hopefully implementors will apply the TEAP text to other TLS-based EAP versions. Alan DeKok. ___ 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: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. Policy could then be around machine credential dictating if the device is even allowed to connect and how (link allowed) whilst the actual type of access granted (routes, firewalling, ...) is determined by the user credential. Cheers ___ 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 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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/ On 19.08.23 21:12, Michael Richardson wrote: Eliot Lear wrote: >> We don't need or want anonymous ciphersuites here. > We should keep the TLS-POK work in mind. I didn't find an obvious draft about that in the TLS WG. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide OpenPGP_0x87B66B46D9D27A33.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
Eliot Lear wrote: >> We don't need or want anonymous ciphersuites here. > We should keep the TLS-POK work in mind. I didn't find an obvious draft about that in the TLS WG. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On 18 Aug 2023, at 23:26, Michael Richardson wrote: > > 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. We should keep the TLS-POK work in mind. Eliot ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
Heikki Vatiainen 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. 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. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Aug 18, 2023, at 1:29 PM, Heikki Vatiainen wrote: > Good find, looks good. Small fix, though. It's section C.5, not C.2. Fixed, thanks. Alan DeKok. ___ 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 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
Alan DeKok.
___
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] WGLC on draft-ietf-emu-rfc7170bis-11
On Aug 17, 2023, at 8:01 PM, Michael Richardson wrote: > Alan DeKok wrote: >>> section 2; paragraph 2, uses SHOULD several times without obvious >>> exceptions. Could be it is MUST? > >> I don't think we can mandate that the outer EAP identity is an NAI. > > okay, then the exception for the SHOULD needs text. Sure. >> NULL ciphers suites. IIRC this is based on a comment from Bernard >> which pointed this out. > > I think people need to be beat on the head here. OK, I'm happy to do that. >> All TEAP implementations SHOULD support resumption. Using resumption >> can significanly improve the scalability and stability of >> authentication systems. > > Again, if it's a SHOULD, then there is an exception :-) I'll add notes on "your network will catch on fire". > So, if you consider the case where engineer argues with CTO as to why they > need to spend the time, and the CTO is clueless, then it being > blindingly obvious doesn't matter. If the network will catch fire and die, > then really, it's a MUST. Given I think all implementations will support resumption, I'm happy to make it a MUST. > I'm not sure it's sane to use EAP-TLS for Inner method myself. I have similar doubts, but it's implemented in supplicants, so we can't really ban it. Given various other issues raised here, I'll add a new section "Limitations on inner EAP methods". * don't use TTLS, PEAP, or FAST * don't use EAP-GTC * for TLS 1.3, use a client certificate outside of the tunnel in preference to EAP-TLS > I wondered why the method exists, when EAP-PWD seems architecturally simpler. Passwords are stored "crypted' in the user DB. Historically this meant using PAP based methods for authentication. In contrast, MS-CHAP is incompatible with crypt'd password stores. RFC 8146 permits EAP-PWD to be used with crypted passwords, which seems better. However, the main reason to allow passwords is for OTP and TOTP based methods. I'll add some text. >>> section 3.5: I wonder if additional references to RFC6125 and the >>> UTA-bis version of that might be more clear. I think that this >>> section is going to get beat on by security review. I also suggest >>> that rather than saying how it is to be matched, I suggest the section >>> be more prescriptive in how certificates are expected to be formed. >>> (I recognize that this text has not changed since 7170) > >> Do you have suggested text? I'm wary of poking at things in this >> area. > > I think that you can poke at it now, or during IESG DISCUSS :-) > I can suggest something, but not today. If you open a github and assign it to > me, I will remember. Done. https://github.com/emu-wg/rfc7170bis/issues/24 > [ restart ] > > I'm trying to understand a situation grave enough to cause a failure, yet not > grave enough that the end points could essentially try again. (vs restarting > from scratch, or failing over to another server) Exactly. Suggestions are welcome. >>> Also, I wonder if the word "peer" above means "Peer", or just either >>> end. To that end, I found "Peer" very confusing at times. > >> It means "TEAP peer", to match the earlier "TEAP server" > > Okay, could it always be "Peer", and never "peer" then? I'll just make it explicitly "TEAP peer" to match the use of "TEAP server". > Sure, but the question is: is it better to have 5 1K things, or > 1 5K thing? Assuming that the TEAP level TLVs can be broken up that way. The TEAP TLVs can be broken up into multiple TLS fragments. However, the TLS layer ensures that their all of the data is presented to the TEAP application, or none of it is. i.e. the application should not have to do defragmentation itself. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On 18.08.23 15:31, Alan DeKok wrote: I don't see why we would want to_allow_ inner method resumption. What benefit does it bring over just using resumption on the outer TLS session? +1. What's the use case? Eliot ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Aug 18, 2023, at 5:46 AM, Vadim Cargatser (vcargats) wrote: > In TLS 1.2: the ticket is part of the handshake, so we cannot bind that with > the successful inner authentication, correct? Yes. However, RFC 9190 goes into detail about "don't send tickets until after authentication has completed". Or "don't allow tickets to be used until after authentication has been completed". These are issues common to all TLS-based EAP types. I'm not sure we need to call them out here. > In TLS 1.3: that should be possible to issue a ticket after the handshake, so > are we ok with such approach to perform inner methods resumption? I don't see why we would want to _allow_ inner method resumption. What benefit does it bring over just using resumption on the outer TLS session? > Is it worth explaining more on that in the document? I'll update it to ban inner method resumption. I think that's the best approach. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
Regarding resumptions: >>> 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. > I'm not sure it's sane to use EAP-TLS for Inner method myself. >> My $0.02 is to disallow inner resumption. It makes zero sense. If >> you want faster authentication, resume the outer session. How about >> after the added paragraph quoted above: >> In contrast, TEAP implementations SHOULD NOT perform resumption for >> inner methods. If the user or machine needs to be authenticated, it >> should use a full authentication method. If the user or machine needs >> to do resumption, it can perform a full authentication once, and then >> rely on the outer TLS session for resumption. > That sounds fine to me. Since PAC is not used anymore: In TLS 1.2: the ticket is part of the handshake, so we cannot bind that with the successful inner authentication, correct? In TLS 1.3: that should be possible to issue a ticket after the handshake, so are we ok with such approach to perform inner methods resumption? Is it worth explaining more on that in the document? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
Alan DeKok wrote: >> section 2; paragraph 2, uses SHOULD several times without obvious >> exceptions. Could be it is MUST? > I don't think we can mandate that the outer EAP identity is an NAI. okay, then the exception for the SHOULD needs text. >> Figure 2: should TLV Encapsulation be narrower than TLS, so show that >> it fits into TLS? Ditto Inner EAP Method fits into TLV. > Sure, but then the text doesn't fit into the fields any more. And > making the box wider will overflow the line width. So I think it's not > terrible, and OK as is. Agreed, it's not terrible. >>> be used in the case when the inner method provides mutual >>> authentication, key generation, and resistance to man-in-the-middle >>> and dictionary attacks. TLS ciphersuites that do not provide >> >> can you give an example of an inner method that does not do this? > NULL ciphers suites. IIRC this is based on a comment from Bernard > which pointed this out. I think people need to be beat on the head here. >> Section 3.3: it might be useful to reviewers not steeped in EAP and >> roaming to understand how often *TLS* resumption is used in practice >> (maybe eduroam have some server stats they could share?), and how it >> is important when roaming from AP to AP. (I understand that *TEAP* is >> not well used in eduroam yet, but EAP-TLS is) > How about this: > All TEAP implementations SHOULD support resumption. Using resumption > can significanly improve the scalability and stability of > authentication systems. Again, if it's a SHOULD, then there is an exception :-) > RFC9190 says systems SHOULD implement resumption, so we probably > can't make it a MUST here. You can always turn SHOULD into MUST. If it's just Quality of implementation issue, those people ignore MUSTs anyway. > I also don't know if it's worth getting into details as to why > resumption is useful. It's either blindingly obvious as to why, or > your network catches fire and dies. So, if you consider the case where engineer argues with CTO as to why they need to spend the time, and the CTO is clueless, then it being blindingly obvious doesn't matter. If the network will catch fire and die, then really, it's a MUST. >> 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. I'm not sure it's sane to use EAP-TLS for Inner method myself. > My $0.02 is to disallow inner resumption. It makes zero sense. If > you want faster authentication, resume the outer session. How about > after the added paragraph quoted above: > In contrast, TEAP implementations SHOULD NOT perform resumption for > inner methods. If the user or machine needs to be authenticated, it > should use a full authentication method. If the user or machine needs > to do resumption, it can perform a full authentication once, and then > rely on the outer TLS session for resumption. That sounds fine to me. >> It might be worth saying that 3.4.2 is a TEAP-TLV thing, and not >> EAP-PWD. > I'm not sure why. EAP-PWD is substantially different, and does a > crypto exchange. The TEAP password authentication just sends a bare > password inside of the TLS tunnel. Well, it took me a bit to understand. I wondered why the method exists, when EAP-PWD seems architecturally simpler. >> section 3.5: I wonder if additional references to RFC6125 and the >> UTA-bis version of that might be more clear. I think that this >> section is going to get beat on by security review. I also suggest >> that rather than saying how it is to be matched, I suggest the section >> be more prescriptive in how certificates are expected to be formed. >> (I recognize that this text has not changed since 7170) > Do you have suggested text? I'm wary of poking at things in this > area. I think that you can poke at it now, or during IESG DISCUSS :-) I can suggest something, but not today. If you open a github and assign it to me, I will remember. >> section 3.6: tls-unique is replaced by TLS Exporter in TLS 1.3. I >> think that there is missing TLS 1.3 text here. > That text is in RFC9427. Maybe "For TLS 1.2 and earlier, do this. > For TLS 1.3, see RFC 9427" Yes. >> section 3.7.2: >>> The EAP-Response packet sent by the peer may encapsulate a TLS >>> ClientHello handshake message, in which case the TEAP server MAY >>> allow the TEAP conversation to be restarted, or it MAY contain a TEAP >>> response with a zero-length message, in which case the server MUST >>> terminate the conversation with an EAP Failure >> >> What are some situations where a peer would expect to do a restart? >>
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
On Aug 17, 2023, at 5:02 PM, Michael Richardson wrote: > Some people might find this URL useful: > https://author-tools.ietf.org/diff?doc_1=RFC7170_2=draft-ietf-emu-rfc7170bis%2F The diff is surprisingly good. > Reading the document from top-to-bottom for the first time in awhile (to do > the Shepherd write-up), paragraph two of the Introduction, where EAP-FAST is > mentioned seems to be aged. It's from 7170, but given that this is 7170bis, > I wonder if the > history is entirely accurate, or really still timely. It's worth removing the text saying "EAP-FAST is widely used", and just saying "TEAP is based on EAP-FAST with change" > section 2; paragraph 2, uses SHOULD several times without obvious exceptions. > Could be it is MUST? I don't think we can mandate that the outer EAP identity is an NAI. There is also a discussion of why we can't make the EAP Identity a "MUST NAI" in RFC 7542 Section 2.6: https://datatracker.ietf.org/doc/html/rfc7542#section-2.6 > } Upon successful execution of TEAP, the EAP peer and > } EAP server both derive strong session key material that can then be > } communicated to the network access server (NAS) for use in > } establishing a link-layer security association. > > I feel like a reference is in order (but 7170 didn't have one). This is the MSK as defined in RFC 3748. I'll add a reference. > Figure 2: should TLV Encapsulation be narrower than TLS, so show that it fits > into TLS? Ditto Inner EAP Method fits into TLV. Sure, but then the text doesn't fit into the fields any more. And making the box wider will overflow the line width. So I think it's not terrible, and OK as is. >> The TEAP version is not protected by TLS and hence can be modified in >> transit. In order to detect a modification of the TEAP version, the > > I suggest: > >> The TEAP version is not protected by TLS and hence can be modified in >> transit. In order to detect a bid-down attack, where the TEAP version is >> modified, the > > (similar things are done in IKEv2, as well as in TLS; I don't know if a > reference is worthwhile here) I'll change it. It's probably not worth adding a reference. >> be used in the case when the inner method provides mutual >> authentication, key generation, and resistance to man-in-the-middle >> and dictionary attacks. TLS ciphersuites that do not provide > > can you give an example of an inner method that does not do this? NULL ciphers suites. IIRC this is based on a comment from Bernard which pointed this out. > Section 3.3: it might be useful to reviewers not steeped in EAP and roaming >to understand how often *TLS* resumption is used in practice (maybe > eduroam >have some server stats they could share?), and how it is important >when roaming from AP to AP. >(I understand that *TEAP* is not well used in eduroam yet, but EAP-TLS > is) How about this: All TEAP implementations SHOULD support resumption. Using resumption can significanly improve the scalability and stability of authentication systems. RFC9190 says systems SHOULD implement resumption, so we probably can't make it a MUST here. I also don't know if it's worth getting into details as to why resumption is useful. It's either blindingly obvious as to why, or your network catches fire and dies. > 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. My $0.02 is to disallow inner resumption. It makes zero sense. If you want faster authentication, resume the outer session. How about after the added paragraph quoted above: In contrast, TEAP implementations SHOULD NOT perform resumption for inner methods. If the user or machine needs to be authenticated, it should use a full authentication method. If the user or machine needs to do resumption, it can perform a full authentication once, and then rely on the outer TLS session for resumption. >> If a particular authentication method succeeds, the server SHOULD NOT >> attempt a subsequent authentication method. For example, if a user > > this seems to contradict the first paragraph that says that multiple > authentications are allowed. Yes. It should be: ... subsequent authentication method for the same Identity-Type. i.e. don't do "user" authentication twice. It's dumb. IIRC, this text was added based on a corner case Eliot brought up earlier on the list. > It might be worth saying that 3.4.2 is a TEAP-TLV thing, and not EAP-PWD. I'm not sure why. EAP-PWD is substantially different, and does a crypto exchange. The TEAP password authentication just sends a bare password inside of the TLS tunnel. > A most likely thing today for "Password" authentication is to use TOTP > methods against a hardware token. (X9.9, SecureID, etc.) Sure. I can add a reference to 6238. > If I
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
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 Some people might find this URL useful: https://author-tools.ietf.org/diff?doc_1=RFC7170_2=draft-ietf-emu-rfc7170bis%2F Reading the document from top-to-bottom for the first time in awhile (to do the Shepherd write-up), paragraph two of the Introduction, where EAP-FAST is mentioned seems to be aged. It's from 7170, but given that this is 7170bis, I wonder if the history is entirely accurate, or really still timely. section 2; paragraph 2, uses SHOULD several times without obvious exceptions. Could be it is MUST? } Upon successful execution of TEAP, the EAP peer and } EAP server both derive strong session key material that can then be } communicated to the network access server (NAS) for use in } establishing a link-layer security association. I feel like a reference is in order (but 7170 didn't have one). Figure 2: should TLV Encapsulation be narrower than TLS, so show that it fits into TLS? Ditto Inner EAP Method fits into TLV. > The TEAP version is not protected by TLS and hence can be modified in > transit. In order to detect a modification of the TEAP version, the I suggest: > The TEAP version is not protected by TLS and hence can be modified in > transit. In order to detect a bid-down attack, where the TEAP version is > modified, the (similar things are done in IKEv2, as well as in TLS; I don't know if a reference is worthwhile here) > be used in the case when the inner method provides mutual > authentication, key generation, and resistance to man-in-the-middle > and dictionary attacks. TLS ciphersuites that do not provide can you give an example of an inner method that does not do this? I assume EAP-PWD, but which others? Section 3.3: it might be useful to reviewers not steeped in EAP and roaming to understand how often *TLS* resumption is used in practice (maybe eduroam have some server stats they could share?), and how it is important when roaming from AP to AP. (I understand that *TEAP* is not well used in eduroam yet, but EAP-TLS is) If I did run EAP-TLS as an Inner method (whether once or twice), could I use resumption? > If a particular authentication method succeeds, the server SHOULD NOT > attempt a subsequent authentication method. For example, if a user this seems to contradict the first paragraph that says that multiple authentications are allowed. It might be worth saying that 3.4.2 is a TEAP-TLV thing, and not EAP-PWD. A most likely thing today for "Password" authentication is to use TOTP methods against a hardware token. (X9.9, SecureID, etc.) If I read correctly, a Crypto-Binding TLV is expected after every successful authentication method. If multiple passes occur, I'm unclear what to do with the multiple bindings. I think that they ought to be incremental. They can be checked each time though. section 3.5: I wonder if additional references to RFC6125 and the UTA-bis version of that might be more clear. I think that this section is going to get beat on by security review. I also suggest that rather than saying how it is to be matched, I suggest the section be more prescriptive in how certificates are expected to be formed. (I recognize that this text has not changed since 7170) section 3.6: tls-unique is replaced by TLS Exporter in TLS 1.3. I think that there is missing TLS 1.3 text here. section 3.7.2: > The EAP-Response packet sent by the peer may > encapsulate a TLS ClientHello handshake message, in which case the > TEAP server MAY allow the TEAP conversation to be restarted, or it > MAY contain a TEAP response with a zero-length message, in which case > the server MUST terminate the conversation with an EAP Failure What are some situations where a peer would expect to do a restart? Some kind of temporary resource exhaustion or something? ENORANDOMNUMBERSLEFTPLEASEWAITFORMORENEUTRINOS ?? Also, I wonder if the word "peer" above means "Peer", or just either end. To that end, I found "Peer" very confusing at times. section 3.7.3: maybe reorganize into point form. It seems like a long if-then-else, and maybe a case-when format would be easier. The edits since 7170 don't seem sufficient to clarify this section. section 3.9.: what is "server unauthenticated provisioning" (sounds like TEAP-BRSKI?) > TEAP peers MUST track whether or not server authentication has taken > place. When the server cannot be authenticated, the peer MUST NOT > request any services from it. so, if a TEAP (supplicant) peer can not validate the Server certificate, but it can get a MSK/EMSK that matches, then it can request "services" from it. (What are these services, if they aren't things that lead to an MSK? Ah, subsequent sections. Forward reference to 3.9.3 please)
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
I plan to implement. On 17.08.23 21: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. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu OpenPGP_0x87B66B46D9D27A33.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11
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. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] WGLC on draft-ietf-emu-rfc7170bis-11
Folks, 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. Thanks. Joe and Peter ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
