[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Now a question on legacy authentication



Radia Perlman - Boston Center for Networking wrote:
> It seems like EAP is just sending a string
> to be displayed at the client end, and
> the client (with the help of the human)
> constructs a string to be sent back.
> 
> So, why is it necessary to have the legacy
> authentication type sent by Bob in message 4?
> It doesn't look like the client does anything
> different based on the legacy authentication type.

I'm not sure I understand the question. Are we talking
about ikev2-05 and its use of EAP? EAP authentication
methods are not just strings to be displayed to the user.
As a result of executing some password authentication,
the user could be prompted for a password. But the
password could also be stored, or the authentication
could be done by some card, and the card could verify
the user's presence at device boot-up time with a PIN.
The EAP protocol does have a Notification message which
contains a string to be displayed to the user, but
that message has no side-effects to the operation of the
protocol as such.

With "legacy authentication type", do you mean the
Type field in the EAP header? This value is really
only used on the first request, but is still copied
on all subsequent responses and further requests, if
any.

Also, now that I took a quick look at the EAP support
in the IKEv2 document, I have a few questions and
comments of my own:

- Section 2.16 text

     "... be added in the future without updating this specification, the
      protocols expected to be used most commonly are fully documented
      here ..."

   I'm not sure this is the case (the most commonly used claim). Also,
   None of the EAP methods seem to have been documented in this
   draft. It mentions the type numbers for some methods, but not
   the normative behaviour. See Section 3 of RFC 2284.

- Section 2.16, AUTH rules:

      "For EAP methods that create a shared key as a side effect of
       authentication, that shared key MUST be used by both ..."

   This rule has to be more specific. In particular, the shared
   key is typically not available starting from the first message. It
   may be available somewhere in the middle of the method or at the
   end. My suggestion would be to require the AUTH payload only
   on the messages that come after the EAP method has finished,
   and forbid it on other ones.

- Section 2.16, the message diagram could probably be
   clearer on what it means when the number of messages
   in EAP varies.

- Section 2.16 text:

      "The Initiator of an IKE-SA using EAP SHOULD be capable of extending
       the initial protocol exchange to at least ten IKE_AUTH exchanges in
       the event the Responder sends notification messages and/or retries
       the authentication prompt."

   Why ten? Actually, this sounds a bit small to cover all possible
   methods. Is there a reason why we could not just
   wait until a timeout occurs or something like that?

- Section 2.16 text

     "The protocol terminates when the Responder sends the
      Initiator and EAP payload containing either a success or
      failure type."

   A suggested rewrite: "Once the protocol exchange defined by
   the chosen EAP authentication method has successfully terminated,
   the responder MUST send an EAP payload containing the Success
   message. Similarly, if the authentication method has failed,
   the responder MUST send an EAP payload containing the Failure
   message. The responder MAY at any terminate the IKE exchange
   by sending an EAP payload containing the Failure message.

   The initiator MUST fail the IKE exchange, if the chosen
   EAP authentication method terminates unsuccessfully, or
   if an EAP payload with the Failure message has been received.
   The IKE exchange is successfully terminated if the authentication
   method terminates successfully, and an EAP payload with the
   Success message has been received."

- Section 3.16 s/NAC/Nak/

- Section 3.16 Type-Data field explanation. Now
   I'm starting to see the reason for your questions...
   Uh... this explanation is wrong. The contents
   of the Type-Data field depend entirely on the
   selected authentication mechanism. For EAP TLS
   or EAP AKA, for instance, the contents are method
   specific cryptographic messages.

   Also, while the Nak case for Type-Data is more
   or less inline with RFC 2284, this behaviour has
   been clarified and extended in RFC 2284bis.

   Suggested rewrite:

   "Type-Data

       The Type-Data field varies with the Type of Request and the
       associated Response. For the documentation of the
       EAP methods, see [RFC2284bis]."

- Section 3.16, it says:

    "Note that since IKE passes an indication of initiator identity in
     message 3 of the protocol, EAP based prompts for Identity SHOULD NOT
     be used."

   This behaviour is fine, but I'd like to rewrite this in
   a slightly more specific way:

    "Note that since IKE passes an indication of initiator identity
     in message 3 of the protocol, requests with Type set to
     Identity SHOULD NOT be sent. Requests received with this type
     SHOULD be silently discarded."

   Hmm... it still isn't clear to me how this would work
   if someone actually wants to go against the SHOULD NOT.
   Is there an attack if we allow initiators to respond to
   identity requests? I'm not familiar enough with IKEv2 to
   understand whether the identity passed in it is protected
   or not. If it is, maybe we should just use MUST NOT.

- Perhaps a reference to 2284bis would be more
   appropriate (draft-ietf-eap-rfc2284bis-01.txt).
   This document expected to be done sometime after the
   next IETF meeting.

Jari