Re: Now a question on legacy authentication
Jari Arkko <jari.arkko@kolumbus.fi> Wed, 26 February 2003 11:10 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00929 for <ipsec-archive@lists.ietf.org>; Wed, 26 Feb 2003 06:10:57 -0500 (EST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA05230 Wed, 26 Feb 2003 03:20:32 -0500 (EST)
Message-ID: <3E5C7970.5000306@kolumbus.fi>
Date: Wed, 26 Feb 2003 10:23:12 +0200
From: Jari Arkko <jari.arkko@kolumbus.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: radia.perlman@sun.com
Cc: ipsec@lists.tislabs.com
Subject: Re: Now a question on legacy authentication
References: <200302260455.h1Q4tqM01659@sydney.East.Sun.COM>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit
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
- Now a question on legacy authentication Radia Perlman - Boston Center for Networking
- Re: Now a question on legacy authentication Jari Arkko
- Re: Now a question on legacy authentication Radia Perlman - Boston Center for Networking
- Re: Now a question on legacy authentication Andrew Krywaniuk