I have gathered these comments over time and therefore some of them are not
fully fleshed out. If you have any questions I will try and reconstruct my
ideas at the time.
Jim
Version Negotiation - terminate the conversation - w or w/o a fail?
Edge case - what if peer only supports a higher version than the
server supports? NAK?
EAP Server Name Checking - On what basis does the client accept or not
accept the EAP server name? You are suggesting that it is signed by a CA
controlling the intended domain, but what does this mean? Are you
suggesting that the CA should have a DNS subject alt name in it for the
domain in question?
If no embedded EAP methods run, then no crypto check and thus no version #
checking is done. Also no checking done if only one inner EAP method is
used as this only sends the Result TLV and not the Crypto-Binding TLV
'serially in a sequence' is redundant - section 3.3.1
Not only does it not allow initiating multiple EAP methods in parallel, it
requires that they not be running in parallel. This is a more strict
condition
Para #3 - can the peer return an error and treat the failure of a specific
EAP method as a total failure for the overall process - or at least
recommend that it should be an overall failure?
Confused messages in 3.3.1 and 3.3.3 about sending intermediate results and
final results at the same time. Specifically 3.3.1 says MUST NOT for one
inner EAP method, but text is not reflected in section 3.3.3
Conflict between 3.3.3 and security considerations (7.5) about sending a
different value in the Result TLV and the clear result in the event of not
doing a Request-Action TLV from the client. Is the server required to use
the client suggested result in the event it does not perform the request
action - could it use a different failure message or a success message?
Does it matter?
Section 3.4 - Need to address the following issues:
1. what if both certificates and an inner EAP method are run - what is the
Peer-Id then?
2. What if multiple inner EAP methods are run - which Peer-Id is used then?
3. What if client and machine EAP methods are run - which one to use then?
(Internal what are the ids used for?)
Section 3.6 - item #2 - it should be noted that not all failure indications
would be transmitted. The failure/success of the last EAP method may not be
sent as it gets wrapped into the Result TLV message
Section 3.6.2 - (internal) - if you get a TLV rules violation - does the TLV
itself need to be acknowledged?
Section 3.7 - Can I assume that the identifier value is monotonically
increasing and does not wrap?
Section 3.7 - it might be useful to tell me how to error for a message too
big or response time too long in dealing with fragmentation - are both just
final errors? Or should it potentially be treated as a TLS error?
Section 3.2 - possible clarification. If all TLVs in a message are marked
optional and none are understood by the peer, then an EMPTY response message
must still be sent to the server.
Section 4.2.2 - Result TLV MUST NOT be accompanied by Crypto-binding TLV -
not what it says in section 3.3
Section 4.2.3 - NAK TLV should not be accompanied by other TLVs. Not sure
I understand why. If I send an EAP plus a vendor w/ mandatory set, should
not I get back a NAK on the vendor plus a result for the EAP?
I might be happy to not do the vendor, but want to distinguish between you
cannot do this vs you choose not to do this. <Not fully sure that I really
care about this case as long I can assume that if the mandatory bit is set
then I would always fail the overall EAP conversation.>
Section 4.2.10 - How can I know if the server does or does not process the
channel binding TLV? This may be part of my policy as a peer depending on
circumstances.
Section 4.2.8 - Currently says that version should be 1 while the version
defined in the intro sections is 2 - would be correct if we change the EAP
method.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
