IETF Logo Mail Archive

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

<lionel.morand@orange.com> Sun, 09 June 2013 09:18 UTC

Return-Path: <lionel.morand@orange.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 6D84D21F9104 for <radext@ietfa.amsl.com>; Sun, 9 Jun 2013 02:18:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
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 tsLgsY68esVb for <radext@ietfa.amsl.com>; Sun, 9 Jun 2013 02:18:36 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C578521F9050 for <radext@ietf.org>; Sun, 9 Jun 2013 02:18:35 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 4F19518C7BD; Sun, 9 Jun 2013 11:18:30 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 30FD427C053; Sun, 9 Jun 2013 11:18:30 +0200 (CEST)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Sun, 9 Jun 2013 11:18:29 +0200
From: lionel.morand@orange.com
To: Bernard Aboba <bernard_aboba@hotmail.com>, "radext@ietf.org" <radext@ietf.org>, "draft-ietf-radext-ieee802ext@tools.ietf.org" <draft-ietf-radext-ieee802ext@tools.ietf.org>
Thread-Topic: [radext] #153: Section 2.8 Access-Info
Thread-Index: AQHOZKuGy2JS2JRmmECdv3c96epxtZktGvFg
Date: Sun, 09 Jun 2013 09:18:29 +0000
Message-ID: <28638_1370769510_51B44866_28638_19542_1_6B7134B31289DC4FAF731D844122B36E1FEC37@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org>, <27657_1370418838_51AEEE96_27657_5798_1_6B7134B31289DC4FAF731D844122B36E1FB0BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> <BLU169-W12706042E244DCC236F92B0939B0@phx.gbl>
In-Reply-To: <BLU169-W12706042E244DCC236F92B0939B0@phx.gbl>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E1FEC37PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.9.73321
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 09:18:41 -0000

I had the same concern. Not sure that this info in the Access-Challenge makes sense.

Lionel

De : Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Envoyé : dimanche 9 juin 2013 02:52
À : MORAND Lionel OLNC/OLN; radext@ietf.org; draft-ietf-radext-ieee802ext@tools.ietf.org
Objet : RE: [radext] #153: Section 2.8 Access-Info


 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?

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

v2.23.0 | Report a Bug | By Email