-Original Message-
From: Hao Zhou [mailto:hz...@cisco.com]
Sent: Wednesday, October 19, 2011 12:31 PM
To: Jim Schaad; draft-ietf-emu-eap-tunnel-met...@tools.ietf.org
Cc: emu@ietf.org
Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft
Jim:
Thanks for reviewing the draft in detail and comments provided. Please see
my response inline below.
On 10/17/11 6:08 PM, Jim Schaad i...@augustcellars.com wrote:
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?
[HZ] It depends. Server might want to proceed with other EAP type
negotiation by proposing a different EAP type, or terminate the
conversation
with an EAP-Failure. I will clarify that in the next rev.
Yes - but in this case I would expect a NAK from the client - possibly
proposing other methods. Is this correct?
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?
[HZ] It's up to client's policy, especially if the server cert is issued
by a public
CA. Client needs not only verify that the server cert presented is a valid
cert
signed by the trusted CA, but also the server name presented in the cert
is
matching the domain it tried to authenticate with. A FQDN in the CN or SAN
would be a way to do it.
If no embedded EAP methods run, then no crypto check and thus no
version # checking is done.
[HZ] That's true.
Ok - this would be in violation of the last paragraph in section 3.1 which
says that the version numbers MUST be 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
[HZ] That's not true. Crypto-binding would still be exchanged with Result
TLV.
Actually using of the Result TLV in lieu of IM-Result TLV is for legacy
reason in
EAP-FAST, which could be removed in next rev since we are designing a new
EAP method.
Please tell me where it says this is done. All I can see is that one CAN
send intermediate-result, result and crypto-binding TLVs in the same
message. (Unless of course only one is sent in which case the
Intermediate-Reuslt TLV MUST NOT be sent). However these is nothing that
says that the Crypto-binding TLV would be sent after the first and only EAP
method - or indeed after a sequence of EAP methods.
'serially in a sequence' is redundant - section 3.3.1
[HZ] Ok. The text is trying to distinguish from running multiple EAP
methods
in parallel.
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
[HZ] For simplicity, otherwise implementation would need to trace when the
1st method finishes and applies the key from the authentication to the
crypto-binding. Supporting them in complete sequence makes it simpler and
securer, as 2nd method might not be safe to run if the crypto-binging
after
1st method fails.
Do you ever expect a version to allow multiple EAP sequences to be run at
the same time? If not then just the statement that they MUST be executed
serially is probably sufficient.
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?
[HZ] Yes it can. It is actually described in Section 3.6.2, peer can send
up some
Fatal Error TLV and Result TLV to indicate the end.
Ok - either I don't see the text or my comment is not sufficiently clear.
Consider:
Client is running EAP-BLAH and returns inside of the EAP-BLAH method a
failure.
If the client wants an overall failure rather than leaving it up to the
server, does it send both the Result TLV failure and the EAP-Message w/ the
failure - or just the result TLV failure or is this not reasonable for the
client?
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
[HZ] I think we can change to always send IM result after each inner EAP
method, if only one inner method, then Result TLV could be sent as well.
See
explanation above.
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
