There are several cases where authorization data is carried in EAP. In the case you site there is information about an authorization result that is carried within EAP. There are also cases where more detailed information is delivered to the peer. One example is the AT_TRUST_IND attribute that has been defined by 3GPP within EAP-AKA/SIM. This attribute allows the authentication server to signal to the peer whether the access network is trusted. Unfortunately, EAP methods do not have a generic way of carrying authorization information. Some methods will not have the capability to carry specific attributes this so it will not be possible to move to a different EAP type to support different credentials in these deployments. This breaks the plug-ability of EAP methods. Another potential issue here is that authorization information is often deployment or technology specific, which breaks the media independent properties of EAP. I would not recommend the general addi tion of authorization information to EAP unless a generic mechanism for communicating authorization information within EAP methods is developed.
Here is a suggested revision for this section: "2.1. Communication of authorisation information In some cases EAP methods carry authorization information. An EAP-AKA attribute, AT_TRUST_IND [3GPP TS 24.302], has been defined in 3GPP to allow the authentication server to signal to the EAP peer if it is attached to a trusted network. If the attribute indicates the network is not trusted then the EAP peer would establish an IPSEC tunnel to its home network to protect its communications. If the attribute indicates a trusted network then the EAP Peer may send its traffic without establishing an IPSEC tunnel since the network is authorized to handle it. It is also common for EAP methods to communicate information about access control decisions beyond just success and failure. For example, MSCHAPv2 signals (lack of) authorisation of an authenticated user to use a service. An MSCHAPv2 failure packet as defined in section 6 of [RFC2759] can indicate condition 646 "Restricted Logon hours". This determination is an authorisation check which happens subsequent to the authentication step (a user needs to be positively identified to correlate his identity to a list of permitted logon hours). This use of EAP is not covered by the EAP applicability statement since it goes beyond authentication. There are some potential issues that can arise from carrying authorization data in EAP. First, there is no generic mechanism for EAP methods to carry authorization data. In order to make use of and communicate the authorization data the EAP method will have to provide custom interfaces and capabilities. This will inhibit the ability for different EAP methods to be used in a pluggable fashion within deployments. It addition, if the authorization information is specific to a particular media, then it will break the media independent property of EAP. Extending individual EAP methods to carry authorization data for a specific deployment, technology, or media type is NOT RECOMMENDED. If the authorization data is informative such that the system operation is not significantly change if it is missing and if it is of a general nature then authorization data MAY be carried. If there is significant need for deployment specific, technology specific or media specific authorization information to be carried within EAP methods then a well defined mechanism and framework must be defined so the type of authorization data can be independent of the EAP method. This would allow the deployment of different EAP methods to support peers and servers with different credential types. " _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
