My comments from a fresh-read. (I think I last read the document when I did the shepherd review, 2024-05-21) I found the number of external references overwhelming. I will read the diffs only after this top-to-bottom-read. This the first of perhaps two messages.
section 1.2:
> the inner method could also be a Public Key Cryptography Standard (PKCS)
> exchange.
I don't know what a PKCS exchange is. I mean, I have some 30year old PKCS
books my shelf, but generally, the were obsolete when I acquired them,
replaced with IETF specifications.
Perhaps it means a TLS connection authenticated with RSA?EcDSA?
section 2:
I find section 2.0 is FAR TOO detailed in paragraphs two, three and four to
be considered a protocol OVERVIEW. Keep paragraph five ("The TEAP
conversation is used...")
Probably those paragraphs deserve a new section 2.4 about Identities.
section 2.1:
new paragraph from: For example,
and I suggest another diagram, exactly like Figure 1, but now very specific
to this example. Peer<--802.11-->Authenticator<--Radius-->TEAP
Server<--??-->Inner Method server.
You could also put this diagram in section 2.2.
3.1: is there any point in even looking at the cleartext EAP Success?
It seems that if the TLS handshake fails, that only a cleartext EAP Failure
might be available.
3.2: It seems like RFC9325 is really the authoritative document on what
cipher suites must be supported. Maybe it should say:
As described in [RFC9325], (Section 4.2 for TLS 1.2, and Section 4.3 for TLS
1.3), the following cipher suites MUST be supported:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Other cipher suites MAY be supported, and updates to RFC9325 should be taken
into account.
} TEAP implementations MUST support mutual peer authentication during tunnel
} establishment using the TLS cipher suites specified in this section. The TEAP
} peer does not need to authenticate as part of the TLS exchange but can
} alternatively be authenticated through additional exchanges carried out in
} Phase 2.
I'm unclear if the TEAP peer must do authentication within TLS or not.
The two sentences seem in opposition to each other.
I think TLS mutual authentication is optional if the TEAP peer will
authenticate during phase 2, maybe that's a SHOULD in sentence one?
} However, this use of SubjectDN is deprecated for TEAP, and is forbidden in
} [RFC9525], Section 2.
so do TEAP peers check the SubjectDN or not?
I think they SHOULD NOT check it.
I found 3.4.1 difficult to follow. Maybe a time-sequence diagram is
worthwhile. Or just splitting it up into numbered steps, perhaps with a GOTO
STEP 4 as appropriate.
3.5:
> This document only describes TEAP issues when resumption is used for TLS
> versions of 1.2 and earlier.
But versions of TLS before 1.2 were excluded, right?
> All TEAP implementations MUST support resumption.
It seems to me that TEAP peer implementations could just never do it, and
thus never need to support it. The arguments for supporting it could be said
louder. I think that students all moving from one lecture room to another at
the top of the hour is a relevant example that could be expanded slightly
here.
3.6.1: it seems that a valid policy would be to do Machine authentication
first, and based upon that, it might then do User authentication, even
restricting which users can login from that machine.
Meanwhile, user-less machines (IoT devices, projectors, etc..) might
only ever do machine authentication.
I think this is supported by the text, but the wording seems
difficult.
3.6.2: is the inner EAP state machine responsible for retransmissions?
3.6.3: Servers MUST track the Username across muServers MUST track the
Username across multiple password rounds, and reject authentication if
the
identity changes from one Basic-Password-Auth-Resp TLV to the next.
There is
no reason for a user (or machine) to change identities in the middle of
authentication.
So, I'd better not typo my username?
3.6.5: paragraph one says limit to A and B. Paragraph two says lots of stuff
that works
with EAP-TLS will work. I'm a bit confused.
change:
"Implementations MUST NOT permit resumption for the inner EAP methods
such as EAP-TLS."
to:
"Implementations MUST NOT permit session resumption for inner EAP methods
such as EAP-TLS."
} EAP-TLS is permitted in Phase 2 for two use-cases. The first is when TLS
} 1.2 is used, as the client certificate is not protected as with TLS 1.3.
} It
} is therefore RECOMMENDED that when TLS 1.3 is used for the outer TEAP
} exchange, the client certificate is sent in Phase 1, instead of doing
} EAP-TLS in Phase 2. This behavior will simplify the authentication
} exchange, and use fewer round trips than doing EAP-TLS inside of TEAP.
move the second sentence, which is *NOT* about the two use cases to after the
next paragraph which is about the second use case for EAP-TLS.
} The second use-case for EAP-TLS in Phase 2 is where both the user and
} machine use client certificates for authentication. Since TLS permits only
} one client certificate to be presented, only one certificate can be used in
} Phase 1. The second certificate is then presented via EAP-TLS in Phase 2
I got the impression before that if I had User and Machine authentication,
that I should run two instances of EAP-TLS for inner method.
3.9.2:
} The server MUST terminate the TEAP The server MUST terminate the TEAP
} exchange with an EAP Failure packet, no matter what the client says.
is there any value in logging this message?
(s/client/peer/ ?)
It seems that it's just a way to make sure the peer has received EAP Failure
packet, right?
3.11:
"For example, if a strong shared secret is used to mutually authenticate the
user and the EAP server, the "
I'm surprised to see the word *user* here. I think it refers to a human at the
keyboard, rather than the software in the peer.
3.11.1: do you need to support CSR attributes like RFC7030?
(draft-ietf-lamps-rfc7030-csrattrs...)
PKCS7 CertificatesOnly objects are apparently hard to process in some
environments.
Why even use that? Isn't a certificate enough?
tls-unique is TLS 1.2 stuff, 1.3 uses an exporter.
how does the peer know what algorithm to use for signing the CSR, or what
kind of key to generate? This is why CSR attributes.
It doesn't seem worth including 3.11.3 if you can't use it with TLS 1.3
anyway.
3.11.4 Is the Lying NAS problem described in RFC6677?
I stopped at 4.x for now.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
