[Emu] Opsdir last call review of draft-ietf-emu-rfc7170bis-15

2024-03-11 Thread Bo Wu via Datatracker
Reviewer: Bo Wu
Review result: Has Nits

Hi Authors,

I am the assigned opsdir reviewer for this document.

Overall, the document makes a significant improvement over RFC 7170.

This document obsoletes RFC 7170 (Tunnel Extensible Authentication Protocol
(TEAP) version 1), and improves the protocols with modifications to several
sections of RFC 7170, such as the Introduction, Terminology, TEAP protocol,
Message Formats, IANA Considerations, Message Formats, Security considerations,
and Examples. This document obsoletes Protected Access Credentials (PAC) from
implementation experience and improves the definition of the inner method.

Here are some nits I found:

1.2. Terminology
Inner method-> Inner Method
PKCS: Good to expand on first use.

3.2. TEAP Authentication Phase 1: Tunnel Establishment
TLS-PSK: Good to expand on the first use and add reference.

3.3. Server Certificate Requirements
Redundant word:
Systems SHOULD use a a private Certification Authority (CA) -> Systems SHOULD
use a private Certification Authority (CA)

3.4. Server Certificate Validation
Redundant period:
Further guidance on server identity validation can be found in [RFC9525]
Section 6.. -> Further guidance on server identity validation can be found in
[RFC9525] Section 6..

In Section 3.6.2:
TOTP expand on the first use
Redundant word:

The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT RECOMMENDED
-> The use of EAP-FAST-GTC as defined in [RFC5421] is NOT RECOMMENDED

3.6.4. Limitations on inner methods ->  3.6.4. Limitations on Inner Methods

EAP-TLS, EAP-MSCHAPv2, and perhaps EAP-pwd
I think it is good to add some reference.

3.6.5. 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 It is not clear to me "except as noted
below" is useful here.

3.11.2. Certificate Content and Uses
The format of a CSR is complex, and contain a substantial amount of
information.
-> The format of a CSR is complex, and contains a substantial amount of
information.

3.11.3. Server Unauthenticated Provisioning Mode
Instead, they should use that mode to set up a secure / authenticated tunnel
-> Instead, they should use that mode to set up a secure authenticated tunnel

Note that server unauthenticated provisioning -> Server Unauthenticated
Provisioning

 4.2.13. Crypto-Binding TLV
OLD:
< 1 Binding Response
New:
1 Binding Response

4.2.19. CSR-Attributes TLV
The base64 encoding in used
-> The base64 encoding is used

4.2.20. Identity-Hint TLV
The Identity-Hint TLV is an optional TLV which can sent
-> The Identity-Hint TLV is an optional TLV which can be sent

When the Identity-Hint is use
-> When the Identity-Hint is in use

The Identity-Hint TLV is used only as a guide to selecting
-> The Identity-Hint TLV is used only as a guide to select

5.3. Computing the Compound MAC
is run then no EMSK or MSK will be generated.
The sentence is incomplete.

5.4. EAP Master Session Key Generation
The label is is the ASCII value for the string without quotes.
->  The label is the ASCII value for the string without quotes.

I think the Appendix sections better to be placed after the References section.

Thanks,
Bo Wu



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Adoption call for eap.arpa

2024-03-11 Thread Jan-Frederik Rieckers
I think this work is useful, emu is the right WG for that, so I'm in 
favor of adopting.


Cheers,
Janfred

On 07.03.24 23:38, Peter Yee wrote:

This is an adoption call for the eap.arpa Internet-Draft
(draft-dekok-emu-eap-arpa). This is an ancillary draft that Alan
DeKok briefed during the Prague (IETF 118) meeting. Seeing as
it primarily exists as a forward-looking extraction of certain
descriptive material and IAB .arpa domanrequests from other
EMU documents, we consider it within the scope of the WG
charter. Alan did a recent minor update to the document and
will speak briefly about it during IETF 119.

With that said, your WG chairs would appreciate hearing your
feedback on whether this document is adopted or not. While
it's not critical to adopt, it really simplifies the domain
registration for things like TLS-POK and would have been
great back when we did EAP-NOOB.

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.

The deadline for feedback is March 21st. Yes, that's during IETF
119 but after the EMU time slot, so hopefully you will have
formed an opinion by then, if not sooner. We hope to hear
from lots of you!

Joe and Peter

1) https://datatracker.ietf.org/doc/draft-dekok-emu-eap-arpa/




--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network

Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens

Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822


smime.p7s
Description: S/MIME Cryptographic Signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu