[Emu] review of draft-ietf-emu-eaptunnel-req-04

["Dan Harkins" <[e-mail]>]

  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.

  - 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."

  - 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.

  - 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.

    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.

  - 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.

  - 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.

  - 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 section 4.2.1.1.1.

  - 4.2.1.1.3 begins saying "A tunnel method MUST provide unidirectional
    authentication from authentication server to EAP peer and mutual
    authentication between authentication server and EAP peer."

    This is a nonsense statement. Either it's unidirectional or it's
    mutual, it can't be both.

    Additionally, it says "mandatory to implement cipher suites MUST NOT
    include...mutually anonymous authentication...."

    Seeing as how this subsection is under 4.2.1 and 4.2.1.1.1 describes
    these as TLS cipher suites then I really think this should be changed.
    An anonymous TLS cipher suite negotiated by the EAP tunnel method
    will be extremely valuable when combined with something like EAP-pwd
    as the inner method. That would provide a way to securely satisfy the
    credential provisioning requirement (which is a MUST by the way).

    Please restate the requirement to say something along the lines of
    "if an anonymous TLS ciphersuite is used by the outer tunnel then an
    inner method providing mutual authentication MUST be used."

  - 4.2.1.2 requires replay protection and then goes on to say that TLS
    (which is required by 4.2.1) satisfies this requirement.

    Please remove 4.2.1.2 since it does not add a new requirement.

  regards,

  Dan.