[eap] EAP Id management
"Alper Yegin" <alper.yegin@yegin.org> Wed, 27 May 2009 07:47 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 D1A1928C1B5 for <ietfarch-eap-archive@core3.amsl.com>; Wed, 27 May 2009 00:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.815
X-Spam-Level:
X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449]
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 zf22icnUCm65 for <ietfarch-eap-archive@core3.amsl.com>; Wed, 27 May 2009 00:47:28 -0700 (PDT)
Received: from lists.tigertech.net (lists.tigertech.net [64.62.209.34]) by core3.amsl.com (Postfix) with ESMTP id 94BD728C234 for <eap-archive@lists.ietf.org>; Wed, 27 May 2009 00:46:39 -0700 (PDT)
Received: from zoidberg.tigertech.net (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 07C54E182FD for <eap-archive@lists.ietf.org>; Wed, 27 May 2009 00:48:10 -0700 (PDT)
Received: from mx3.tigertech.net (morbo.tigertech.net [67.131.251.53]) by lists.tigertech.net (Postfix) with ESMTP id 4D385E240B0 for <eap@lists.tigertech.net>; Wed, 27 May 2009 00:47:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 1CA9619D9D5 for <eap@frascone.com>; Wed, 27 May 2009 00:47:58 -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 78C6919D9B2 for <eap@frascone.com>; Wed, 27 May 2009 00:47:57 -0700 (PDT)
X-TigerTech-Content-Filter: Clean
X-TigerTech-Spam-Status: Level 0 (High) (P0); Whitelisted TTSSA (alper.yegin@yegin.org whitelisted)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by mx3.tigertech.net (Postfix) with ESMTP for <eap@frascone.com>; Wed, 27 May 2009 00:47:57 -0700 (PDT)
Received: from LENOVO (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1M9DrZ2KWc-000fmw; Wed, 27 May 2009 03:47:54 -0400
From: Alper Yegin <alper.yegin@yegin.org>
To: eap@frascone.com
Date: Wed, 27 May 2009 10:47:39 +0300
Message-ID: <0aed01c9de9f$6cb24ac0$4616e040$@yegin>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acnen2g5nQDzvCGISyyfpU7dtYG7ww==
Content-Language: en-us
X-Provags-ID: V01U2FsdGVkX1+KVTYlKcVT7s6GqP8Lb678WITMYGc/Uc8+Qgz +Dz+4jjqM4IpgjEm1/6hgHyU5PQ7MSMS/nnVBPr1FYBwj7IiLk y4DuATaeYWtAMlwWcrbFQ==
Subject: [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: multipart/mixed; boundary="===============1496383389=="
Errors-To: eap-bounces+eap-archive=lists.ietf.org@frascone.com
I hope this ML is active and people can provide feedback. 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. This statement implies that the Identifier management extends beyond EAP-Success/Failure into subsequent EAP re-authentications. 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.] 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. So, which one is the right way, and which one did the implementations follow? I already asked few people, and need feedback from others as well. Thanks in advance. Alper
_________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap
- [eap] EAP Id management Alper Yegin
- Re: [eap] EAP Id management Alan DeKok