IETF Logo Mail Archive

Re: [radext] #153: Section 2.8 Access-Info

Bernard Aboba <bernard_aboba@hotmail.com> Sun, 09 June 2013 00:51 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E12121F95EF for <radext@ietfa.amsl.com>; Sat, 8 Jun 2013 17:51:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.459
X-Spam-Level:
X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WG06xZ0E2VlP for <radext@ietfa.amsl.com>; Sat, 8 Jun 2013 17:51:48 -0700 (PDT)
Received: from blu0-omc1-s38.blu0.hotmail.com (blu0-omc1-s38.blu0.hotmail.com [65.55.116.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9372D21F94BA for <radext@ietf.org>; Sat, 8 Jun 2013 17:51:48 -0700 (PDT)
Received: from BLU169-W127 ([65.55.116.8]) by blu0-omc1-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 8 Jun 2013 17:51:48 -0700
X-TMN: [5CjI+hACP27wW5ihx0+CKcRlX9t42mCHSKGOPZmxY8E=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W12706042E244DCC236F92B0939B0@phx.gbl>
Content-Type: multipart/alternative; boundary="_487d4a6b-c878-4c55-82db-96e0eec882f1_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: "lionel.morand@orange.com" <lionel.morand@orange.com>, "radext@ietf.org" <radext@ietf.org>, "draft-ietf-radext-ieee802ext@tools.ietf.org" <draft-ietf-radext-ieee802ext@tools.ietf.org>
Date: Sat, 08 Jun 2013 17:51:47 -0700
Importance: Normal
In-Reply-To: <27657_1370418838_51AEEE96_27657_5798_1_6B7134B31289DC4FAF731D844122B36E1FB0BA@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org>, <27657_1370418838_51AEEE96_27657_5798_1_6B7134B31289DC4FAF731D844122B36E1FB0BA@PEXCVZYM13.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Jun 2013 00:51:48.0643 (UTC) FILETIME=[85BF8730:01CE64AB]
Subject: Re: [radext] #153: Section 2.8 Access-Info
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Jun 2013 00:51:54 -0000

 Lionel said: 

> I'm not sure to understand this point.
> 
> As per section 10.1 in 802.1X, the access status indication is consecutive to an authentication procedure in any case. 
> So my assumption is that this status is valid for the duration of the session. If any change is required, you need to restart a session.
> Except if I have missed something...

[BA] The document allows the Access-Info Attribute in an Access-Challenge packet.  That doesn't seem compatible with "if any change is required you need to restart a session", because the value in an Access-Challenge could be different from that in an Access-Accept or Access-Reject.   Does inclusion in an Access-Challenge really make sense?

v2.23.0 | Report a Bug | By Email