Re: [eap] EAP Id management

Alan DeKok <aland@deployingradius.com> Wed, 27 May 2009 10:27 UTC

Return-Path: <eap-bounces+eap-archive=lists.ietf.org@frascone.com>
X-Original-To: ietfarch-eap-archive@core3.amsl.com
Delivered-To: ietfarch-eap-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A19F93A6B21 for <ietfarch-eap-archive@core3.amsl.com>; Wed, 27 May 2009 03:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.715
X-Spam-Level:
X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=0.884, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkGXP9cuQM+0 for <ietfarch-eap-archive@core3.amsl.com>; Wed, 27 May 2009 03:27:29 -0700 (PDT)
Received: from lists.tigertech.net (lists.tigertech.net [64.62.209.34]) by core3.amsl.com (Postfix) with ESMTP id A6FC93A6E59 for <eap-archive@lists.ietf.org>; Wed, 27 May 2009 03:27:29 -0700 (PDT)
Received: from zoidberg.tigertech.net (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5AC5AE182F7 for <eap-archive@lists.ietf.org>; Wed, 27 May 2009 03:29:12 -0700 (PDT)
Received: from mx3.tigertech.net (morbo.tigertech.net [67.131.251.53]) by lists.tigertech.net (Postfix) with ESMTP id 31C67E240C1 for <eap@lists.tigertech.net>; Wed, 27 May 2009 03:29:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 16CB819DFEB for <eap@frascone.com>; Wed, 27 May 2009 03:29:05 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net
Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id A136019DFD4 for <eap@frascone.com>; Wed, 27 May 2009 03:29:04 -0700 (PDT)
X-TigerTech-Content-Filter: Clean
X-TigerTech-Spam-Status: Level 0 (High) (P0); Whitelisted TTSSA (aland@deployingradius.com whitelisted)
Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by mx3.tigertech.net (Postfix) with ESMTP for <eap@frascone.com>; Wed, 27 May 2009 03:29:04 -0700 (PDT)
Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 3E80C12343D2; Wed, 27 May 2009 12:29:03 +0200 (CEST)
Message-ID: <4A1D15EE.8050905@deployingradius.com>
Date: Wed, 27 May 2009 12:29:02 +0200
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Alper Yegin <alper.yegin@yegin.org>
References: <0aed01c9de9f$6cb24ac0$4616e040$@yegin@yegin.org>
In-Reply-To: <0aed01c9de9f$6cb24ac0$4616e040$@yegin@yegin.org>
X-Enigmail-Version: 0.95.7
Cc: eap@frascone.com
Subject: Re: [eap] EAP Id management
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for EAP <eap.frascone.com>
List-Post: <mailto:eap@frascone.com>
X-Tigertech-Mailman-Hint: 656170
List-Subscribe: <http://lists.frascone.com/mailman/listinfo/eap>, <mailto:eap-request@frascone.com?subject=subscribe>
List-Unsubscribe: <http://lists.frascone.com/mailman/listinfo/eap>, <mailto:eap-request@frascone.com?subject=unsubscribe>
List-Archive: <http://lists.frascone.com/pipermail/eap>
List-Help: <mailto:eap-request@frascone.com?subject=help>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com

Alper Yegin wrote:
> According to RFC 3748:
>
>       Since the Identifier space is unique to each session, 
>       authenticators are not restricted to only 256 simultaneous
>       authentication conversations.  Similarly, with re-authentication,
>       an EAP conversation might continue over a long period of time, and
>       is not limited to only 256 roundtrips.

  I think that statement isn't overly clear.

> This statement implies that the Identifier management extends beyond
> EAP-Success/Failure into subsequent EAP re-authentications.

  That would seem to be a valid interpretation of that sentence.
However, all AAA servers I'm aware of treat EAP sessions as finishing at
EAP-Success/Fail.

  That is, the *EAP* layer management treats re-authentication the same
as authentication.  The EAP Id's are tracked, but once an
EAP-Success/Fail is sent back, all information about "current" Id's is
discarded.

> If that’s
> true, Id of the first EAP packet after an EAP-Success (e.g., initiation
> of EAP re-auth) has to be different than the Id used with the
> EAP-Success. [Problem: EAP re-auth may take place with another
> authenticator in the case of mobility, and that authenticator would not
> know the last Id used with the previous authenticator.]

  Yes.

> But on the other hand, this text is not normative, and EAP State Machine
> RFC 4137 already ignores that by resetting currentId to "NONE" at the
> beginning of EAP authentication.

  Yes.

> So, which one is the right way, and which one did the implementations
> follow?

  The implementations I'm aware of all followed the method of RFC 4137:
Discard all information about Id's on Success/Fail.

  Alan DeKok.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap