Thanks Dan,
I haven't seen any responses on the list yet so I provided some inline
below.
-Original Message-
From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
Dan
Harkins
Sent: Monday, November 30, 2009 12:57 PM
To: emu@ietf.org
Subject: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Hello,
I made some of these comments at the mic in Hiroshima but was
asked to submit them to the list.
- I get the feeling that this document is being written to
ensure some end-game and not simply as a protocol requirements
document.
I mentioned that it would be nice if the tunneled method
described a way to establish an EAP-TLS -style connection,
either anonymous or server-side-auth-only, and then allow
for subsequent authentication using another EAP method (or
using specific TLVs for some password authentication) or
EAP methods chained together by the tunnel. Pasi said that
is the intention but it sure doesn't seem that way.
[Joe] Currently the scope of the work does not include anonymous
authentication. I think this could be follow-on work to the tunnel
method. I don't think the current document should prohibit anonymous
cipher suites from being used in follow-on specifications. See the
response to 4.2.1.1.3 for some suggested text.
- section 3.4 states that the tunnel method MUST ensure that
peer identity is not disclosed to the authenticator and any
other intermediaries before the server that terminates the
tunnel method.
EAP is supposed to be a 2 party protocol that, for optimization,
can have functionality split between a pass-thru authenticator
and a EAP method-terminating server. But it seems wrong to
put forth the optimization as if it's a requirement for the
tunnel method.
Please change this to something like the identity of the peer
used for authentication purposes MUST NOT be obtainable by any
entity other than the EAP server terminating the tunnel method.
[Joe] OK
- 3.6 seems somewhat pointless. The tunnel method SHOULD support
carrying of NEA protocols and these protocols may be required
to be carried in an EAP method.
Since the tunneled EAP method can tunnel EAP methods then this
requirement should just naturally flow out of another
requirement.
Please remove section 3.6.
[Joe] While, it is true that carrying NEA protocols should be met by
either the extensibility or carrying EAP method requirements, I believe
that NEA use case is pertinent to the tunnel method work and should be
mentioned somewhere in the document. What is the harm in mentioning it
here?
- 3.7 describes credentials [that] may only partially authenticate
the identity of the peer.
Huh? What kind of credentials are these? Please describe these
credentials.
[Joe] OK
Additionally, the tunnel may be used to communicate additional
data.
This is so vague as to be meaningless. A nonce could satisfy
this requirement, and so could 8 bits of RESERVED-- set to zero
before transmitting and ignored upon receipt-- for that matter.
Please remove this.
[Joe] Removed
- 3.8 mentions a use of extensibility is support for authentication
frameworks other than EAP.
That seems like a huge stretch of the work we are chartered to do.
I suggest that line be removed.
[Joe] Alan had a similar comment that this text is confusing. The
suggest text is:
Another use for extensibility is support for alternate authentication
frameworks within the tunnel.
- 4.1.2 is inappropriate. It is not the purpose of a document
describing
the requirements for a protocol to direct the working group how to
evaluate potential protocols against those requirements.
When I brought this up in Hiroshima a response was (I paraphrase),
that the working group had consensus to use existing work and so
this is just a restatement of that consensus. Which raises
another
interesting point without addressing my comment. That other point
is
that if there is working group consensus then it is not necessary
to
have section 4.1.2 then. The fact that 4.1.2 is in the document
leads
one to believe that perhaps there is a fear that such support
might
have evaporated.
The working group does not need to be constrained in its decision-
making process. The process is defined and understood and it is
inappropriate for a _protocol requirements document_ to say, hey
remember way back when a sample of active participants seemed to
agree on a vague concept, well now you SHOULD select one of the
two
candidates here.
Please remove 4.1.2.
[Joe] Needs more discussion.
- 4.2.1.1.1 if TLS is required and [a]ll versions of TLS meet
[cipher suite negotiation] requirements then what's the point of
this section?
Please remove
