Re: [Emu] Fixes and suggestions for draft-ietf-emu-tls-eap-types-09
On Nov 18, 2022, at 8:50 AM, Heikki Vatiainen wrote:
>
> 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.
I agree.
>
> 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)
Fixed, thanks. This aligns the document with RFC 7170.
> 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.
Fixed.
> 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 ...
I think that's good.
> 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 ...
That's good.
> The first sentence in the second paragraph of section 3. says '"TLS finished"
> method' which is one case where simple 'Finished message' would work.
Fixed.
> 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.
Fixed, thanks.
> 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.
Fixed.
> 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.
I agree. I've fixed it.
>
> Other minor suggestions and fixes
> +
> EAP-Response/Identity could be used as the common notation for the two uses
> in section 3.1.
Fixed.
> Section 6.1 has '... do not provided ...'. Remove 'ed'.
Fixed.
> Section 7 has a typo: tje
Fixed.
Thanks for the comments. Hopefully we can get an IETF last call soon.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-ietf-emu-rfc7170bis-01 - few more comments
On Jan 4, 2023, at 11:45 AM, Oleg Pekar wrote: > > Hi all, > Few more comments: > 1) Section "3.3.4. Protected Termination and Acknowledged Result Indication" > > Except as noted below, the Crypto-Binding TLV MUST be >exchanged and verified before the final Result TLV exchange, >regardless of whether or not there is an inner EAP method >authentication. 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 >authentications. > > --this is confusing by introducing another term "inner authentication" in > addition to two existing in the document "inner method" and "inner EAP > method". Please note that there could be no real authentication but just > unsuccessful inner EAP method negotiation or even just exchange of Identity > Request/Response. Maybe we should do a very formal approach: > • Define inner method as something that is conducted in Phase 2 > • Define two types of inner method - inner EAP method (that starts with > Identity Request, no matter whether it performs authentication or not) and > basic password authentication and treat them in the same way > • We should also consider the option when there's no inner method in Phase 2 I think the document should use "inner authentication method" every time it could be either EAP or password. I'll see if we can clarify the wording as to what happens when there's no inner authentication method. > The same regarding the section "3.6. Error Handling, item #3" and "4.2.11. > Intermediate-Result TLV" and few other places. > > 2) Nit: Section "5.2. Intermediate Compound Key Derivations" - looks that > the concatenation operator is escaped, while in the other places it is not: > > IMCK[j] = TLS-PRF(S-IMCK[j-1], > "Inner Methods Compound Keys" \|\| OK. I'll fix that. > 3) Are we planning to address all errata items in this review cycle? Some of > them are not yet in. The hope is to have them all fixed by the end of January. Please check the GitHub repo. I've put in a bunch of fixes which weren't filed as explicit errata. There's a lot of commits there, but each one is relatively small. They're also cross-link to either the official errata, or to the changes from the "teap-errata" GitHub repo, or the commits have explanations as to why they've been made. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] draft-ietf-emu-rfc7170bis-01 - few more comments
Hi all, Few more comments: 1) Section "3.3.4. Protected Termination and Acknowledged Result Indication" Except as noted below, the Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange, regardless of whether or not there is an inner EAP method authentication. 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 authentications. --this is confusing by introducing another term "inner authentication" in addition to two existing in the document "inner method" and "inner EAP method". Please note that there could be no real authentication but just unsuccessful inner EAP method negotiation or even just exchange of Identity Request/Response. Maybe we should do a very formal approach: • Define inner method as something that is conducted in Phase 2 • Define two types of inner method - inner EAP method (that starts with Identity Request, no matter whether it performs authentication or not) and basic password authentication and treat them in the same way • We should also consider the option when there's no inner method in Phase 2 The same regarding the section "3.6. Error Handling, item #3" and "4.2.11. Intermediate-Result TLV" and few other places. 2) Nit: Section "5.2. Intermediate Compound Key Derivations" - looks that the concatenation operator is escaped, while in the other places it is not: IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" \|\| 3) Are we planning to address all errata items in this review cycle? Some of them are not yet in. Thanks Oleg ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] RFC 7170bis Issue 4: do we want to keep PAC/PAC-Ackonwledgment?
On Jan 4, 2023, at 5:09 AM, Eliot Lear wrote: > > We have discussed not adding a lot into TEAP, but it might be good to > consider removing some stuff. PAC tops the list of things I'd like to see > removed. This is relevant to Erratum 5844 in that the example given contains > a PAC/PAC-Acknowledgment. This also, has bearing on whether or not we bump > the TEAP version. I think it's best to leave it in. We already have TLS 1.3 updates which remove the PAC. That doesn't require a version update. Which says to me even more that we should update this document with TLS 1.3 issues. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] RFC 7170bis: More small potatoes: use Obsoletes
On Jan 4, 2023, at 3:20 AM, Eliot Lear wrote: > > This document is a complete specification, and as such should obsolete RFC > 7170 (if approved). Address in https://github.com/emu-wg/rfc7170bis/commit/225cd8a0ce908febf12f1e4c16ab2eae3db3ce5f Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] RFC 7170bis: Small potatoes: IANA registry
On Jan 4, 2023, at 3:18 AM, Eliot Lear wrote: > > This is almost editorial. > > The TLV registry and the various registrations should now be pointed to this > document as the authority rather than RFC 7170, and we should retain the > registration policy statement for TLVs here. Frankly, specification required > is just a little thin. We probably should provide a template. We should also > leave a tombstone to indicate how the registries were formed. > > I've opened GH issue 1 on this: https://github.com/emu-wg/rfc7170bis/issues/1 I'll add some text addressing the simpler issues. As for registration policy, that will require a deeper WG discussion. I'll see if I can add a template, too. But likely not before the interim today. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-09.txt
On Wed, 4 Jan 2023, at 09:17, Alexander Clouter wrote: > > For TEAP (and similarly for FAST) we need to do more than just state > "PACs are dead use NewSessionTicket"[1]. Looks like I jumped at this too quickly, there is some text from the original RFC7170: https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-01#name-tls-session-resume-using-a- https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-01#section-3.8.1 It clearly states PAC-Info is not to be used when NewSessionTicket is so we can get rid of it and all its sub-attributes. Though not described, I guess we can *assume* A-ID/Authority-ID is tracked via the Outer-TLV values, though we now lose A-ID-Info and I-ID. It is not described (or shown) but I suppose we can *assume* the conversation (which can be started by the peer with PAC-TLV[PAC-Type]) is otherwise: [server] TLS NewSessionTicket [peer] PAC-Acknowledgement inside tunnel The peer can request several PACs upfront (though as only Tunnel-PAC is supported this probably has not be exercised) there is no language about if the server has to respond in order, especially as it is (by policy) allowed to ignore some of those requests. So fortunately no need for the 'extensions' field, but maybe this is more a change to the RFC7170bis draft rather than here to firm up how to use NewSessionTicket around A-ID/Authority-ID and a explicit declaration that PAC's must be provisioned in order they were requested? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] RFC 7170bis Issue 4: do we want to keep PAC/PAC-Ackonwledgment?
We have discussed not adding a lot into TEAP, but it might be good to consider removing some stuff. PAC tops the list of things I'd like to see removed. This is relevant to Erratum 5844 in that the example given contains a PAC/PAC-Acknowledgment. This also, has bearing on whether or not we bump the TEAP version. Eliot ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-09.txt
On Tue, 27 Sep 2022, at 13:25, 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-09.txt > Pages : 21 > Date: 2022-09-27 For TEAP (and similarly for FAST) we need to do more than just state "PACs are dead use NewSessionTicket"[1]. Crucially what goes into 'ticket'? Is this value just the PAC-TLV and parsed by the peer to extract the PSK identity? If so this would rub up against the 'opaque label' nature of the field. I think we should describe how to use the 'extensions' field and define an 'ExtensionType' for our PAC-TLV[2]. We also need to state that some of those sub-attributes are handled differently: * PAC-Key: replaced by internal TLS library magic * PAC-Opaque: replaced by value of 'NewSessionTicket.ticket'? * PAC-Info * PAC-Lifetime: replaced by ticket_lifetime+ticket_add_add * A-ID: still used * I-ID: still used * A-ID-Info: still used * PAC-Type: still used * PAC-Acknowledgement: no longer used Thanks [1] https://www.rfc-editor.org/rfc/rfc8446#section-4.6.1 [2] https://www.rfc-editor.org/rfc/rfc7170.html#section-4.2.12 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] RFC 7170bis: More small potatoes: use Obsoletes
This document is a complete specification, and as such should obsolete RFC 7170 (if approved). Eliot ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] RFC 7170bis: Small potatoes: IANA registry
This is almost editorial. The TLV registry and the various registrations should now be pointed to *this* document as the authority rather than RFC 7170, and we should retain the registration policy statement for TLVs here. Frankly, specification required is just a little thin. We probably should provide a template. We should also leave a tombstone to indicate how the registries were formed. I've opened GH issue 1 on this: https://github.com/emu-wg/rfc7170bis/issues/1 Eliot ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
