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

From: <[email-masked]>
Date: Wed, 5 Jun 2013 07:53:56 +0000

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...

Regards,

Lionel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de radext issue tracker
Envoyé : dimanche 5 mai 2013 00:52
À : [email-masked]; [email-masked]
Cc : [email-masked]
Objet : [radext] #153: Section 2.8 Access-Info

#153: Section 2.8 Access-Info

 The Access-Info Attribute is utilized by implementations of
       IEEE-802.1X [IEEE-802.1X] to specify the Access status information
       field within an Access Information Type Length Value Tuple (TLV)
       to be sent to the user within MACsec Key Agreement (MKA) or EAPoL-
       Announcement frames.

       A single Access-Info Attribute is permitted within a RADIUS
       Access-Accept, Access-Challenge, Access-Reject or Accounting-
       Request packet.

 [BA] The above paragraph seems to imply that the Access-Info Attribute
 could cause the Access status information to change during and after
 authentication.  It is unclear how supplicants would respond to such a
 change.  For example, the potential response to a change in MKA (which is
 authenticated) could be quite different from a change in an EAPoL-
 Announcement frame (which is not).  As a result, the desired behavior is
 unclear.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-radext-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  critical                 |  Milestone:  milestone1
Component:  ieee802ext               |    Version:  1.0
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/radext/trac/ticket/153>
radext <http://tools.ietf.org/radext/>

_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

_________________________________________________________________________________________________________________________

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.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 Jun 2013 17:51:47 -0700

> 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?

---

From: <[email-masked]>
Date: Sun, 9 Jun 2013 09:18:29 +0000

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

Lionel

De : Bernard Aboba [mailto:[email-masked]]
Envoyé : dimanche 9 juin 2013 02:52
À : MORAND Lionel OLNC/OLN; [email-masked]; [email-masked]
Objet : RE: [radext] #153: Section 2.8 Access-Info

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Jun 2013 07:30:21 -0700

Unless anyone objects, I will remove it.

---

From: "radext issue tracker" <[email-masked]>
Date: Sun, 09 Jun 2013 16:20:49 -0000

Comment (by [email-masked]):

 Proposed fix:

 Change:

 "A single Access-Info Attribute is permitted within a RADIUS
 Access-Accept, Access-Challenge, Access-Reject or Accounting-
 Request packet."

 To:

 "A single Access-Info Attribute is permitted within a RADIUS
 Access-Accept, Access-Reject or Accounting-Request packet."

 Also, change the table entry under Access-Challenge from 0-1 to 0.

 Severity:  In WG Last Call          |  Resolution:
 Keywords:                           |

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/153#comment:1>
radext <http://tools.ietf.org/radext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Sun, 09 Jun 2013 16:21:00 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-radext-
  [email-masked]          |  [email-masked]
     Type:  defect                   |      Status:  closed
 Priority:  critical                 |   Milestone:  milestone1
Component:  ieee802ext               |     Version:  1.0
 Severity:  In WG Last Call          |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/153#comment:2>
radext <http://tools.ietf.org/radext/>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 10 Jun 2013 00:05:10 +0000

Access Status is advertised to the supplicant in EAPOL-Announcement Messages which are separate from authentication messages.    I would it expect to be communicated in any message from the AAA server as it is possible you have some level of access before authentication completes.   Access-Info needs to be included in an Access-Challenge message.  

THanks,

Joe

---

From: "radext issue tracker" <[email-masked]>
Date: Mon, 10 Jun 2013 00:06:24 -0000

Changes (by [email-masked]):

 * status:  closed => reopened
 * resolution:  fixed =>

     Type:  defect                   |      Status:  reopened

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/153#comment:3>
radext <http://tools.ietf.org/radext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Mon, 10 Jun 2013 00:06:42 -0000

Comment (by [email-masked]):

 Access Status is advertised to the supplicant in EAPOL-Announcement
 Messages which are separate from authentication messages.    I would it
 expect to be communicated in any message from the AAA server as it is
 possible you have some level of access before authentication completes.
 Access-Info needs to be included in an Access-Challenge message.

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/153#comment:4>
radext <http://tools.ietf.org/radext/>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Jun 2013 10:48:55 -0700

Joe said: 
  
"Access Status is advertised to the supplicant in EAPOL-Announcement Messages which are separate from authentication messages.    I would it expect to be communicated in any message from the AAA server as it is possible you have some level of access before authentication completes.   Access-Info needs to be included in an Access-Challenge message.  "
 
[BA]  As I understand it, the use of the Access-Info attribute is to allow for the setting (and reporting) of the Access Status, which might be provided in response to a request (or not); protected by MKA (or not); could relate to a particular NID or for the port in general.   This raises the question of what the usage scenarios are, and whether the document covers them. 
 
For example: 
 
a. Is there a scenario where the Access-Info attribute could be used along with Service-Type="Call Check"?  For example, if a request comes in, could the RADIUS client generate a Call-Check message (e.g. with the MAC address of the supplicant in the Calling-Station-Id parameter) and then use the information in the Access-Info Attribute within the EAPoL-Announcement sent in reply? 
 
b.  Is the Access-Info Attribute always used to communicate status for the port in general, or can it sometimes be used to indicate the status for a particular NID?  If the latter, how is the NID to which Access-Info relates communicated?  Does the inclusion of an Network-Id-Name Attribute in the Access-Accept indicate that the Access-Info Attribute is NID-specific? 
 
IEEE 802.1X-2010 Section 11.12.2 states:
 
The Access Information TLV provides the information specified in clause 10.1 (see Table 11-9) for a particular NID or for the port in general (if the TLV is encoded before any set TLV).

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 11 Jun 2013 04:23:42 +0000

On Jun 10, 2013, at 10:48 AM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:

Joe said:

For example:

[Joe] Yes, some systems provide limited access for specific MAC addresses.

[Joe] Good point.  I agree the behavior should be that if the Access-info attribute is included without a Network-ID-Name then it should pertain to the port in general.  If the access info attribute is included along with a network-ID-Name attribute then it pertains to the identified NID.