Internet Engineering Task Force Walter Weiss RAP Working Group Ellacoya Networks Expiration: February 2002 John Vollbrecht draft-ietf-rap-access-bind-00.txt David Spence David Rago InterLink Networks Cees de Laat Univ. of Amsterdam Freek Dijkstra Univ. of Utrecht Leon Gommans Enterasys Amol Kulkarni Ravi Sahita Intel Kwok Chan Nortel Networks Framework for Binding Access Control to COPS Provisioning Last Updated: 7/13/01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Weiss et al. [Page 1] Internet Draft Binding Authentication to Provisioning July 2001 Status of this Memo................................................1 Conventions used in this document..................................1 Abstract...........................................................4 1. Introduction....................................................4 2. Paradigm for the Bind PIB.......................................6 2.1 Accessor Concepts..............................................6 2.1.1 Example - Ethernet IP Address Authorization..................9 2.2 Accessor Management Paradigm..................................10 2.3. Context Data.................................................16 2.4. Policy Distribution and Management...........................17 2.5. Interactions with DiffServ model.............................18 2.6. Interactions with RSVP model.................................19 3. Supporting various client Authentication Protocols.............19 3.1. EAP Authentication...........................................20 3.1.1. EAP Message sequence.......................................20 3.1.2. AuthEapReXXExt data structures.............................22 3.2. PAP Authentication...........................................23 3.2.1. PAP Connection sequence....................................23 3.2.2. AuthPapExtEntry datastructure..............................24 3.3. CHAP Authentication..........................................24 3.3.1. CHAP Connection sequence...................................25 3.3.2. AuthChapExtEntry datastructure.............................26 3.4. HTTP Authentication..........................................26 4. Data Structures................................................27 4.1. Accessor class...............................................27 4.2. AccessorElement class........................................28 4.3. AccessorSessionScope class...................................29 4.4. AccessorAuthProtocol class...................................30 4.5. ContextData class............................................30 4.6. Session class................................................31 4.7. AuthExt class................................................32 4.7.1. AuthEapReqExt class........................................33 4.7.2. AuthEapRespExt class.......................................33 4.7.3. AuthPapExt class...........................................33 4.7.4. AuthChapExt class..........................................34 4.8. ContextData classes..........................................34 4.8.1. CtxtL3Hdr class............................................34 4.8.2. Ctxt802Hdr class...........................................36 4.8.3. CtxtDialupInterface class..................................36 4.8.3.1 CtxtDialupIfFramedProtocol class..........................37 4.8.3.2 CtxtDialupIfLoginService class............................38 4.8.3.3 CtxtDialupIfLoginLat class................................39 5. Message Types..................................................40 5.1. Accessor Provisioning Decisions..............................40 5.2. Provisioning Report..........................................41 5.3. PEP Access Request...........................................41 5.4. PDP Access Response..........................................41 5.5. Session-specific ContextData Request.........................42 5.6. Session-specific ContextData Response........................43 5.7. Opaque Decision..............................................43 5.8. Opaque Report................................................43 6. Combining Data Structures in Messages..........................43 Weiss et al. Expires October 2000 [Page 2] Internet Draft Binding Authentication to Provisioning July 2001 6.1. Combining Access Request and Session-specific ContextData messages..........................................................44 6.2. Combining Access Response and Provisioning Decision messages.44 7. The AccessBind PIB Module......................................44 8. Security Considerations........................................74 9. References.....................................................75 10. Author Information and Acknowledgments........................76 Weiss et al. Expires October 2000 [Page 3] Internet Draft Binding Authentication to Provisioning July 2001 Abstract There is an ever-growing distinction between edge and core functionality. While the core continues to focus on stability and pure forwarding functionality, the edges increasingly need to deal with dynamic capabilities like QoS management, VPN encapsulations, encryption, dynamic steering and service monitoring. The dynamic deployment of these functions is dependent on specific contextual knowledge such as the physical location of the data stream and the identity of the client or system generating the data. In many environments, there is a requirement to both bind resource consumption to an identity or account, and also to quickly and efficiently provision the appropriate set of policies for that client or account. It is possible to provide this capability with a collection of currently available protocols. However, the synchronization of account and provisioning information between these protocols makes this approach extremely unwieldy. This memo offers a solution in the form of a single COPS PIB capable not only of supporting all the above requirements but also offering a scalable means for extending the provisioning capabilities as new technologies are standardized. Specifically, we offer a mechanism for provisioning the criteria for initiating a dynamic authorization requests from the PEP as well as a means for propagating credentials received by the PEP to allow the PDP to validate a client identity or an account. 1. Introduction There are two sides to access control. The one side is the negotiation between the client and the edge device (also known as the policy enforcement point), for example between a workstation and an Ethernet switch supporting authentication protocols like 802.1x and PPPoE. The other side of a typical access control model is an interaction between the edge device (PEP) and a PDP, such that the PDP performs the client/account validation process and notifies the PEP of the result. This separation of access control into two parts is necessary because invariably the PEP does not have the capacity to store all possible identities and credentials. This information is typically stored in a server (PDP). In reality access control can include authentication as one piece of a larger authorization process. As such, authorization has much in common with RSVP. When an RSVP service request is made, the PDP evaluates a set of criteria including what is being requested, what the availability of specific resources are, the identity of the requestor, and even the location of the requestor. All these criteria are taken into consideration before determining whether the RSVP request should be honored. In addition, if the request is Weiss et al. Expires October 2000 [Page 4] Internet Draft Binding Authentication to Provisioning July 2001 honored, specific provisioning actions may be taken to bound or manage the request. Similarly, the ability for a PDP to respond to a non-RSVP service request potentially requires all the same information of a traditional RSVP request in order to determine whether the request should be accepted or rejected. It is also important to note that a service request should not just be restricted to network access. In practice, there are many instances where a determination of access privileges requires an explicit decision. For instance, there are scenarios where limited network access is granted based on the specific criteria, but subsequent authorization is required to access a premium resource that requires incremental authentication (via HTTP for example). Another possible scenario occurs when initial access is authorized based on one set of credentials, but usage of a specific resource requires an examination of an account balance. These authorizations will be referred to as ôPEP Access Requestsö to denote the fact that PEP are requesting access to some type of service. In order to support the broad variety of potential PEP Access Requests, there must be a way of provisioning the criteria for generating the PEP Access Request. In the most common case the PEP Access Request is generated as a result of some type of packet oriented event such as activity on a link, traffic of a particular type or traffic from a new, unknown IP address. This leads to a useful observation: PEP Access Requests need to be defined within the context of network data path. In other words, the data path mechanisms defined in the DiffServ informal model [MODEL] and the DiffServ PIB [DSPIB] provide a means for specifying the circumstances for generating a PEP Access Request by reusing elements from the model like the qosDatapathTable table and the qosClfrTable table in the DiffServ PIB. Another consideration is the variety of information that can potentially be included in a PEP Access Request. For instance, a PEP Access Request could pass information about the client (domain), the physical port (dial up interface), L2 headers, L3 headers, encapsulation headers (tunnels), cookies, and additional information already negotiated prior to generating the PEP Access Request. Given the amount of information that could be sent with the PEP Access Request, it is reasonable to allow the PDP to configure the PEP with the set of information the PDP would like to have included with a specific type of PEP Access Request. PEP Access Requests provide a convenient means for the PEP to signal an event that requires specific actions. A PDP authorization for access to specific resources (and the potential verification of identity) is one example of an event that not only requires a response but also some potential provisioning work. It is interesting to note how neatly RSVP decision support fits into this model. In the original COPS design [COPS], the RESV request was sent in a COPS request and a COPS response message determined whether the Weiss et al. Expires October 2000 [Page 5] Internet Draft Binding Authentication to Provisioning July 2001 reservation should be accepted or not. The enhancements provided by this PIB not only allow RSVP messages to generate access requests, but also explicitly provision QoS resources, using COPS-PR [COPSPR], to support the reservation. This generalizes COPS for RSVP and allows it to evolve to the COPS-PR model. There are a number of situations where access requests need to be negotiated quickly. Mobile-IP applications in particular require speedy resolution of PEP Access Requests. This implies that the combination of PEP Access Requests and provisioning needs to be completed with the minimum number of communication legs (round trips). One of the problems discovered with existing PIBs [DSPIB, FPIB] was that it was difficult to support two-phase classification. In the general case, PEP Access Requests will be used to grant authenticated clients access to specific resources. As such, many clients are likely to share various combinations of resources. However each resource is likely to be provisioned once and shared by a set of clients. For example, a set of clients may share access to a Virtual Private Network while a set of overlapping clients may share access to a Voice over IP service, and a third set of overlapping clients may be given access to a set of premium services. The problem is that provisioning policies for each combination of client and resource creates an n-square policy table that is difficult to maintain and to scale. Provisioning the resources independent of the consumer of the resources and binding the two is a far more efficient approach allowing either resources or clients to be managed independently of each other. However, this requires approach requires two-phase classification, classifying the client independent of the resource. This PIB will define incremental structures to support this model. 2. Paradigm for the Bind PIB There are several key aspects to this PIB. First there is the ability to provisioning for future authorization request, known as PEP Access requests. Second, there is a set of tables that used to notify the PDP of an attempt to access managed resources. These tables can also include credentials necessary to verify client identity. Finally, there are tables that provide a means for dynamically binding sessions to a set of policies. This section describes the approach taken for supporting each of these structures. 2.1 Accessor Concepts This section introduces the concepts of an Accessor and Sessions associated with an Accessor. Much of what is described in this paper is based on the Accessors, the sessions that Accessors create, and the way Accessors match data with sessions, creating new sessions when there is no match. Weiss et al. Expires October 2000 [Page 6] Internet Draft Binding Authentication to Provisioning July 2001 Accessors are implemented in PEPs and configured by PDPs. Accessors are provisioned by standard COPS-PR protocol sequences. A PEP will announce what Accessors are available in the capabilities table of the COPS-PR Request message. The PDP will provision the Accessors with Decision messages. Once an Accessor is provisioned it is responsible for identifying packets that should be treated as a session, generating access requests to authorize the session when it detects the first packet of a session, and then applying a specific policy for all packets in a session. The general model for access requests includes a client, a Policy Enforcement Point (PEP) and a Policy Decision Point (PDP). In this model, the PEP is the interface to the client, and the Accessor is the part of the PEP that is responsible for recognizing the conditions for client authorization, forwarding the Request to the PDP, and communicating with the Client, if necessary, to get identity or other information. The Accessor takes a signal or message from the client and translates it into an Access Request to send to the PDP. It takes the Access Decision from the PDP and, in cases where the client is aware of the authorization process, does what is needed to communicate the Decision to the client. The access request is sent from the PEP to the PDP. The PDP attempts to authorize the request (which may require sending some intermediate messages to authenticate the client), and then returns an access Decision for the session. The PEP then returns a Report to the PDP confirming what was provisioned by the Decision. | C |->Access Request->| | | | | L | | |-Access Notification->| | | I | <-(optional)-> |PEP | <-(optional)-> |PDP | | E | | |<-Access Decision ----| | | N |<-Access Decision-| | | | |__T_| |____| --> Access Report -->|____| Fig. 2.1 Access Control Protocol Sequence This paper is primarily concerned with the function of the Accessor and the communication between the PEP and PDP. Communication between the Client and PEP is assumed to be something like PPP or 802.1, and the capabilities described here should work with any Client/PEP communication method. The PEP Access Request and PDP Access Response sequence is similar to the ôclassicalö COPS RSVP model. The Report confirming that the Decision was installed correctly on the PEP is an extra message Weiss et al. Expires October 2000 [Page 7] Internet Draft Binding Authentication to Provisioning July 2001 beyond what is included in the RSVP sequence. We believe this is a good approach, but expect further discussion (It is interesting to note that RADIUS does not send an acknowledgements of Access Accepts/Rejects, and the DIAMETER drafts specify no acknowledgement, but do expect a negative message if the Reply cannot be processed correctly). An Accessor is a data path element in the PEP. Each Accessor has a ôselectorö that identifies packets that should be assigned by the accessor to a session (See section 4.3 û Filter Entries). The selector essentially divides all packets into two sets, one set the Accessor is responsible for assigning to a session; the other set it just passes to the next data path element. For example, if an AccessorÆs selector is Destination TCP Port = 80, an incoming packetÆs Destination port is examined and if Destination Port is not 80, the packet passed on without further processing. If the Destination Port is 80, each packet is associated with a ôsessionö and the session policy is applied to it. If a packet is the first of a session, the Accessor will initiate an Access Request to authorize and request provisioning for the new session. Every session has a ôsession criteriaö defining which packets are to be part of that session. (note: see section 4.3. The distinction between selector and session criteria is not well spelled out in 4.3, and will be worked on in the next revision of this draft). Each Accessor also has a ôsession matcherö that checks session criteria to determine if a packet is part of an existing session. There has been some discussion of what the session criteria should be. One possibility is that there would be a definition of scope by a set of attributes (e.g. every Source IP and Destination IP address combination) and that every unique element that is in the scope would be a session. The approach taken in this paper is that the scope is defined by Filter entries defined in the COPS Framework PIB [FWPIB]. For example, if a FilterEntry object specifies SRC IP address (10.20.0.0) and SRC IP Mask (FF.FF.0.0) each new IP address within the range 10.20.0.0 and 10.20.255.255 will trigger a new session. The session criterion is that all packets that have a unique value within the scope are assigned to the (unique) session associated with that unique value. (We expect discussion on how the scope is defined, especially for situations that involve signaling rather than inspecting packet headers) When a packet arrives, the Accessor first checks if it meets the general criteria for sessions it is managing. In the example above, a packet with a SRC IP address of 10.25.12.100 would not match the range criteria. If not selected, it is passed to the next data path element. If it is selected, then a check is made to see if it matches the criteria for an existing session. If it does match a session criteria, the policy for that session is applied. If it does not match the criteria for an existing session, then it instantiates a new session, marks the session as ôpendingö and sends Weiss et al. Expires October 2000 [Page 8] Internet Draft Binding Authentication to Provisioning July 2001 an Access Request to the PDP. The PDP authorizes the request, possibly sending additional messages to support authentication and provisioning for the session, then sends an Access Decision û either an ôEnableö (accept) or ôDisableö (reject) û to the PEP. The Access Decision may also contain other provisioning data piggybacked with the Access Decision. 2.1.1 Example - Ethernet IP Address Authorization This (relatively simple) example assumes an edge device has an Ethernet interface and wants to require each new Source IP address arriving at one Ethernet port to be authorized before getting general access to the network. Assume also that some clients are to get preferred access (via DiffServ Marking). In the example, the PEP is configured with two policies used by Accessor sessions to direct traffic from two sets of authorized IP addresses to an appropriate data path, one to the preferred queue, the other to the best effort queue. Packets from IP addresses not included in either set of authorized IP addresses are to be dropped. When the PEP comes up it sends information about its Accessors to the PDP in a capabilities table. The PDP returns an Accessor Provisioning Decision which instructs the PEP to install the Accessor behind the Ethernet interfaceÆs datapath, and AccessorSessionScope Tables. Each Accessor Table will have a pointer to a (tagged) set of AccessorSessionScope Tables that provide Selector and Session Matching setup information. In this case, the AccessorSessionScope table will contain a range of ôSourceIPAddresses.ö Once the Accessor is setup, packets arriving at the Ethernet Interface are processed by the Accessor. If the packet is not from EthernetPort 1, then it is passed immediately to the next data path element behind the Accessor. The Accessor looks at remaining packets and uses the session matching rules to check if the packet is part of an existing session. In this example packets from each unique Source IP address will be separate sessions. If the packet is not part of an existing session, the Accessor checks what information the PDP requires from the Client (e.g. username and credential), gets the information, instantiates a new (pending) session with this Source IP address, and sends an Access Request to the PDP. The PDP checks the packet, authenticates the client (if required), and decides which policy should apply to that IP address. It sends a Access Decision to the PEP including the Session Table with state set to ôEnabledö and a pointer to appropriate policy (e.g. best effort or preferred). Weiss et al. Expires October 2000 [Page 9] Internet Draft Binding Authentication to Provisioning July 2001 Future drafts will expand on this example and add other examples. Current plan is to add examples for dial access and QoS flow authorization. 2.2 Accessor Management Paradigm Figures 2.2 through 2.6 below show a number of diagrams representing a sequence of steps involved in the authorization, authentication and provisioning phase. The semantics of this are shown as layout of switches and Connections. Switches, Accessor and Policy components in a topology that describe certain traffic classifications represent access to Service capabilities enforced by the PEP. The following diagrams represent the semantic components within the PEP. Each (A) represents an Accessor. An Accessor is a logical component inside the PEP that can be created and/or configured during the PEP initialization phase or it gets instantiated as the result of an unsolicited Provision Decision from the PDP. An Accessor is configured to act on certain messages or interface events (as described in section 2.1). After matching a packet and determining that no session exists for it, the Accessor in the PEP will create a new session and assert the start of an authorization phase by sending an Access Request to the PDP (or AAA server). This authorization phase may include authentication as well. The configuration of an Accessor will include a list of the types of authentication methods (PAP/CHAP/ EAP/HTTP etc.) to be used. Each (S) within the topology represents an active unique session created by the PEP, replacing the Accessor symbol when the session is activated (as will be explained later). A single Accessor component is capable of creating multiple Session instances that each represent a unique session as represented in the subsequent example. The (P) symbols represent provisioned policies. Policies are created and/or made accessible or inaccessible in the PEP based on Provisioning Decisions from the PDP. Provisioning Decisions can be sent on request by the PEP or can be sent unsolicited by the PDP. Switches: closed or ON: --o---o--. \ open or OFF : --o \o-- In this example there are two kinds of switches: - Accessor Switches: --(An)---o-- A logical switch that is connected to the Accessor and can be seen as a kind of master switch that enables a group of Services at once. Under normal circumstances the switch remains open until an explicit access response is sent by the PDP. This allows the PDP to perform preemptive provisioning prior to providing closing the switch. Weiss et al. Expires October 2000 [Page 10] Internet Draft Binding Authentication to Provisioning July 2001 - A Policy Switch: --o---o--(Pn) Service/Resource (Pn) is a logical switch that represents a policy. The (Pn) open switch defines a policy that denies resources and a closed switch describes policies that enable services. The figures simplify policies to permit and deny. In practice a policy provisioned by the PDP can express QoS semantics, tunnel semantics, or even high level services such as telephony services. In figures 2.2 through 2.6, these services are represented as branches. The Accessor Switch can be explicitly operated by a response to the PEP Access Request. This response will hereafter be referred to as a ôPDP access responseö message. DISABLE Link \ ----(A1) \o-- Access Request Activity Fig 2.2: The PEP waits for traffic that initiates a PEP Access Request. Figure 2.2 shows the PEP Accessor A1 is waiting to receive an event that will initiate a PEP Access Request to the PDP. This Accessor (A1) can be configured by the PDP either at boot time or it could exist permanently in the non-volatile memory of the PEP after a one- time configuration of the PEP. For the purposes of this example, we will assume that Accessor (A1) has been instantiated a new Session due to link activity and a PEP Access Request message has been sent to the PDP. HTTP ENABLE |----------o---o---(P1) tunnel to content filter | | DISABLE |Non IP \ |----------o \o---(P2) drop | DISABLE |10.x.x.x ENABLE \ |----------o---o---(P3) tunnel corporate traffic ----(S1) \o--| |24.x.x.x \ |-------(A2) \o--- Access Request | |All other |traffic ENABLE |----------o---o---(P4) default QoS Fig 2.3: The PDP provisions policies P1, P2, P3 & P4 and Accessor A2. Weiss et al. Expires October 2000 [Page 11] Internet Draft Binding Authentication to Provisioning July 2001 The PEP Access Request generated by (A1) can be configured such that it sends specific information about the client including physical link characteristics, L2, L3 & tunnel information, as well as authentication credentials. For some authentication protocols there may be sufficient information to allow the PDP to authorize the access request. If additional information is required, a number of data structures are defined in the PIB to allow additional negotiation for either the authentication or the authorization to be completed. These structures are discussed in more detail in the next section. When the PDP is ready to grant access, it can choose to provision specific services for the session bound to the access request. These service policies can be dynamically bound to the session via the NextElement attribute in the Session table (discussed in detail in section 4.5). This attribute allows sessions, generated by PEP Access Requests, to be bound to other data path elements describing the necessary configuration to support additional service policies. The example in Figure 2.3 replaces the Accessor (A1) with Session (S1) to demonstrate that the policy bindings are at the session level rather than at the Accessor level. For simplicityÆs sake the Accessor is not shown in the figure. In this example the Session is followed by a classifier, and a set of QoS and tunneling services are defined to provide access to services defined with policies P1, P3 & P4, as well as explicit deny policy P2. The diagram shows that services such as tunnels for certain traffic types (P1/P3) and a default QoS treatment (P4) is enabled and that access of Non-IP traffic to the network is denied (P2). The PDP also provisions a new Accessor (A2) that will trigger the generation of a new PEP Access Request if/when traffic is destined for IP subnet 24.x.x.x. This ability to support multiple Accessors as well as a hierarchy of Accessors is a key capability of this model. There are many scenarios where multiple authorizations are required for the same client. Further any of these authorizations can require incremental authentication. Weiss et al. Expires October 2000 [Page 12] Internet Draft Binding Authentication to Provisioning July 2001 HTTP ENABLE |----------o---o---(P1) tunnel to content filter | | DISABLE |Non IP \ |----------o \o---(P2) drop | |10.x.x.x ENABLE ENABLE |----------o---o---(P3) tunnel corporate traffic ----(S1)--o--| | DISABLE |24.x.x.x \ |-------(A2) \o-- Access Request | |All other |traffic ENABLE |----------o---o---(P4) default QoS Fig 2.4: The PDP enables services by sending a PDP Access Response. Figure 2.4 above shows the state of the data path after the authorization has been completed. After any incremental data path provisioning performed by the PDP, the PDP sends an explicit response to the PEP Access Request. This response, referred to as the ôPDP Access Response,ö notifies the PEP that traffic is now allowed to pass through the session (S1) created with Accessor (A1). Once the Session is enabled, traffic can now proceed to the classifier that will forward traffic on to the specified policies (P1, P3 & P4) or cause a new PEP Access Request for (A2). Weiss et al. Expires October 2000 [Page 13] Internet Draft Binding Authentication to Provisioning July 2001 HTTP ENABLE |----------o---o---(P1) tunnel to content filter | | DISABLE |Non IP \ |----------o \o---(P2) drop | |10.x.x.x ENABLE ENABLE |----------o---o---(P3) tunnel corporate traffic ----(S1)--o--| | 24.20.x.x ENABLE | |----------o---o---(P5) high QoS | DISABLE | |24.x.x.x \ |24.1.x.x ENABLE |-------(S2) \o--|----------o---o---(P6) low QoS | | | | DISABLE | |TELNET \ | |----------o \o---(P7) drop |All other |traffic ENABLE |----------o---o---(P4) default QoS Fig 2.5: Accessor 2 triggers new PEP Access Request resulting in PDP Provision Decisions installing policies P5, P6, & P7. In figure 2.5, above, the second Accessor (A2) (shown as S2) has been triggered with a packet from the client to subnet 24.x.x.x resulting in a PEP Access Request and the creation of a new Session (S1) by the PEP. Figure 4 also demonstrates the PDPÆs ability to incrementally apply additional provisioning decisions. In the example, additional classification and provisioning components are provisioned behind the new session (S2) to apply more selective QoS to specific types of traffic via policies P5 and P6. Weiss et al. Expires October 2000 [Page 14] Internet Draft Binding Authentication to Provisioning July 2001 HTTP ENABLE |----------o---o---(P1) tunnel to content filter | | DISABLE |Non IP \ |----------o \o---(P2) drop | |10.x.x.x ENABLE ENABLE |----------o---o---(P3) tunnel corporate traffic ----(S1)--o--| | 10.20.x.x ENABLE | |----------o---o---(P5) high QoS | | | ENABLE |10.1.x.x ENABLE |-------(S2)--o--|----------o---o---(P6) low QoS | | | | DISABLE | |TELNET \ | |----------o \o---(P7) drop |All other |traffic ENABLE |----------o---o---(P4) default QoS Fig 2.6: The PEP receives PDP Access Response and enables S2. In figure 2.6, after all Provision Decisions have been reported successfully, the PDP will send a PDP Access Response that will enable access to all the services behind Session S2. Services and Accessors are provisioned and given a certain state either as a default during the first contact phase with the PDP or during the operational period as updates from the PDP driven by PEP Access Requests. Typically the default configurations are requested by the PEP at startup time and the PDP returns Provision Decisions based on the context data described in the Request. Provision Decisions may arrive at the PEP solicited (after the PEP sends a Provision Request) or unsolicited. Provision Decisions that are sent unsolicited to the PEP may create additional switches (services), enable or disable switches or it may remove a Service Switch or even an Accessor Switch. In addition, it is also possible for an existing, enabled Accessor Switch to be disabled dynamically. Provision Reports subsequently sent from the PEP to the PDP will confirm that a particular switch is created, has a certain status or is removed. A Provision Report does not always imply that the endpoint of a particular service is operational since PEP only controls the access to a particular service. After a particular client has been identified to the PDP, the PDP will decide which Services will be provisioned to this particular Weiss et al. Expires October 2000 [Page 15] Internet Draft Binding Authentication to Provisioning July 2001 client. There may be a set of Provision Decisions that must be ôReportedö as successfully installed to the PDP before the PDP sends a PDP Access Response to control all (or a set of) services. For example a certain set of security settings must be in place before the PEP is allowed to have the client send any packet to the network behind the PEP. A solicited or unsolicited Provision Decision may also create new Accessors as illustrated in Figures 2.2 through 2.6. Provisioning additional Accessors may be seen as an extension to the original access and provision sequence or may be seen as an independent event. A use case for multiple Accessors might be that the first Accessor causes a default service to be provisioned that only requires very basic authorization (e.g. based on source IP address) and that more elaborate authentication is only required when the client accesses web servers in a certain IP address range. For this reason, the second Accessor may be configured to trigger on any HTTP packet to a certain range of IP addresses or it could be configured to trigger on a specific HTTP GET request. The PDP may subsequently create a service switch to a specific IP address for port 80 marking the traffic for a High QoS. Additional Accessors may trigger PEP/PDP Access Request/Response sequences on behalf of different parties. This is part of the Accessor configuration provided by the PDP. The PDP may create Accessors without explicit knowledge of the client. As stated previously, in order for the PEP to generate a PEP Access Request, the PEP must be configured not only to generate the request under the proper circumstances, but also what physical interface and transport header information should be passed with the request. This configuration must also include the authentication rules that may be supported. The semantics of the PEP Access Request are discussed in detail in sections 5.1 and 6.1. 2.3. Context Data As mentioned previously, access requests frequently require information beyond just the identity of the client. Information about the physical interface, the protocols being used, and the protocol bindings (VLANs, IP addresses, etc.) may also be required to complete an access request. Therefore a mechanism is required that allows the PDP to specify what information is needed. With the advent of Tunnels, the same headers can be repeated (nested) within a single client message. This makes identification of specific attributes such as IP Addresses difficult because it is unclear whether the PDP needs the IP Address in the innermost or outermost header. This gets even more complicated when more than two layers are involved (i.e. VLAN and label stacking). The ContextData class, described in more detail below, allows the PDP to explicitly Weiss et al. Expires October 2000 [Page 16] Internet Draft Binding Authentication to Provisioning July 2001 specify the set of nested headers that it needs more details on. This can either be specified in from the outermost header or the innermost header, as well as all headers of a particular type. Since the volume of information can be quite large and is very PEP and interface specific, it is appropriate to organize the information into manageable chunks. This approach was a compromise between two extremes. One extreme is one large data structure with all possible information. The other extreme is specifying each attribute explicitly. The first extreme is not viable because it is difficult to adapt to new types of information. The second alternative is very configuration intensive, particularly for header data that must distinguish inner and outer headers. The choice to group context data into classes and request the data at the class level is not without problems. If the PDP is only interested in a single attribute within a given class, there is no way to specify this. Hence the PEP has to fill in the entire class and the PDP has to parse the entire class to find the appropriate attribute. In order for the PDP to specify which chunks of context data it needs, this PIB defines a table called the ContextData class that allows the PDP to specify the tables it needs. This table is discussed in more detail in section 4.4. The messages used to send ContextData are discussed in sections 5.1, 5.2, and 5.3. 2.4. Policy Distribution and Management One of the purposes of this memo is to demonstrate how authorization and authentication can be bound to traditional COPS provisioning. Stated somewhat differently, this memo provides the means for seamlessly integrating outsourcing with provisioning using only PIBs. Authorization, Authentication, and COPS/RSVP are all forms of outsourcing because they are all triggered by events in the PEP and depend on decision support from the PDP. Earlier sections have gone into a fair bit of detail in describing how the PEP can generate access requests. However, we have not yet discussed how these semantics integrate with traditional COPS PR provisioning semantics. There are two aspects to provisioning that need to be considered. First is the provisioning of the Accessors themselves. Section 2.1 went into some detail describing how Accessors are provisioned using policy decisions. More details on the Accessor tables can be found in sections 4.1, 4.2, and 4.3. In addition the provisioning messages used to configure Accessors are also described in section 5.1. The second aspect of provisioning is the use standard provisioning decisions to bind policies to authorized clients. The goal in binding sessions to policies was to minimize reconfiguration. Therefore, this PIB has been designed to configure Accessors as well as Policies once and bind them together dynamically. The process for this binding is as follows. An Accessor can be configured to generate sessions and trigger a PEP Access Requests Weiss et al. Expires October 2000 [Page 17] Internet Draft Binding Authentication to Provisioning July 2001 based on specific criteria. These criteria explicitly scope the session. For example, if the criteria were one per unique source IP address, then there would be one session for each unique source IP address and all policies bound to that session would operate on all traffic with that source IP address flowing into that Accessor. Note that the criteria that scope a session could also be a unique protocol, unique VLAN, or each unique RSVP RESV message. It is also worth noting that the session bounding criteria could also be a unique combination of field values such as a VLAN and TCP Port Number. With the scope of a session specified, the Accessor can instantiate new sessions in conjunction with the PEP Access Request. When the PDP authorizes a new session, it must bind specific policies to the session in order to specify how the session-specific traffic should be processed. If no specialized handling is required for the individual sessions, the sessions may all be lumped back into a single data path. Normally the next data path element will be a classifier that de-multiplexes specific or aggregate session traffic to the various service policies configured behind the classifier. As such an Accessor performs a sort of classification function that instantiates additional more specific policies, provisioned in the PEP. This can be viewed as a boot strapping process for handling session specific access control. 2.5. Interactions with DiffServ model The DiffServ model [MODEL] and PIB [DSPIB] allow for flexible addition of new Data Path Functional Elements. Accessor is one such new Data Path Functional Element. Previous sections have already described how this PIB extends the existing DiffServ Informal Model and the DiffServ PIB. However, it is worth describing how this PIB enhances the basic DiffServ model. First and foremost, this new PIB provides a means for scaling the basic DiffServ model to the edges of the network that can have many interfaces and many specialized services. Previous PIBs only supported the static configuration of data paths. This meant that dynamic events such as binding of new clients to existing or new services were difficult to support because there was no way to anticipate new clients and because most provisioning was managing classifiers on a per client per service basis did not scale well. This PIB addresses this problem by preserving the basic data path semantics but separating the creation of sessions into a new data path component. This provides a stable data path for the generation of sessions (and authorizations) while also supporting a stable data path for the services that various sessions may make use of. The linchpin of this PIB is the Accessor that provides a new form of a demultiplexor that separates streams of traffic into individually authorizable sessions. These sessions can in turn be bound to pre- configured services. Further, with this PIB, modifications to service policies can added or removed at the session level rather than the raw data path level. Weiss et al. Expires October 2000 [Page 18] Internet Draft Binding Authentication to Provisioning July 2001 So far we have only discussed the value of authorizing a session when the link notices new IP address. However, it is worth noting that because the Accessor is part of the data path definition, it is far more flexible. For instance, the Accessor can be placed behind a Classifier to explicitly authorize access to a specific part of the network or specific services. The Accessor can also be the FailNext element behind a meter resulting in an authorization for the use of out-of-profile traffic. Bandwidth Brokers could use this approach or an Accessor trapping RSVP RESV messages to support dynamic bandwidth allocation decisions. The integration of Accessor and Session as Data Path Functional Elements allows seamless integration with DiffServ provisioning. DiffServ network device mechanism policy control continues to be supported with the use of DiffServ PIB [DSPIB] with added functionality at the edge of the network with usage of Accessor and Session. Totally controlled via the use of COPS-PR. The Policy Server level interaction with DiffServ comes naturally with the integration of Accessor and Session as Data Path Functional Elements when the network data model is common and scoped appropriately in the schema level, with the Accessor becoming stimuli for DiffServ provisioning. 2.6. Interactions with RSVP model The Accessor model provides a means for detecting RSVP RESV messages. This means that the traditional COPS outsourcing model could eventually be phased out in favor of the provisioning model and the use of this PIB. Before this option is fully realized one issue will need to be addressed. Because RSVP uses the same message to create a reservation as it does to modify the reservation, new hooks will need to be supplied in the Accessor in order to detect modified reservations for existing sessions. 3. Supporting various client Authentication Protocols In the operational model for this PIB, the Authentication Server is a specific function of the PDP. The main purpose of an authentication portions of this PIB is to verify the validity of client credentials by an Authentiation Server. The verification process itself may do this whilst ensuring some level of authenticity, confidentiality and integrity. Messages exchanged between a Client and Authentication Server (PDP) may remain confidential to PEP's and Proxy Servers. The message integrity may be ensured by some hashing algorithm so PEP's and Proxy's may inspect but not modify the content of authentication messages. Clients, PEP's, Proxy's and PDP's will always need some security method to ensure message authenticity. Weiss et al. Expires October 2000 [Page 19] Internet Draft Binding Authentication to Provisioning July 2001 Some authentication protocols explicitly consider proxies by allowing the payload to be carried over a variety of transports. Others depend on the termination point of the connection to explicitly proxy the authentication, when that is necessary. In order to demonstrate the general utility of this model, a variety of client authentication protocols will be considered in this document. For each protocol, the negotiation mechanism will be described and the mapping to this framework will be detailed. 3.1. EAP Authentication The most significant aspect distinguishing EAP [EAP] from other authentication protocols is that EAP assumes the negotiation is between the client and the authentication server. In anticipation of the fact that the terminating point of a connection such as PPP or L2TP is not necessarily the same as the agent managing client authentication, EAP encapsulates itÆs negotiation process in a separate header that can be forwarded in entirety to the server. This mechanism provides extra security by preventing intermediate proxies from monitoring or managing authentication credentials. EAP supports a number of different authentication mechanisms including MD5, TLS, and One-Time-Password authentication. The terminology used in [EAP] differs from the terminology used in this document. In particular, the peer, as defined in section 1.2 of [EAP], is referred to as 'Client' in this document. Similar, the 'authenticator' is called a PEP in this document and 'back-end server' is called the Authentication Server function of the PDP (or just PDP) in this document. 3.1.1. EAP Message sequence The generic sequence of transmissions between the PEP and PDP has already been described in section 2. In particular, figure (reference to the figure on slide 3) gives an overview of the messages involved between the Client workstation, PEP and PDP. EAP messages are embedded in PPP packets in the communication between the Client and the PEP. In the communication between the PEP and PDP, the EAP messages are embedded in COPS Request, COPS Decision and COPS Report messages. Figure 3.1 shows how EAP may be used to retrieve credentials from the client workstation by the PDP. Weiss et al. Expires October 2000 [Page 20] Internet Draft Binding Authentication to Provisioning July 2001 time | +---+ +---+ +---+ | | | | |<- COPS-Dec Accessor -----| | | | |-- PPP traffic ----->| | | | | | |<- PPP LCP Req-EAP --| | | | | | U |-- PPP LCP ACK-EAP ->| P | | P | | | s |<- PPP EAP Req Id ---| E | | D | | | e |-- PPP EAP Res Id -->| P | | P | | | r | | |-- COPS-Req Ses-EAP ---->| | | | | | |<- COPS-Dec EAP Dec Chal -| | | | |<- PPP EAP Req Chal -| | | | | | |- PPP EAP Res Chal ->| | | | | | | | |- COPS-Rep EAP Rep Chal ->| | | | | | | | | | | | | |<- COPS-Dec Ses-Enable----| | | | |<- PPP EAP succes ---| | | | V +---+ +---+ +---+ Fig 3.1: Embedding of EAP messages between the Client workstation and the PEP, and between the PEP and PDP. The EAP messages may be opaque to the PEP. Typically, when the PEP boots up, it is configured with one or more Accessor decisions specifying the criteria for generating an PEP Access Request. The first message from the PEP to the PDP is a request to initiate a new Session. The PEP sends a COPS request to the PDP containing a new instance of the Session table. The sessionAccessor attribute in the Session table entry is a ReferenceId that points to an AccessorTable entry indicating that EAP is a valid protocol to use in this Session. When the Accessor has been configured to require authentication, a PEP session request will not be generated until after a minimal set of credentials have been negotiated with the client. For EAP, this means that a PEP Access Request will not be generated until after the sessionRealm and sessionUsername have been determined. This means that that the PEP must receive an EAP Identity Response message before it can send the PEP Access Request. Session table attribute Attribute type ------- ------- sessionId InstanceId sessionStatus INTEGER sessionRealm OCTET STRING sessionUsername OCTET STRING sessionDataPath Prid sessionBinding ReferenceId sessionAccessor ReferenceId Figure 3.2: Data elements of the Session datastructure. Weiss et al. Expires October 2000 [Page 21] Internet Draft Binding Authentication to Provisioning July 2001 All EAP messages necessary to complete the authentication process will be forwarded to the PDP. With the exception of EAP Identity messages, the negotiation occurs between the Client and the PDP. In order to support multiple EAP protocols, this PIB supports a generic EAP request class and EAP response class. Each class has a single string attribute (authEapReqExtSpecific and authEapRespExtSpecific, respectively) within which the entire EAP message is passed. Although figure 3.1 shows two EAP messages going from the PDP to the Client and two EAP messages being returned from the client to the PDP, the actual number of messages exchanged can be any amount. The PDP may continue to retrieve additional credentials from the client for as long as it wishes. As soon as the PDP has all the necessary credentials from the client, the PDP may continue to provision the PEP with policies. This is action is not shown in figure 3.1. The PDP should not end the EAP negotiation with an EAP Success or an EAP Failure message. Instead, it must send a PDP Access Response, which takes the form of a COPS Decision. The PDP Access Response contains the instance of the SessionTable with the SessionStatus set to either ENABLED or DISABLED. The PEP must upon receipt of this COPS Decision message, send an EAP Success or EAP Failure to the Client Workstation. 3.1.2. AuthEapReXXExt data structures The EAP messages are embedded in COPS by sending an instance of the authEapReqExt or authEapRespExt table, which each have an attribute (Specific) to encapsulate the appropriate EAP messages necessary for the authentication mechanism. The authEapReqExt table is owned and managed by the PEP, while the authEapReqExt table is owned and managed by the PDP. Put another way, the PDP generates authEapReqExt instances that it sends in Decision messages and the PEP generates authEapRespExt instances that it sends in Report messages. Since neither the PEP nor the PDP needs to maintain the messages permanently, the same instance of each class is used when more than one exchange is required in each direction. AuthEapReXXExt table attributes Attribute type --------------- ------- authExtId InstanceId authExtSession ReferenceId authEapReXXExtSpecific OCTET STRING Fig 3.3: Data elements in AuthEapReqExt and AuthEapRespExt tables The AuthEapReXXExt class contains three attributes. The instanceId is used to uniquely define the instance in the table. However, since EAP messages are meant to be opaque, they should not be referenced. Because the purpose of the classes is to carry EAP messages and each Weiss et al. Expires October 2000 [Page 22] Internet Draft Binding Authentication to Provisioning July 2001 message is transient instances of these tables are temporary and should not be referred to. The Session attribute points to the Session table entry for which EAP is being negotiated. The format of EAP packages being passed by the AuthEapReXXExt classes is described in [EAP]. 3.2. PAP Authentication PAP (Password Authentication Protocol), as described in section 2 of [AUTH] is a very simple authentication mechanism used over PPP. It is not considered to be a strong security mechanism, since it sends passwords over the wire in clear text format. However, where one- time passwords are used, this security concern is mitigated. It is described here nonetheless for illustration purposes and because it may still be used among ISPs, or in situations where another layer already performs encryption for security. The terminology used in [AUTH] differs from the terminology used in this document. In particular, the peer as defined in section 1.2 of [AUTH] is referred to as 'Client' in this document. Similar, the 'authenticator' is called PEP in this document. 3.2.1. PAP Connection sequence Figure 3.4 shows how PAP may be used to retrieve credentials from the client workstation by the PDP. time | +---+ +---+ +---+ | | | | |<- COPS-Dec Accessor -----| | | | |-- PPP traffic ----->| | | | | | |<- PPP LCP Req-PAP --| | | | | | U |-- PPP LCP ACK-PAP ->| P | | P | | | s |-- PPP PAP Id, Pwd ->| E | | D | | | e | | P |-- COPS-Req Ses-PAP ----->| P | | | r | | | | | | | | | |<- COPS-Dec Ses-Enable ---| | | | |<- PPP PAP ack ------| | | | V +---+ +---+ +---+ Fig 3.4: Embedding of PAP messages between the Client workstation and the PEP, and between the PEP and PDP. The Client will send the Identity and Password to the PEP. The PEP will embed the password into an AuthPapExtEntry datastructure and send this to the PDP. In addition, the PAP identity attribute will be inserted into the sessionUsername attribute of the Session entry. The first connection from the PEP to the PDP is a request to initiate a new Session. The PEP sends a PEP Access Request to the PDP containing a new instance of the SessionTable. The Weiss et al. Expires October 2000 [Page 23] Internet Draft Binding Authentication to Provisioning July 2001 sessionAccessor attribute in the Session table entry is a ReferenceId that points to an AccessorTable entry indicating that PAP is a valid protocol to use in this Session. Along with this new instance of the Session table, the PEP must also send an instance of the AuthPapExt table. 3.2.2. AuthPapExtEntry datastructure The PAP information is embedded in the PEP Access Request by sending an instance of the authPapExt table. AuthPapExt table attributes Attribute type ---------------- --------- authExtId InstanceId authExtSession ReferenceId authPapExtPwd OCTET STRING Fig 3.5: Atributes of the AuthPapExt entry. The AuthPapExtEntry contains three attributes. The instanceId is used to uniquely define the instance in the table. However, since the PAP password is sent to the PDP once and is needed by neither the PDP nor the PEP after the client is authenticated, the instance should not be referenced after it is used the first time. The Session attribute points to the Session table entry for which PAP is being negotiated. The PDP performs the PAP authentication. When the authentication is complete and the PDP is ready to authorize the session, the PDP may optionally choose to provision the PEP with policies. This sequence of messages should terminate with a PDP Access Decision (a COPS-PR Decision message). The PDP Access Response contains the instance of the Session table with the SessionStatus set to either ENABLED or DISABLED. The PEP must upon receipt of this COPS Decision message, send PAP ACK or NACK message to the client. 3.3. CHAP Authentication CHAP (Challenge Authentication Protocol) [CHAP] is a strong authentication mechanism, which eliminates the need to send passwords in the clear, like PAP does. With CHAP, the Authenticator generates a challenge key, sends it to the Peer (Client) and the client responds with a cryptographically hashed response that depends upon the Challenge and a secret key. The PDP checks the secret key by performing the same encryption and comparing the results. The terminology used in [CHAP] differs from the terminology used in this document. In particular, the peer as defined in section 1.2 of [CHAP] is referred to as 'Client' in this document. Similar, the 'authenticator' is called PEP in this document. Weiss et al. Expires October 2000 [Page 24] Internet Draft Binding Authentication to Provisioning July 2001 3.3.1. CHAP Connection sequence Figure 3.6 shows how CHAP may be used to retrieve credentials from the client workstation by the PDP. time | +---+ +---+ +---+ | | | | |<- COPS-Dec Accessor -----| | | | |-- PPP traffic ----->| | | | | | |<- PPP LCP Req-CHAP -| | | | | | U |- PPP LCP ACK-CHAP ->| P | | P | | | s |<- PPP CHAP Chal ----| E | | D | | | e |-- PPP CHAP Ident, ->| P | | P | | | r |-- Id, Resp ->| | | | | | | | |-- COPS-Req Ses-CHAP ---->| | | | | | |-- COPS-Rep CHAP Resp, -->| | | | | | |-- Chal -->| | | | | | | | | | | | | |<- COPS-Dec Ses-Enable ---| | | | |<- PPP CHAP ack -----| | | | V +---+ +---+ +---+ Fig 3.6: Embedding of CHAP messages between the Client workstation and the PEP, and between the PEP and PDP. As soon as the PEP finished negotiating CHAP as the Authentication protocol, it generates a challenge itself, and sends this to the Client. The client will respond to this authentication request by sending his or her identity, an identifier and the response. The response is a cryptographically encrypted hash based on the challenge and secret key (password). The identifier is only used to keep track of CHAP messages, and needs to be used by the PEP to recover the associated challenge. The first connection from the PEP to the PDP is a request to initiate a new Session. The PEP sends a PEP Access Request to the PDP containing a new instance of the SessionTable. The sessionAccessor attribute in the Session table entry is a ReferenceId that points to an AccessorTable entry indicating that CHAP is a valid protocol to use in this Session. Along with this new instance of the Session table, the PEP must also send an instance of the AuthChapExt table. Note that having the PEP issue the challenge allows the PEP to perpetrate fraud by issuing a replayed request (assuming that the PEP and PDP are in different domains). The only guard against this is for the PDP to check that multiple authentication requests for the same client have unique challenges. This may be slow. PDP and Authentication server developers that feel this is a security issue Weiss et al. Expires October 2000 [Page 25] Internet Draft Binding Authentication to Provisioning July 2001 may want to use EAP-MD5 authentication rather then CHAP authentication, since EAP-MD5 addresses this problem by letting the PDP generate the challenge. 3.3.2. AuthChapExtEntry datastructure The CHAP information is embedded in the PEP Access Request by sending an instance of the authChapExt table. AuthChapExt table attributes Attribute type ----------------- --------- authExtId InstanceId authExtSession ReferenceId authChapExtId Unsigned32 authChapExtChal OCTET STRING authChapExtResp OCTET STRING Fig 3.7: Data elements of the AuthChapExtEntry datastructure. The AuthChapExtEntry contains four attributes. The instanceId is used to uniquely define the instance in the table. However, since the CHAP information is sent to the PDP once and is needed by neither the PDP nor the PEP after the client is authenticated, the instance should not be referenced after it is used the first time. The Session attribute points to the Session table entry for which PAP is being negotiated. The challenge is the challenge generated by the PEP. The PDP may check the challenge to see if it is different from challenges used earlier. This to provides an increased level of security. The Response and the Id is taken from the CHAP message sent by the client and put into the AuthChapExtEntry by the PEP. The PDP performs the CHAP authentication. When the authentication is complete and the PDP is ready to authorize the session, the PDP may optionally choose to provision the PEP with policies for that session. This sequence of messages should terminate with a PDP Access Decision (a COPS-PR Decision message). The PDP Access Response contains the instance of the Session table with the SessionStatus set to either ENABLED or DISABLED. The PEP must upon receipt of this COPS Decision message, send CHAP ACK or NACK message to the client. 3.4. HTTP Authentication This section will be added in a subsequent version of this draft. Weiss et al. Expires October 2000 [Page 26] Internet Draft Binding Authentication to Provisioning July 2001 4. Data Structures The data classes defined formally in the Authentication PIB module (section 7) are introduced and discussed here. 4.1. Accessor class The Accessor class models the accessor component in the PEP discussed in section 2.1. An instance of this class, with the aid of the objects to which it points, identifies when the PEP should send an access (i.e. authorization) request to the PDP. As a result of this request, a new session may be started. Hence, the Accessor can be said to create or remove Session entries. The Accessor is installed on the PEP by the PDP and references a list of authentication protocols supported (AccessorAuthProtocol) and a list of interface and header class identifiers whose instances must be included in the PEP Access Request (the ContextData). The attributes of the Accessor Class are as follows: AccessorId (InstanceId) identifies an instance of this class AccessorRequestAuth (Boolean) True if authentication is required False if not. AccessorAccElmRef (ReferenceId) points to the AccessorElement object (sec. 4.2) for this Accessor AccessorAuthProtocol (TagReferenceId) references AccessorAuthProtocol objects (sec. 4.4). There may be several AccessorAuthProtocol objects with this TagReferenceId. Each specifies one authentication protocol that may be used for client authentication in order to satisfy the access request. AccessorAuthContext (TagReferenceId) references ContextData objects (sec. 4.5). There may be several ContextData objects with this TagReferenceId. Each specifies the PRI of one interface or header element class for which an object instance must be included in access requests triggered by this Accessor. This attribute must be assigned a valid TagReferenceId when the AccessorRequestAuth attribute is set to True. AccessorDefaultDataPath (PRID) (optional) points to the next data path element that will process out of scope traffic û that is not one of the following: 1. Traffic that is part of an established session. 2. Traffic matching a pending session (one for which the PEP Weiss et al. Expires October 2000 [Page 27] Internet Draft Binding Authentication to Provisioning July 2001 is waiting for an access response). 3. A packet that triggers the creation of a session. 4.2. AccessorElement class Generally speaking the purpose of the AccessorElement is to specify the characteristics of the Accessor. The attributes in the AccessorElement are there to provide maximal resuse by allowing multiple instances of an Accessor to reuse the same AccessorElement instance. AccessorElement object is referenced by an Accessor object. It specifies a list of one or more AccessorSessionScope objects, each of which defines a trigger for creating a Session object and generating an access request. It also specifies what to do with traffic for a newly created session while the PEP is awaiting a response to the access request. The attributes of the AccessorElement class are: AccessorElementId (InstanceId) identifies the object AccessorElementScope (TagReferenceId) references AccessorSessionScope objects (section 4.3). There may be one or more AccessorSessionScope objects, each of which specifies conditions for creating a Session and generating an access request. AccessorElementInterimFwdBehavior (Drop, Forward, Queue) specifies what to do with traffic for the newly created session while awaiting the response to the access request. Drop means to drop all packets received for this session until the PEP receives a PDP Access Response packet. Forward means forward interim traffic using the data path specified by the AccessorElementDefaultSessionDataPath attribute. Queue means to buffer interim traffic in a hold queue to be forwarded after access is granted by a PDP Access Response packet. This attribute provides for a great deal of flexibility regarding the treatment of interim traffic. For example, it may be blocked altogether, it may be passed, but be given best effort service, or it may be filtered to go only to a particular web server at which authentication will take place (see section 3.4) AccessorElementDefaultSessionDataPath (Prid) specifies the interim data path element that will process traffic for new sessions created by this accessor while awaiting an access response if the value of the AccessorElementInterimFwdBehavior attribute is Forward. This attribute also specifies the default data path element that will process traffic for this session if no other Weiss et al. Expires October 2000 [Page 28] Internet Draft Binding Authentication to Provisioning July 2001 element is configured by the PDP. The value of this attribute will be used to initialize the value of the SessionDataPath attribute of Session objects created by this accessor. The PDP may subsequently override the SessionDataPath attribute if it wishes with a PDP Access Reponse message (Section 5.4). 4.3. AccessorSessionScope class The AccessorSessionScope class determines the criteria for generating a new unique session. FilterEntries as defined in the framework PIB [FWPIB] allow for the specification of the set of header fields that scope each session. Whenever traffic arrives at the Accessor that is not part of an established session, it is compared against the FilterEntry objects of the AccessorSessionScope objects referenced by the AccessorElement. If it matches the criteria specified in all of the FilterEntry objects, a new Session object will be created and a PEP Access Request will be sent to the PDP. For example, if a FilterEntry object specifies SRC IP address (10.20.0.0) and SRC IP Mask (FF.FF.0.0) each new IP address within the range 10.20.0.0 and 10.20.255.255 will trigger a new session. Further after a session has been allocated for a specific SRC IP address like 10.20.15.109, all subsequent traffic will be forwarded from the Accessor to the data path assigned to the newly created session. When multiple fields are specified for the filter, each unique pairing of field values gets allocated a distinct session. For example, if the SRC IP was assigned a range of 10.10.10.224 to 10.10.10.255 and DST Ports 80 to 90 then 10.10.10.240+80, 10.10.10.240+81, and 10.10.10.250+80 would all be assigned separate sessions. The combination of supporting multiple filters and being able to control precedence allows for the construction of both lists (10.10.x.x and 10.15.x.x) and combinations of disjoint headers in a single match criteria (any combination of 10.10.x.x and VLANs 100 to 120). The attributes of this class are: AccessorSessionScopeId (InstanceId) identifies this object AccessorSessionScopeGroup (TagId) contains the tag by which the AccessorElement references this object. It is the means by which a list of filters can be associated with a Accessor AccessorSessionScopeFilter (PRID) points to a FilterEntry object (as defined in the Framework PIB) that specifies the filter for this AccessorSessionScope object Weiss et al. Expires October 2000 [Page 29] Internet Draft Binding Authentication to Provisioning July 2001 AccessorSessionScopePrecedence (Integer) specifies how multiple FilterEntry objects interact 4.4. AccessorAuthProtocol class The AccessorAuthProtocol class allows a PDP to configure the set of authentication protocols that are allowed for a given Accessor. The instances of this class are grouped together using the same TagId value, the reference to which are specified in the Accessor. The attributes of this class are: AccessorAuthProtocolId (InstanceId) identifies this object AccessorAuthProtocolGroup (TagId) contains the tag by which the Accessor references this object. AccessorAuthProtocolAuthMechanism (Enum) specifies an authentication mechanism to be used in access requests triggered by the Accessor referencing this AccessorAuthProtocol object. The value is from an enumerated list initially consisting of (PAP, CHAP, EAP-MD5, and EAP- TLS) 4.5. ContextData class The ContextData class defines the set of interface descriptions or packet header data that should be included in each PEP Access Request for sessions created by the reference Accessor. There may be multiple objects of this class referenced with a tag by an Accessor object. Note that the ContextData class can be part of either an Accessor Provisioning decision message (Section 5.1) or a Session-specific ContextData Request message (Section 5.5). The attributes of this class are: ContextDataId (InstanceId) identifies this object ContextDataGroup (TagId) contains the tag by which an Accessor object references objects of this class. This attribute may only be set for ContextData instances that will be bound to an Accessor. If the ContextData instance will be used in a Session-specific ContextData Request, this attribute must be left unspecified. Weiss et al. Expires October 2000 [Page 30] Internet Draft Binding Authentication to Provisioning July 2001 ContextDataSessionRef (ReferenceId) points to a Session object. This attribute may only be used for ContextData instances that will be used in a Session- specific ContextData Request. This attribute must be left unspecified for instances of ContextData instances bound to specific Accessors. ContextDataIfElement (PRC of interface elements) identifies an interface or header class identifier whoÆs class instance must be populated by the PEP and included in an access request or a Session-specific ContextData Request. ContextDataEncapsulation (Integer) distinguishes inner and outer headers of tunnels. For example, the PRC of a header element may specify that layer 3 header information should be sent. When there are tunnels, however, there will be header contents (with different IP addresses) for the outer header than for the inner header. A value of zero means return all layers of header. A negative n means return the nth layer from the innermost header. A positive n means return the nth layer from the outermost header. In situations where the ContextData is explicitly bound to an Accessor table entry, the ContextDataGroup attribute (TagId) must be specified and the ContextDataSessionRef (ReferenceId) must be Null. When this class is used to get specific information for a session, the ContextDataSessionRef is used and the ContextDataGroup is Null. Under no circumstances may an instance of the ContextData class have both the ReferenceId and the TagId specified. For examples of classes that may be referenced by the ContextData class, see section 4.8. 4.6. Session class Each instance of the Session class represents a session on the PEP. The PEP creates an instance of this class and sends it in the PEP Access Request to the PDP. In the PDP Access Response, the PDP sends a success/fail decision back to the PEP. This decision contains the same instance of the Session class, with its SessionStatus field filled in to indicate the outcome of the authorization decision. Note that the owner of the Session Class is always the PEP and the PEP always assigns the Instance ID. Sessions may be linked to each other, meaning that a new session may be initiated within the context of an existing session. This possible dependency is reflected in the Session class. The attributes of the Session class are: SessionId (InstanceId) Weiss et al. Expires October 2000 [Page 31] Internet Draft Binding Authentication to Provisioning July 2001 identifies this object SessionStatus (Integer) set by the PDP. Indicates whether this access attempt is authorized (success) or unauthorized (fail) or whether an authorization decision is still pending. SessionRealm (Octet String) the realm field of the clientÆs Network Access Identifier [NAI]. SessionRealm tells the PDP in what administrative domain the client can be authenticated. This attribute is optional, but must be provided if the AccessorRequestAuth attribute of the Accessor object is set to true and the specific authentication protocol supports realms. SessionUsername (Octet String) the Username field of the clientÆs NAI [NAI]. The SessionUsername attribute identifies the client for which this Session is being created. SessionUsername is optional, but must be specified if the RequestAuthentication attribute of the Accessor is set to true. SessionDataPath (PRID) points to the first data path element to process traffic for this session. SessionDataPath is initialized by the PEP to the value of the AccessorElementDefaultSessionDataPath attribute of the AccessorElement object. The PDP may assign a different value before returning the Session object in the PDP Access Response message. SessionBinding (ReferenceId) If this is a daughter session of another session, the SessionBinding attribute points to the parent session. A hierarchy of sessions is useful where a client has already initiated a session but later wants to access a service for which further authorization is needed. An Accessor can be created by the PDP in the data path of the parent session to trigger when additional service is required. A daughter session is created that points back to the parent session. An access request message is sent by the PEP to the PDP to authorize the new service. Authentication may or may not be required to establish the daughter session. SessionAccessor (ReferenceId) points to the Accessor which created this Session 4.7. AuthExt class The AuthExt class contains authentication data passed between the PDP and the client such as challenges and responses. An instance of this class must be included with a Session class instance in a PEP Access Request when the AccessorRequestAuth attribute in thee Accessor managing the session is set to True. Weiss et al. Expires October 2000 [Page 32] Internet Draft Binding Authentication to Provisioning July 2001 The data in this class is passed between the PDP and the client with little or no involvement of the PEP except to forward it in the appropriate AuthExt class instance. The PEP is not meant to store AuthExt objects. As such, this class, along with all its extending classes, is meant to be 'transient'. Its instances are temporary and are deleted by the PEP after a certain time or event. The PDP, in its decisions, must not refer to instances of this class that are sent by the PEP in its requests. Likewise, the PEP must not refer to instances sent by the PDP. Also, since instances are deleted, it is possible for InstanceIds to be reused. The AuthExt class is extended for each authentication mechanism supported. As a base class, it is never instantiated. The attributes of this class are: AuthExtId (InstanceId) identifies this object AuthExtSession (ReferenceId) points to the Session for which this object contains authentication information 4.7.1. AuthEapReqExt class The AuthEapReqExt class extends the AuthExt class. It contains an EAP message. (See sec. 3.1.) Instances of this class are sent by the PDP to the PEP. The attributes that this class adds to the base class are: AuthEapReqExtSpecific (Octet String) an EAP message [EAP] passed from the PDP to the client via the PEP in a COPS-PR Decision message. 4.7.2. AuthEapRespExt class The AuthEapRespExt class extends the AuthExt class. It contains an EAP message. (See sec. 3.1.) Instances of this class are sent by the PEP to the PDP. The attributes that this class adds to the base class are: AuthEapRespExtSpecific (Octet String) an EAP message [EAP] passed from the client to the PDP via the PEP in a COPS-PR Report message. 4.7.3. AuthPapExt class The AuthPapExt class extends the AuthExt class. It contains the PAP Password. (See sec. 3.2.) Weiss et al. Expires October 2000 [Page 33] Internet Draft Binding Authentication to Provisioning July 2001 The attributes that this class adds to the base class are: AuthPapExtPwd (Octet String) a one-time password used to authenticate the client 4.7.4. AuthChapExt class The AuthChapExt class extends the AuthExt class. It contains the attributes of the CHAP protocol [CHAP]. (See section 3.3.) The attributes that this class adds to the base class are: AuthChapExtId (Unsigned32) The AuthChapExtId is generated by the PEP. The ID value is sent to the client. When the client endpoint (Peer) generates a CHAP response it includes the same ID, and the ID is then included in this attribute when it is sent to the PDP. AuthChapExtChal (Octet String) The AuthChapExtChal is generated by the PEP. The Challenge value is sent to the client, along with the ID. When the client generates a CHAP response containing the ID and Response (key), the Challenge associated with the ID is included in this attribute when it is sent to the PDP. AuthChapExtResp The Response is calculated by the client and forwarded by the PEP to the PDP. 4.8. ContextData classes This section contains examples of classes that might be referenced by the ContextData class as classes that must be included in the access request for various types of accessors. There are two kinds of ContextData classes depending on the type of PEP. Some PEPs receive traffic from many users over a shared port such as an Ethernet port. They recognize new users based on information in the headers of incoming packets. For them, the ContextData will come from packet headers. The L3HeaderData class is an example of this kind of ContextData class. Other PEPs receive traffic from one user per interface. For them, the context data will be information about the interface. The CtxtDialupInterfaceFramedProtocol class is an example of this kind of ContextData class. 4.8.1. CtxtL3Hdr class This class specifies level three header data. This class is used to inform the PDP of the details of the IP header that caused the PEP Access Request to be generated. Weiss et al. Expires October 2000 [Page 34] Internet Draft Binding Authentication to Provisioning July 2001 The attributes of this class are: CtxtL3HdrId (InstanceId) identifies this object CtxtL3HdrSrcAddrType (Enum) specifies the type of the packetÆs layer 3 source address CtxtL3HdrSrcAddr the packetÆs layer 3 source address CtxtL3HdrDstAddrType (Enum) specifies the type of the packetÆs layer 3 destination address CtxtL3HdrDstAddr the packetÆs layer 3 destination address CtxtL3HdrProtocol the packetÆs protocol field CtxtL3HdrSrcPort the packetÆs source port field CtxtL3HdrDstPort the packetÆs destination port field CtxtL3HdrDscp the packetÆs Type of Service (Diffserv Code Point)field CtxtL3HdrEcn (boolean) Indicates whether this packet is ECN capable (True) or not (False) CtxtL3HdrIpOpt IP Options CtxtL3HdrEncap The Encap allows the PEP to indicate where this header is in relation to other IP headers found in the packet (with tunnels). This value can be either positive or negative depending on how the Accessor (or the Session-specific Context Data request) was specified using negative or positive numbers. A negative n means return the nth layer from the innermost header. A positive n means return the nth layer from the outermost header. Weiss et al. Expires October 2000 [Page 35] Internet Draft Binding Authentication to Provisioning July 2001 4.8.2. Ctxt802Hdr class This class specifies IEEE 802.1 header data. This class is used to inform the PDP of the details of the 802 header that caused the PEP Access Request to be generated. The attributes of this class are: Ctxt802HdrId (InstanceId) identifies this object Ctxt802HdrSrcAddr the frameÆs source MAC address Ctxt802HdrDstAddr the frameÆs destination MAC address Ctxt802HdrProtocol the layer 2 frameÆs protocol field Ctxt802HdrPriority the layer 2 frameÆs priority field (only used if the frame is using the 802.q header extension) Ctxt802HdrVlan the layer 2 frameÆs VLAN field (only used if the frame is using the 802.q header extension) Ctxt802HdrEncap The Encap allows the PEP to indicate where this header is in relation to other IP headers found in the packet (with tunnels). This value can be either positive or negative depending on how the Accessor (or the Session-specific Context Data request) was specified using negative or positive numbers. A negative n means return the nth layer from the innermost header. A positive n means return the nth layer from the outermost header. 4.8.3. CtxtDialupInterface class The CtxtDialupInterface class specifies data to be included in access requests sent by accessors providing dialin services. The attributes of this class are: CtxtDialupInterfaceId identifies this object CtxtDialupInterfaceNASPort This attribute indicates the physical port number of Weiss et al. Expires October 2000 [Page 36] Internet Draft Binding Authentication to Provisioning July 2001 the NAS which is authenticating the user. Note that this is using 'port' in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number. Either CtxtDialupInterfaceNasPort or CtxtDialupInterfaceNasPortType or both SHOULD be specified in a CtxtDialupInterface object, if the NAS differentiates among its ports. CtxtDialupInterfaceNASPortId This attribute contains a text string which identifies the port of the NAS which is authenticating the user. Note that this is using 'port' in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number. Either CtxtDialupInterfaceNasPort or CtxtDialupInterfaceNasPortId SHOULD be specified in a CtxtDialupInterface object, if the NAS differentiates among its ports. CtxtDialupInterfaceNasPortId is intended for use by NASes which cannot conveniently number their ports. CtxtDialupInterfaceNASPortType (Enum) This attribute indicates the type of the physical port of the NAS which is authenticating the user. It can be used instead of or in addition to the CtxtDialupInterfaceNasPort attribute. CtxtDialupInterfaceCalledStationId This attribute allows the NAS to send the phone number that the user called, using Dialed Number Identification (DNIS) or similar technology. Note that this may be different from the phone number the call comes in on. CtxtDialupInterfaceCallingStationId This attribute allows the NAS to send the phone number that the call came from, using Automatic Number Identification (ANI) or similar technology. CtxtDialupInterfaceConnectInfo This attribute is sent from the NAS to indicate the nature of the user's connection. This is a notify-only class. These attributes are not write-able by the PDP. Three additional notify/install classes can be defined. These classes can be included in an access request as information to the PDP. The PDP may change the values of these attributes, however, in subsequent provisioning messages. 4.8.3.1 CtxtDialupIfFramedProtocol class The CtxtDialupIfFramedProtocol class is an optional class that may be sent if a framed protocol is being used. Weiss et al. Expires October 2000 [Page 37] Internet Draft Binding Authentication to Provisioning July 2001 The attributes of this class are: CtxtDialupIfFramedProtocolId identifies this object CtxtDialupIfFramedProtocolProt This attribute indicates the framing to be used for framed access. CtxtDialupIfFramedProtocolMTU This attribute indicates the Maximum Transmission Unit to be configured for the user, when it is not negotiated by some other means (such as PPP). It MAY be used in access response packets. It MAY be used in an access request packet as a hint by the NAS to the PDP that it would prefer that value, but the PDP is not required to honor the hint. CtxtDialupIfFramedProtocolCompression (Enum) This attribute indicates a compression protocol to be used for the link. It MAY be used in access response packets. It MAY be used in an access request packet as a hint to the PDP that the NAS would prefer to use that compression, but the PDP is not required to honor the hint. CtxtDialupIfFramedProtocolPortLimit This attribute sets the maximum number of ports to be provided to the user by the NAS. This Attribute MAY be sent by the PDP to the PEP in an access response packet. It is intended for use in conjunction with Multilink PPP or similar uses. It MAY also be sent by the NAS to the PDP as a hint that that many ports are desired for use, but the PDP is not required to honor the hint. CtxtDialupIfFramedProtocolIpAddress This attribute indicates the address to be configured for the user. It MAY be used in access response packets. It MAY be used in an access request packet as a hint by the NAS to the PDP that it would prefer that address, but the PDP is not required to honor the hint. CtxtDialupIfFramedProtocolIpNetmask This attribute indicates the IP netmask to be configured for the user when the user is a router to a network. It MAY be used in access response packets. It MAY be used in an access request packet as a hint by the NAS to the PDP that it would prefer that netmask, but the PDP is not required to honor the hint. 4.8.3.2 CtxtDialupIfLoginService class The CtxtDialupIfLoginService class is an optional class that may be sent if a Login service is being provided. Weiss et al. Expires October 2000 [Page 38] Internet Draft Binding Authentication to Provisioning July 2001 This class contains a single attribute: CtxtDialupIfLoginIpHost This attribute indicates the system with which to connect he user. It MAY be used in access response packets. It MAY be used in an access request packet as a hint to the PDP that the NAS would prefer to use that host, but the PDP is not required to honor the hint. 4.8.3.3 CtxtDialupIfLoginLat class The CtxtDialupIfLoginLat class extends the CtxtDialupInterfaceLoginService class. Its attributes are: CtxtDialupIfLoginLatService This attribute indicates the system with which the user is to be connected by LAT. It MAY be used in access response packets. It MAY be used in an access request packet as a hint to the PDP, but the PDP is not required to honor the hint. CtxtDialupIfLoginLatNode This attribute indicates the Node with which the user is to be automatically connected by LAT. It MAY be used in access response packets. It MAY be used in an access Request packet as a hint to the PDP, but the PDP is not required to honor the hint. CtxtDialupIfLoginLatGroup This attribute contains a string identifying the LAT group codes which this user is authorized to use. It MAY be used in access response packets. It MAY be used in an access request packet as a hint to the PDP, but the PDP is not required to honor the hint. LAT supports 256 different group codes, which LAT uses as a form of access rights. LAT encodes the group codes as a 256 bit bitmap. Administrators can assign one or more of the group code bits at the LAT service provider; it will only accept LAT connections that have these group codes set in the bit map. The administrators assign a bitmap of authorized group codes to each user; LAT gets these from the operating system, and uses these in its requests to the service providers. CtxtDialupIfLoginLatPort This attribute indicates the Port with which the user is to be connected by LAT. It MAY be used in access response packets. It MAY be used in an access request packet as a hint to the PDP, but the PDP is not required to honor the hint. Weiss et al. Expires October 2000 [Page 39] Internet Draft Binding Authentication to Provisioning July 2001 5. Message Types All PIB messages have some form of transactional semantics. Most all transactions consist of requests and responses. Typical provisioning PIBs have the PDP requesting a provisioning decision to the PEP and the PEP responding with a success or fail. This PIB uses this paradigm in some cases, but it also uses a paradigm where the PEP initiates a request and the PDP responds with a success or fail. The specific use of this paradigm is with the PEP Access Request message, which is triggered by a PEP event and requires a success or fail response. This section discusses both paradigms and how the various classes defined in Section 4 are combined to form the various message interactions described in sections 2 and 3. Each message description in this section will include the purpose of the message, the COPS-PR message type, the direction of the message, the class instances typically found in the message and the request/response message it is peered with. 5.1. Accessor Provisioning Decisions The Accessor Provisioning Decision message is a COPS-PR Decision message used by the PDP to provision each Accessor in the PEP. It is likely to be a piece of a larger Decision message that provisions other data path components that occur either before or after the Accessor in the data path. However, it could also be sent as a part of unrelated data path or other provisioning components. Accessor provisioning typically includes the Accessor class, and the AccessorElement class, an optional set of AccessorContextData class instances, a optional set of AccessorAuthProtocol class instances, and an instance of the AccessorSessionScope class. Because the AccessorElement, AccessorContextData, AccessorAuthProtocol, and the AccessorSessionScope classes all describe configuration details of the Accessor, any of these class instances may be shared by multiple Accessor instances. Therefore, in many cases, an Accessor Provisioning Decision will contain only an Accessor that references instances of the other classes defined in previous Provisioning Decisions. In addition, these classes can also be provisioned individually in anticipation of being applied to an Accessor. However, because there is a relationship between the classes, there is an order dependency between the classes. For instance, an AccessorSessionScope must be provisioned at the same time or before an AccessorElement making use of the AccessorSessionScope. AccessorElement, AccessorAuthProtocol, AccessorContextData, and data path class instances referenced by an Accessor must be provisioned at the same time or before the Accessor is provisioned. When the PEP receives an AccessorProvisioning Decision must always respond with a Provisioning Report indicating success or failure. Weiss et al. Expires October 2000 [Page 40] Internet Draft Binding Authentication to Provisioning July 2001 5.2. Provisioning Report A report must follow all provisioning decisions described in section 5.1. This report may not have any class instances in it. However, it explicitly notifies the PDP that the provisioning was successful or whether it failed. If many structures were simultaneously provisioned in the Provisioning Decision and a failure occurred, none of the class instances will be accepted by the PEP. Hence it is possible to subsequent Provisioning Decisions to occur with a smaller subset of the class instances or an alternative set of class instances that can satisfy the service policies defined in the PDP. 5.3. PEP Access Request A PEP Access Request is generated by the PEP to indicate that a new class of traffic has been identified by the Accessor and that a new Session has been allocated. The PEP Access Request message uses a COPS-PR Request message. The PEP Access Request will always include an instance of the Session class. In order to support multiple PEP Access Request messages in a single COPS Request message, all class instances associated with the Session must immediately follow the Session class instance. Classes that may be part of a PEP Access Request include one or more instances of Header and Interface data classes and no more than one instance of the AuthExt class. When authentication protocols such as PAP or CHAP are in use, the PIB assumes that the UserId, Challenge, and Password will all be determined by the PEP prior to generating the PEP Access Request. EAP is an exception to this rule because EAP assumes a direct negotiation between the Endpoint and the Authentication server. For EAP, it is assumed that the Endpoint generates a response to the EAP Identity Request message before the PEP sends the Access Request. This allows the PEP to fill in the Username and Realm in the Session table. However, for this scenario, it is also assumed that the PEP Access Request will include the EAP Identity Response in the authEapRespExtSpecific attribute of the AuthEapRespExtEntry class. Subsequent EAP negotiation prior to the final PDP Access Response message will be performed with the Opaque Decision and Opaque Report message types. 5.4. PDP Access Response When the PDP has all the necessary information to determine whether the session is authorized or not and it has completed any intermediate data path PRIs that the session may be dependent on, the PDP will generate a PDP Access Response message. The PDP Access Response message only contains the instance of the Session table passed in the PEP Access Request. The PDP is capable of modifying two attributes in the Session table PRI. One attribute is the sessionStatus, which the PDP MUST modify to indicate whether the Session is authorized or not. The second attribute is the sessionDataPath, which the PDP may modify to indicate what specific Weiss et al. Expires October 2000 [Page 41] Internet Draft Binding Authentication to Provisioning July 2001 packet processing should occur for all traffic matching the session criteria. The PEP is the only entity that knows when traffic is no longer flowing through a particular session (either because of a timer expiring or because of a physical link termination). Therefore lifetime of a Session table instance are always controlled by the PEP. The PDP may advise the PEP that the session is no longer valid. However, the ultimate dispensation of the Session table and the related tables are always determined by the PEP. The PDP can indicate that a Session may no longer have access to resources either by changing the sessionStatus attribute to ôDisabledö or by modifying the sessionDataPath to drop packets arriving for that session. Since setting the sessionStatus to ôDisabledö will result in all packets for the session being dropped, both alternatives achieve the same semantics. The PEP can ôDisableö the session simply by notifying the PDP that the Session instance is no longer valid. Since a COPS-PR Provisioning Decision is used send the PDP Access Response, the PEP must send a report back to the PDP to confirm that the Session is still valid and that there are no problems with the SessionDataPath change requested by the PDP. When a Session is removed all relating class instances may be removed as well. Typically these will include header and authentication table instances. Interface table instances may continue to be valid if multiple Sessions are sharing the same interface description. 5.5. Session-specific ContextData Request The AccessorContextData class can be used either during the configuration of the Accessor to specify what context data should be sent with each PEP Access Request or it can be used by the PDP to get additional context data for a session after it receives an Access Request for that session. In the latter case, the PDP may send a Session-specific ContextData Request to retrieve the specific information needed to either authorize a pending session or monitor an active session. Since each ContextData class only retrieves a specific subset of the information regarding a session, a single request message can contain multiple instances of the ContextData class, thereby supporting the retrieval of as much session-specific information as needed in a single message. The COPS-PR message type used for a Session-specific ContextData Request is a Provisioning Decision message. Further, when the ContextData class is sent in a Session-specific ContextData Request, the RefId attribute must contain a valid InstanceId for in the Session table (described in section 4.6). It does not matter what the current state of the Session table entry is. Since the TagId is only used when the ContextData class is configured with an Accessor, the TagId attribute should not be set when the class is used in a Session-specific ContextData Request. When the PEP receives a Weiss et al. Expires October 2000 [Page 42] Internet Draft Binding Authentication to Provisioning July 2001 Session-specific ContextData Request, it will send a Session- specific ContextData Response message back to the PDP. Session-specific ContextData Response will contain a set of Header and Interface data class instances. However, because these instances do not contain a Reference Id to the Session, we must rely on the COPS protocol to bind the request with the response. This precludes PDP from generating multiple Session-specific ContextData requests for different sessions in the same Decision message. 5.6. Session-specific ContextData Response The Session-specific ContextData Response message is used to report specific interface and/or packet header information back to the PDP. This message is implemented as a COPS-PR Report message. A Report message may include any number of Interface or Header table instances. However, because Reference Identifiers to the Session table are not specified in the header or interface data tables, a Report message may contain header and interface data for one and only one Session. 5.7. Opaque Decision An Opaque Decision message is used to send specialized authentication messages from the PDP to the PEP. Specifically, this type of COPS-PR Decision message is used to pass EAP request messages. The class used in this message is used to send authEapReqExt table instances. 5.8. Opaque Report An Opaque Report message is used to send specialized authentication messages from the PEP to the PDP. Specifically, this type of COPS-PR Report message is used to pass EAP response messages. The class used in this message is used to send authEapRespExt table instances. 6. Combining Data Structures in Messages In the most degenerate case, the PDP provisions the Accessor with no ContextData. In this case, the PEP will generate an Access Request message. The PDP will then perform a series of Session-specific ContextData Requests. In addition, if EAP authentication is required, a sequence of Opaque Decisions and Opaque Reports are also required. Finally, if new data paths need to be provisioned (including specialized Accessors), normal Provisioning Decision and Report messages must also be exchanged. In some environments, it is essential to complete the authorization process as quickly as possible. The way to accelerate this process is to combine as many messages into a single message as possible. This section describes which messages can be collapsed, and what the rules are for collapsing the messages. Weiss et al. Expires October 2000 [Page 43] Internet Draft Binding Authentication to Provisioning July 2001 6.1. Combining Access Request and Session-specific ContextData messages Previous sections have discussed at length how Accessors can be pre- provisioned to generate specific ContextData (Interface and Header data) with the PEP Access Request. When the choice of what context data is not dependent on the specific semantics of each session, pre-provisioned Accessors is the preferred approach. 6.2. Combining Access Response and Provisioning Decision messages What has not been discussed in any detail is how Provisioning Decisions can be pre-pended to PDP Access Response messages. In general the preferred approach is to pre-provision as much of the data path as possible. However, when this is not possible, the PDP Access Response message can be combined with the data path Provisioning Decisions that the Session table entry (actually, the sessionDataPath attribute) in the PDP Access Response is dependent on. When this occurs, it is important to note that all Provisioning Decisions must report back to the PDP whether the Decision was successfully installed. Since both the PDP Access Response message and the Provisioning Decision are in the same message (a Decision message), COPS-PR transactional semantics apply to the entire combined message. Therefore, if the Decision fails, the Session will remain in the ôPendingö state with the sessionDataPath attribute unaltered. Given that the sessionDataPath would probably be invalid if the Provisioning Decision failed, this is the appropriate behavior. 7. The AccessBind PIB Module ACCESSBIND-PIB PIB-DEFINITIONS ::= BEGIN IMPORTS Unsigned32, Integer32, MODULE-IDENTITY, MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib FROM COPS-PR-SPPI InstanceId, Prid FROM COPS-PR-SPPI-TC RoleCombination, PrcIdentifier FROM FRAMEWORK-ROLE-PIB InetAddress, InetAddressType FROM INET-ADDRESS-MIB TruthValue, PhysAddress FROM SNMPv2-TC; accessBindPib MODULE-IDENTITY SUBJECT-CATEGORIES { all } LAST-UPDATED "200107101600Z" ORGANIZATION "IETF RAP WG" CONTACT-INFO " Weiss et al. Expires October 2000 [Page 44] Internet Draft Binding Authentication to Provisioning July 2001 Walter Weiss Ellacoya Networks 7 Henry Clay Drive Merrimack, NH 03054 Phone: 603-879-7364 E-mail: wweiss@ellacoya.com " DESCRIPTION "A PIB module containing the set of classes to bind authorization and authentication to COPS Provisioning " ::= { pib xxx } -- xxx to be assigned by IANA -- -- The branch OIDs in the AccessBind PIB -- capabilityClasses OBJECT IDENTIFIER ::= { accessBindPib 1 } sessionClasses OBJECT IDENTIFIER ::= { accessBindPib 2 } accessorClasses OBJECT IDENTIFIER ::= { accessBindPib 3 } contextClasses OBJECT IDENTIFIER ::= { accessBindPib 4 } authClasses OBJECT IDENTIFIER ::= { accessBindPib 5 } -- -- Session Table -- sessionTable OBJECT-TYPE SYNTAX SEQUENCE OF SessionEntry PIB-ACCESS install-notify STATUS current DESCRIPTION "An instance of this class is created by the PEP and sent to the PDP. The PDP will fill in the sessionStatus field and send the instance back when sending a decision." ::= { sessionClasses 1 } sessionEntry OBJECT-TYPE SYNTAX SessionEntry STATUS current DESCRIPTION "An instance of the sessionTable PRC." PIB-INDEX { sessionId } UNIQUENESS { } ::= { sessionTable 1 } SessionEntry ::= SEQUENCE { Weiss et al. Expires October 2000 [Page 45] Internet Draft Binding Authentication to Provisioning July 2001 sessionId InstanceId, sessionStatus INTEGER, sessionRealm OCTET STRING, sessionUsername OCTET STRING, sessionDataPath Prid, sessionBinding ReferenceId, sessionAccessor ReferenceId } sessionId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An index to uniquely identify an instance of this provisioning class." ::= { sessionEntry 1 } sessionStatus OBJECT-TYPE SYNTAX INTEGER { Pending(0), Enabled(1), Disabled(2) } STATUS current DESCRIPTION "This attribute is set by the PDP. Set to true(1) if the PDP has authorized the session, else set to false(2)." ::= { sessionEntry 2 } sessionRealm OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "Realm name in which the client is requesting access (sometimes referred to as a domain name." ::= { sessionEntry 3 } sessionUsername OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "Unique user name to identify the client requesting access." ::= { sessionEntry 4 } sessionDataPath OBJECT-TYPE SYNTAX Prid STATUS current Weiss et al. Expires October 2000 [Page 46] Internet Draft Binding Authentication to Provisioning July 2001 DESCRIPTION "This attribute references the first functional data path element to process data flow for this session. It is first assigned by the PEP with the accessorElementDefaultSessionDataPath in the accessorElement and may optionally be reassigned by the PDP." ::= { sessionEntry 5 } sessionBinding OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES { sessionEntry } STATUS current DESCRIPTION "This attribute allows a PEP to indicate to the PDP that this session was generated downstream on the data path from a session for which an PEP has previously generated an authorization request. This allows the PDP to reference additional knowledge acquired from the previous session such as the credentials or interface data. " ::= { sessionEntry 6 } sessionAccessor OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES { accessorEntry } STATUS current DESCRIPTION "This attribute references the instance of the previously provisioned Accessor that resulted in this PEP Access Request." ::= { sessionEntry 7 } -- -- Accessor Table -- accessorTable OBJECT-TYPE SYNTAX SEQUENCE OF AccessorEntry PIB-ACCESS install STATUS current DESCRIPTION "The AccessorTable identifies when the PEP should send an access or authentication request to the PDP. As a result of this request, a new session may be started. Hence, the AccessorTable can be said to create or remove SessionTable entries. " Weiss et al. Expires October 2000 [Page 47] Internet Draft Binding Authentication to Provisioning July 2001 ::= { accessorClasses 1 } accessorEntry OBJECT-TYPE SYNTAX AccessorEntry STATUS current DESCRIPTION " An instance of this class defines the circumstances for generating an access request, and provides the means for specifying the contents of the PEP Access Request." PIB-INDEX { accessorId } UNIQUENESS { accessorRequestAuth, accessorAccElmRef, accessorAuthProtocol, accessorAuthContext, accessorDefaultDataPath } ::= { accessorTable 1} AccessorEntry::= SEQUENCE { accessorId InstanceId, accessorRequestAuth TruthValue, accessorAccElmRef ReferenceId, accessorAuthProtocol TagReferenceId, accessorAuthContext TagReferenceId, accessorDefaultDataPath Prid } accessorId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION " An arbitrary integer index that uniquely identifies an instance of the accessorTable class." ::= { accessorEntry 1} accessorRequestAuth OBJECT-TYPE SYNTAX TruthValue STATUS current DESCRIPTION "Indicates whether or not authentication is required for this session. TRUE indicates that authorization is required." ::= { accessorEntry 2} accessorAccElmRef OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES { accessorElementEntry } STATUS current DESCRIPTION "A reference to an AccessorElementTable instance which Weiss et al. Expires October 2000 [Page 48] Internet Draft Binding Authentication to Provisioning July 2001 determines the scope (criteria for generating a new request) and interim forwarding behavior." ::= { accessorEntry 3} accessorAuthProtocol OBJECT-TYPE SYNTAX TagReferenceId PIB-TAG { accessorAuthProtocolGroup } STATUS current DESCRIPTION "Identifies a list of accessorAuthProtocolTable entries associated with this accessor instance." ::= { accessorEntry 4} accessorAuthContext OBJECT-TYPE SYNTAX TagReferenceId PIB-TAG { contextDataGroup } STATUS current DESCRIPTION "Identifies a list of ContextDataTable entries associated with this accessor instance." ::= { accessorEntry 5} accessorDefaultDataPath OBJECT-TYPE SYNTAX Prid STATUS current DESCRIPTION "The data path for æout of scopeÆ traffic." ::= { accessorEntry 6} -- -- AccessorElement Table -- accessorElementTable OBJECT-TYPE SYNTAX SEQUENCE OF AccessorElementEntry PIB-ACCESS install STATUS current DESCRIPTION "This table defines the criteria to be used to generate an access request. It also defines the interim forwarding behavior pending a decision from the server." ::= { accessorClasses 2 } accessorElementEntry OBJECT-TYPE SYNTAX AccessorElementEntry STATUS current DESCRIPTION "An instance of this class defines request trigger criteria and interim forwarding behavior for packets." Weiss et al. Expires October 2000 [Page 49] Internet Draft Binding Authentication to Provisioning July 2001 PIB-INDEX { accessorElementId } UNIQUENESS { accessorElementScope } ::= { accessorElementTable 1} AccessorElementEntry::= SEQUENCE { accessorElementId InstanceId, accessorElementScope TagReferenceId, accessorElementInterimFwdBehavior INTEGER, accessorElementDefaultSessionDataPath Prid } accessorElementId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the accessorElementTable class." ::= { accessorElementEntry 1} accessorElementScope OBJECT-TYPE SYNTAX TagReferenceId PIB-TAG { accessorSessionScopeGroup } STATUS current DESCRIPTION "Identifies a list of AccessorSessionScopeTable instances associated with an instance of this class. This list defines the criteria for partitioning various portions of traffic into distinct sessions." ::= { accessorElementEntry 2} accessorElementInterimFwdBehavior OBJECT-TYPE SYNTAX INTEGER { DROP (0), FORWARD (1), QUEUE (2) } STATUS current DESCRIPTION "The forwarding behavior to use while awaiting a PDP Access Response message." ::= { accessorElementEntry 3} accessorElementDefaultSessionDataPath OBJECT-TYPE SYNTAX Prid STATUS current DESCRIPTION "The default data path for each session while waiting for a PDP Access Response message." Weiss et al. Expires October 2000 [Page 50] Internet Draft Binding Authentication to Provisioning July 2001 ::= { accessorElementEntry 4} -- -- AccessorSessionScope Table -- accessorSessionScopeTable OBJECT-TYPE SYNTAX SEQUENCE OF AccessorSessionScopeEntry PIB-ACCESS install STATUS current DESCRIPTION "This class defines the criteria to be used for partitioning various portions of traffic into distinct sessions." ::= { accessorClasses 3 } accessorSessionScopeEntry OBJECT-TYPE SYNTAX AccessorSessionScopeEntry STATUS current DESCRIPTION "An instance of this class defines an individual criterion to be used towards generating an access request." PIB-INDEX { accessorSessionScopeId } UNIQUENESS { accessorSessionScopeGroup, accessorSessionScopeScopeRef } ::= { accessorSessionScopeTable 1} AccessorSessionScopeEntry::= SEQUENCE { accessorSessionScopeId InstanceId, accessorSessionScopeGroup TagId, accessorSessionScopeFilter Prid, accessorSessionScopePrecedence INTEGER } accessorSessionScopeId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the accessorSessionScopeTable class." ::= { accessorSessionScopeEntry 1} accessorSessionScopeGroup OBJECT-TYPE SYNTAX TagId STATUS current DESCRIPTION "Represents the binding between the accessorElementTable and the accessorSessionScope entries. A group of Weiss et al. Expires October 2000 [Page 51] Internet Draft Binding Authentication to Provisioning July 2001 accessorSessionScope entries constitutes the criteria for partitioning various portions of traffic into distinct sessions." ::= { accessorSessionScopeEntry 2} accessorSessionScopeFilter OBJECT-TYPE SYNTAX Prid STATUS current DESCRIPTION "Pointer to a filter to be used as the criteria." ::= { accessorSessionScopeEntry 3} accessorSessionScopePrecedence OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Represents the precedence of this criterion with respect to other criteria within the same group. When the precedence is unique, the instance represents an alternative criteria (an ORing function). When the precedence for two or more instances of the accessorSessionScope class is the same, the attributes within all the instances are treated collectively as a single filter criteria." ::= { accessorSessionScopeEntry 4} -- -- AccessorAuthProtocol Table -- accessorAuthProtocolTable OBJECT-TYPE SYNTAX SEQUENCE OF AccessorAuthProtocolEntry PIB-ACCESS install STATUS current DESCRIPTION "This class lists the authentication protocols that can be used for an access request originating from a particular instance of the accessorTable." ::= { accessorClasses 4 } accessorAuthProtocolEntry OBJECT-TYPE SYNTAX AccessorAuthProtocolEntry STATUS current DESCRIPTION "An instance of this class describes an authentication protocol that may be used for an access request. Instances Weiss et al. Expires October 2000 [Page 52] Internet Draft Binding Authentication to Provisioning July 2001 of this class that share the same TagId value collectively constitute a list of authentication protocols that may be used for a given access request" PIB-INDEX { accessorAuthProtocolId } UNIQUENESS { accessorAuthProtocolGroup, accessorAuthProtocolAuthMechanism } ::= { accessorAuthProtocolTable 1} AccessorAuthProtocolEntry::= SEQUENCE { accessorAuthProtocolId InstanceId, accessorAuthProtocolGroup TagId, accessorAuthProtocolAuthMechanism INTEGER } accessorAuthProtocolId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the ContextDataTable class." ::= { accessorAuthProtocolEntry 1} accessorAuthProtocolGroup OBJECT-TYPE SYNTAX TagId STATUS current DESCRIPTION "Represents a binding between an accessorTable instance and a list of accessorAuthProtocolTable instances." ::= { accessorAuthProtocolEntry 2} accessorAuthProtocolAuthMechanism OBJECT-TYPE SYNTAX INTEGER { PAP (0), CHAP (1), EAP-MD5(2), EAP-TLS(3) } STATUS current DESCRIPTION "The authentication protocol that may be used for an access request." ::= { accessorAuthProtocolEntry 3} -- -- ContextData Table -- Weiss et al. Expires October 2000 [Page 53] Internet Draft Binding Authentication to Provisioning July 2001 contextDataTable OBJECT-TYPE SYNTAX SEQUENCE OF ContextDataEntry PIB-ACCESS install STATUS current DESCRIPTION "This class points to the context information to be included with an access request." ::= { contextClasses 1 } contextDataEntry OBJECT-TYPE SYNTAX ContextDataEntry STATUS current DESCRIPTION "An instance of this class contains the type description (COPS-PR OID) of the class which needs to be filled in by the PEP and included with a PEP access request." PIB-INDEX { contextDataId } UNIQUENESS { } ::= { contextDataTable 1} ContextDataEntry::= SEQUENCE { contextDataId InstanceId, contextDataGroup TagId, contextDataSessionRef ReferenceId, contextDataIfElement PrcIdentifier, contextDataEncapsulation INTEGER } contextDataId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An arbitrary integer index that uniquely identifies an instance of the contextDataTable class." ::= { contextDataEntry 1} contextDataGroup OBJECT-TYPE SYNTAX TagId STATUS current DESCRIPTION "Defines the grouping of contextData instances that are applicable to a given Accessor. This attribute MUST NOT be specified when the instance is used in Session-specific contextData Request message." ::= { contextDataEntry 2} contextDataSessionRef OBJECT-TYPE SYNTAX ReferenceId Weiss et al. Expires October 2000 [Page 54] Internet Draft Binding Authentication to Provisioning July 2001 PIB-REFERENCES { sessionEntry } STATUS current DESCRIPTION "This attribute is used to specify the Session for which the ContextData is being requested with a Session- specific ContextData Request. This attribute MUST NOT be specified when the instance of the ContextData class is used in an Accessor Provisioning Decision message." ::= { contextDataEntry 3} contextDataIfElement OBJECT-TYPE SYNTAX PrcIdentifier STATUS current DESCRIPTION "The OID of a class whose instance is to be included with the PEP access request or Session-specific ContextData Response." ::= { contextDataEntry 4} contextDataEncapsulation OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "This attribute allows one to distinguish between inner and outer headers when there are multiple encapsulated headers of the same type in a packet. A value of: 0 means all headers, positive number ænÆ means the ænÆth header starting from the outermost, negative number ænÆ means the ænÆth header starting from the innermost." ::= { contextDataEntry 5} -- -- Layer 3 Header Data PRC -- ctxtL3HdrTable OBJECT-TYPE SYNTAX SEQUENCE OF ctxtL3HdrEntry PIB-ACCESS notify STATUS current DESCRIPTION "An instance of this class is created by the PEP and sent to the PDP to provide the PDP with information it requested in the ContextData PRC. The PDP uses this PRC to make Authentication/Provisioning decisions." Weiss et al. Expires October 2000 [Page 55] Internet Draft Binding Authentication to Provisioning July 2001 ::= { contextClasses 2 } ctxtL3HdrEntry OBJECT-TYPE SYNTAX CtxtL3HdrEntry STATUS current DESCRIPTION "An instance of the ctxtL3HdrTable PRC." PIB-INDEX { ctxtL3HdrId } UNIQUENESS { } ::= { ctxtL3HdrTable 1 } CtxtL3HdrEntry::= SEQUENCE { ctxtL3HdrId InstanceId, ctxtL3HdrSrcAddrType InetAddressType, ctxtL3HdrSrcAddr InetAddress, ctxtL3HdrDstAddrType InetAddressType, ctxtL3HdrDstAddr InetAddress, ctxtL3HdrProtocol Unsigned32, ctxtL3HdrSrcPort Unsigned32, ctxtL3HdrDstPort Unsigned32, ctxtL3HdrDscp Unsigned32, ctxtL3HdrEcn TruthValue, ctxtL3HdrIpOpt TruthValue, ctxtL3HdrEncap Integer32 } ctxtL3HdrId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An index to uniquely identify an instance of this provisioning class." ::= { ctxtL3HdrEntry 1 } ctxtL3HdrSrcAddrType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION "The address type enumeration value [INETADDR] to specify the type of the packet's source L3 address)." ::= { ctxtL3HdrEntry 2 } ctxtL3HdrSrcAddr OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION " The packet's source L3 address." Weiss et al. Expires October 2000 [Page 56] Internet Draft Binding Authentication to Provisioning July 2001 ::= { ctxtL3HdrEntry 3 } ctxtL3HdrDstAddrType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION "The address type enumeration value [INETADDR] to specify the type of the packet's destination L3 address." ::= { ctxtL3HdrEntry 4 } ctxtL3HdrDstAddr OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "The packet's destination L3 address." ::= { ctxtL3HdrEntry 5 } ctxtL3HdrProtocol OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "The packet's protocol field." ::= { ctxtL3HdrEntry 6 } ctxtL3HdrSrcPort OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "This attribute binds an existing upstream session to this session instance." ::= { ctxtL3HdrEntry 7 } ctxtL3HdrDstPort OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "This attribute binds an existing upstream session to this session instance." ::= { ctxtL3HdrEntry 8 } ctxtL3HdrDscp OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "." Weiss et al. Expires October 2000 [Page 57] Internet Draft Binding Authentication to Provisioning July 2001 ::= { ctxtL3HdrEntry 9 } ctxtL3HdrEcn OBJECT-TYPE SYNTAX TruthValue STATUS current DESCRIPTION "PEP sets this attribute to true(1) if ECN capable." ::= { ctxtL3HdrEntry 10 } ctxtL3HdrIpOpt OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "IP Options field in the packet." ::= { ctxtL3HdrEntry 11 } ctxtL3HdrEncap OBJECT-TYPE SYNTAX Integer32 STATUS current DESCRIPTION "This attribute specifies which encapsulated header is being described. The sign on this value will be the same as the value specified in the ContextData instance that requested this header. If the original ContextData instance specified a ContextDataEncapsulation value of zero (meaning return all headers), then all instances of this attribute MUST be expressed as positive numbers. A value of: positive number ænÆ means the ænÆth header starting from the outermost, negative number ænÆ means the ænÆth header starting from the innermost." ::= { ctxtL3HdrEntry 12 } -- -- 802.1 Header Data PRC -- ctxt802HdrTable OBJECT-TYPE SYNTAX SEQUENCE OF Ctxt802HdrEntry PIB-ACCESS notify STATUS current DESCRIPTION "An instance of this class is created by the PEP and sent to the PDP to provide the PDP with information it requested in the ContextData PRC. The PDP uses Weiss et al. Expires October 2000 [Page 58] Internet Draft Binding Authentication to Provisioning July 2001 this PRC to make Authorization/Provisioning decisions." ::= { contextClasses 3 } ctxt802HdrEntry OBJECT-TYPE SYNTAX Ctxt802HdrEntry STATUS current DESCRIPTION "An instance of the ctxt802HdrTable PRC." PIB-INDEX { ctxt802HdrId } UNIQUENESS { } ::= { ctxt802HdrTable 1 } Ctxt802HdrEntry::= SEQUENCE { ctxt802HdrId InstanceId, ctxt802HdrSrcAddr PhysAddress, ctxt802HdrDstAddr PhysAddress, ctxt802HdrProtocol Unsigned32, ctxt802HdrPriority BITS, ctxt802HdrVlan Unsigned32, ctxt802HdrEncap Integer32 } ctxt802HdrId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An index to uniquely identify an instance of this provisioning class." ::= { ctxt802HdrEntry 1 } ctxt802HdrSrcAddr OBJECT-TYPE SYNTAX PhysAddress STATUS current DESCRIPTION " The packet's source MAC address." ::= { ctxt802HdrEntry 2 } ctxt802HdrDstAddr OBJECT-TYPE SYNTAX PhysAddress STATUS current DESCRIPTION "The packet's destination MAC address." ::= { ctxt802HdrEntry 3 } ctxt802HdrProtocol OBJECT-TYPE Weiss et al. Expires October 2000 [Page 59] Internet Draft Binding Authentication to Provisioning July 2001 SYNTAX Unsigned32 (0..'ffff'h) STATUS current DESCRIPTION "The L2 packet's protocol field." ::= { ctxt802HdrEntry 4 } ctxt802HdrPriority OBJECT-TYPE SYNTAX Unsigned32 (0..7) STATUS current DESCRIPTION "The L2 packet's priority field. This attribute is only valid for packets using the 802.1q header extension." ::= { ctxt802HdrEntry 5 } ctxt802HdrVlan OBJECT-TYPE SYNTAX Unsigned32 (1..4094) STATUS current DESCRIPTION "The L2 packet's VLAN field. This attribute is only valid for packets using the 802.1q header extension." ::= { ctxt802HdrEntry 6 } ctxt802HdrEncap OBJECT-TYPE SYNTAX Integer32 STATUS current DESCRIPTION "This attribute specifies which encapsulated header is being described. The sign on this value will be the same as the value specified in the ContextData instance that requested this header. If the original ContextData instance specified an ContextDataEncapsulation value of zero (meaning return all headers), then all instances of this attribute MUST be expressed as positive numbers. A value of: positive number ænÆ means the ænÆth header starting from the outermost, negative number ænÆ means the ænÆth header starting from the innermost." ::= { ctxt802HdrEntry 7 } -- -- CtxtDialupInterface Table -- ctxtDialupInterfaceTable OBJECT-TYPE Weiss et al. Expires October 2000 [Page 60] Internet Draft Binding Authentication to Provisioning July 2001 SYNTAX SEQUENCE OF CtxtDialupInterfaceEntry PIB-ACCESS notify STATUS current DESCRIPTION "." ::= { contextClasses 4 } ctxtDialupInterfaceEntry OBJECT-TYPE SYNTAX CtxtDialupInterfaceEntry STATUS current DESCRIPTION "Entry oid of the ctxtDialupInterfaceTable PRC." PIB-INDEX { ctxtDialupInterfaceId } UNIQUENESS { } ::= { ctxtDialupInterfaceTable 1 } CtxtDialupInterfaceEntry::= SEQUENCE { ctxtDialupInterfaceId InstanceId, ctxtDialupInterfaceNASPort Integer32, ctxtDialupInterfaceNASPortId OCTET STRING, ctxtDialupInterfaceNASPortType INTEGER, ctxtDialupInterfaceCalledStationId OCTET STRING, ctxtDialupInterfaceCallingStationId OCTET STRING, ctxtDialupInterfaceConnectInfo OCTET STRING } ctxtDialupInterfaceId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An index to uniquely identify an instance of this provisioning class." ::= { ctxtDialupInterfaceEntry 1 } ctxtDialupInterfaceNASPort OBJECT-TYPE SYNTAX Integer32 STATUS current DESCRIPTION "This Attribute indicates the physical port number of the NAS which is authenticating the user. It is only used in Access-Request packets. Note that this is using 'port' in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number." ::= { ctxtDialupInterfaceEntry 2 } ctxtDialupInterfaceNASPortId OBJECT-TYPE Weiss et al. Expires October 2000 [Page 61] Internet Draft Binding Authentication to Provisioning July 2001 SYNTAX OCTET STRING STATUS current DESCRIPTION "This Attribute contains a text string which identifies the port of the NAS which is authenticating the user. It is only used in Access-Request and Accounting-Request packets. Note that this is using 'port' in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number. " ::= { ctxtDialupInterfaceEntry 2 } ctxtDialupInterfaceNASPortType OBJECT-TYPE SYNTAX INTEGER { radAsync(0), radSync(1), radIsdnSync(2), radIsdnAsyncV120(3), radIsdnAsyncV110(4), radVirtual(5), radPIAFS(6), radHdlcClearChannel(7), radX25(8), radX75(9), radG3Fax(10), radSDSL(11), radAdslCAP(12), radAdslDMT(13), radIdsl(14), radEthernet(15), radXdsl(16), radCable(17), radWirelessOther(18), radWirelessIEEE80211(19) } STATUS current DESCRIPTION "This Attribute indicates the type of the physical port of the NAS which is authenticating the user. It can be used instead of or in addition to the radNasPort (5) attribute. It is only used in Access-Request packets. Either radNasPort (5) or radNasPortType or both SHOULD be present in an Access-Request packet, if the NAS differentiates among its ports. A value of 'radAsync(0)' indicates Async. A value of 'radSync(1)' indicates Sync. A value of 'radIsdnSync(2)' indicates ISDN Sync. A value of 'radIsdnAsyncV120(3)' indicates ISDN Async V.120. Weiss et al. Expires October 2000 [Page 62] Internet Draft Binding Authentication to Provisioning July 2001 A value of 'radIsdnAsyncV110(4)' indicates ISDN Async V.110. A value of 'radVirtual(5)' indicates Virtual. Virtual refers to a connection to the NAS via some transport protocol, instead of through a physical port. For example, if a user telnetted into a NAS to authenticate himself as an Outbound-User, the Access-Request might include radNasPortType = Virtual as a hint to the RADIUS server that the user was not on a physical port. A value of 'radPIAFS(6)' indicates PIAFS. PIAFS is a form of wireless ISDN commonly used in Japan, and stands for PHS (Personal Handyphone System) Internet Access Forum Standard (PIAFS). A value of 'radHdlcClearChannel(7)' indicates HDLC Clear Channel. A value of 'radX25(8)' indicates X.25. A value of 'radX75(9)' indicates X.75. A value of 'radG3Fax(10)' indicates G.3 Fax. A value of 'radSDSL(11)' indicates SDSL û Symmetric DSL. A value of 'radAdslCAP(12)' indicates ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase Modulation. A value of 'radAdslDMT(13)' indicates ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone. A value of 'radIdsl(14)' indicates IDSL û ISDN Digital Subscriber Line. A value of 'radEthernet(15)' indicates Ethernet. A value of 'radXdsl(16)' indicates xDSL - Digital Subscriber Line of unknown type. A value of 'radCable(17)' indicates Cable. A value of 'radWirelessOther(18)' indicates Wireless - Other. A value of 'radWirelessIEEE80211(19)' indicates Wireless - IEEE 802.11." ::= { ctxtDialupInterfaceEntry 2 } Weiss et al. Expires October 2000 [Page 63] Internet Draft Binding Authentication to Provisioning July 2001 ctxtDialupInterfaceCalledStationId OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "This Attribute allows the NAS to send in the Access- Request packet the phone number that the user called, using Dialed Number Identification (DNIS) or similar technology. Note that this may be different from the phone number the call comes in on. It is only used in Access-Request packets. " ::= { ctxtDialupInterfaceEntry 2 } ctxtDialupInterfaceConnectInfo OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "This Attribute allows the NAS to send in the Access- Request packet the phone number that the call came from, using Automatic Number Identification (ANI) or similar technology. It is only used in Access-Request packets." ::= { ctxtDialupInterfaceEntry 2 } --- --- CtxtDialupInterfaceFramedProtocol Table --- ctxtDialupIfFramedProtocolTable OBJECT-TYPE SYNTAX SEQUENCE OF CtxtDialupIfFramedProtocolEntry PIB-ACCESS notify STATUS current DESCRIPTION "." ::= { contextClasses 5 } ctxtDialupIfFramedProtocolEntry OBJECT-TYPE SYNTAX CtxtDialupIfFramedProtocolEntry STATUS current DESCRIPTION "Entry oid of the ctxtDialupIfFramedProtocolTable PRC." PIB-INDEX { ctxtDialupIfFramedProtocolId } UNIQUENESS { } ::= { ctxtDialupIfFramedProtocolTable 1 } CtxtDialupInterfaceEntry::= SEQUENCE { ctxtDialupIfFramedProtocolId InstanceId, ctxtDialupIfFramedProtocolProt INTEGER, Weiss et al. Expires October 2000 [Page 64] Internet Draft Binding Authentication to Provisioning July 2001 ctxtDialupIfFramedProtocolMTU Integer32, ctxtDialupIfFramedProtocolCompression INTEGER, ctxtDialupIfFramedProtocolPortLimit Unsigned32, ctxtDialupIfFramedProtocolIpAddress IpAddress, ctxtDialupIfFramedProtocolIpNetmask IpAddress } ctxtDialupIfFramedProtocolId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An index to uniquely identify an instance of this provisioning class." ::= { ctxtDialupIfFramedProtocolEntry 1 } ctxtDialupIfFramedProtocolProt OBJECT-TYPE SYNTAX INTEGER { radPPP(1), radSLIP(2), radARAP(3), radGandalf(4), radXylogics(5), radX75Synchronous(6) } STATUS current DESCRIPTION "This Attribute indicates the framing to be used for framed access. It MAY be used in both Access-Request and Access-Accept packets. A value of 'radPPP(1)' represents PPP. A value of 'radSLIP(2)' represents SLIP. A value of 'radARAP(3)' represents AppleTalk Remote Access Protocol (ARAP). A value of 'radGandalf(4)' represents Gandalf proprietary SingleLink/MultiLink protocol. A value of 'radXylogics(5)' represents Xylogics proprietary IPX/SLIP. A value of 'radX75Synchronous(6)' represents X.75 Synchronous." ::= { ctxtDialupIfFramedProtocolEntry 2 } ctxtDialupIfFramedProtocolMTU OBJECT-TYPE SYNTAX Integer32 Weiss et al. Expires October 2000 [Page 65] Internet Draft Binding Authentication to Provisioning July 2001 STATUS current DESCRIPTION "This Attribute indicates the Maximum Transmission Unit to be configured for the user, when it is not negotiated by some other means (such as PPP). It MAY be used in Access-Accept packets. It MAY be used in an Access- Request packet as a hint by the NAS to the server that it would prefer that value, but the server is not required to honor the hint." ::= { ctxtDialupIfFramedProtocolEntry 3 } ctxtDialupIfFramedProtocolCompression OBJECT-TYPE SYNTAX INTEGER { radNone(0), radVJ(1), radIPXheader(2), radStacLZS(3) } STATUS current DESCRIPTION "This Attribute indicates a compression protocol to be used for the link. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint to the server that the NAS would prefer to use that compression, but the server is not required to honor the hint. More than one compression protocol Attribute MAY be sent. It is the responsibility of the NAS to apply the proper compression protocol to appropriate link traffic. A value of 'radNone(0)' indicates None. A value of 'radVJ(1)' indicates VJ TCP/IP header compression. A value of 'radIPXheader(2)' indicates IPX header compression. A value of 'radStacLZS(3)' indicates Stac-LZS compression." ::= { ctxtDialupIfFramedProtocolEntry 4 } ctxtDialupIfFramedProtocolPortLimit OBJECT-TYPE SYNTAX Integer32 STATUS current DESCRIPTION "This Attribute sets the maximum number of ports to be provided to the user by the NAS. This Attribute MAY be sent by the server to the client in an Access-Accept Weiss et al. Expires October 2000 [Page 66] Internet Draft Binding Authentication to Provisioning July 2001 packet. It is intended for use in conjunction with Multilink PPP [10] or similar uses. It MAY also be sent by the NAS to the server as a hint that that many ports are desired for use, but the server is not required to honor the hint." ::= { ctxtDialupIfFramedProtocolEntry 5 } ctxtDialupIfFramedProtocolIpAddress OBJECT-TYPE SYNTAX IpAddress STATUS current DESCRIPTION "This Attribute indicates the address to be configured for the user. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that address, but the server is not required to honor the hint." ::= { ctxtDialupIfFramedProtocolEntry 6 } ctxtDialupIfFramedProtocolIpNetmask OBJECT-TYPE SYNTAX IpAddress STATUS current DESCRIPTION "This Attribute indicates the IP netmask to be configured for the user when the user is a router to a network. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that netmask, but the server is not required to honor the hint." ::= { ctxtDialupIfFramedProtocolEntry 7 } --- --- CtxtDialupIfLoginService Table --- ctxtDialupIfLoginServiceTable OBJECT-TYPE SYNTAX SEQUENCE OF CtxtDialupIfLoginServiceEntry PIB-ACCESS notify STATUS current DESCRIPTION "Base class." ::= { contextClasses 6 } ctxtDialupIfLoginServiceEntry OBJECT-TYPE SYNTAX CtxtDialupIfLoginServiceEntry STATUS current Weiss et al. Expires October 2000 [Page 67] Internet Draft Binding Authentication to Provisioning July 2001 DESCRIPTION "Entry oid of the ctxtDialupIfLoginServiceTable PRC." PIB-INDEX { ctxtDialupIfLoginServiceId } UNIQUENESS { } ::= { ctxtDialupIfLoginServiceTable 1 } CtxtDialupIfLoginServiceEntry::= SEQUENCE { ctxtDialupIfLoginServiceId InstanceId, ctxtDialupIfLoginIpHost IpAddress } ctxtDialupIfLoginServiceId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An index to uniquely identify an instance of this provisioning class." ::= { ctxtDialupIfLoginServiceEntry 1 } ctxtDialupIfLoginIpHost OBJECT-TYPE SYNTAX IpAddress STATUS current DESCRIPTION "." ::= { ctxtDialupIfLoginServiceEntry 2 } --- --- CtxtDialupIfLoginLat Table (Extends CtxtDialupIfLoginService) --- ctxtDialupIfLoginLatTable OBJECT-TYPE SYNTAX SEQUENCE OF CtxtDialupIfLoginLatEntry PIB-ACCESS notify STATUS current DESCRIPTION "Extended class." ::= { contextClasses 7 } ctxtDialupIfLoginLatEntry OBJECT-TYPE SYNTAX CtxtDialupIfLoginLatEntry STATUS current DESCRIPTION "Entry oid of the ctxtDialupIfLoginLatTable PRC." Weiss et al. Expires October 2000 [Page 68] Internet Draft Binding Authentication to Provisioning July 2001 EXTENDS { ctxtDialupIfLoginServiceEntry } UNIQUENESS { } ::= { ctxtDialupIfLoginLatTable 1 } CtxtDialupIfLoginLatEntry::= SEQUENCE { ctxtDialupIfLoginLatService OCTET STRING, ctxtDialupIfLoginLatNode OCTET STRING, ctxtDialupIfLoginLatGroup OCTET STRING, ctxtDialupIfLoginLatPort OCTET STRING } ctxtDialupIfLoginLatService OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "." ::= { ctxtDialupIfLoginLatEntry 1 } ctxtDialupIfLoginLatNode OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "." ::= { ctxtDialupIfLoginLatEntry 2 } ctxtDialupIfLoginLatGroup OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "." ::= { ctxtDialupIfLoginLatEntry 3 } ctxtDialupIfLoginLatPort OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "." ::= { ctxtDialupIfLoginLatEntry 4 } -- -- Authentication Extension Tables -- -- Weiss et al. Expires October 2000 [Page 69] Internet Draft Binding Authentication to Provisioning July 2001 -- AuthExtensions Base Table -- authExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AuthExtEntry PIB-ACCESS install-notify STATUS current DESCRIPTION "This is an abstract PRC. This PRC can be extended by authentication PRCs that contain attributes specific to that authentication protocol. An instance of the extended class is created by the PEP and sent to the PDP. The PDP may send information back to the PEP or may uses the information to authenticate the PEP's access request. This PRC itself should not be instantiated. This is a ætransientÆ class. Its instances are temporary and are deleted by the PEP after a certain time/event. Thus it must not be referred to by the server." ::= { authClasses 1 } authExtEntry OBJECT-TYPE SYNTAX AuthExtEntry STATUS current DESCRIPTION "Entry oid for the AuthExtTable PRC." PIB-INDEX { authExtId } UNIQUENESS { } ::= { authExtTable 1 } AuthExtEntry ::= SEQUENCE { authExtId InstanceId, authExtSession ReferenceId } authExtId OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An index to uniquely identify an instance of the entended provisioning class." ::= { authExtEntry 1 } authExtSession OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES { sessionEntry } STATUS current DESCRIPTION "This attribute is set by the PEP to reference the Weiss et al. Expires October 2000 [Page 70] Internet Draft Binding Authentication to Provisioning July 2001 session for which authentication is being requested." ::= { authExtEntry 2 } -- -- AuthChapExt Table -- authChapExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AuthChapExtEntry PIB-ACCESS notify STATUS current DESCRIPTION "This is a concrete PRC used to contain CHAP authentication fields. This PRC extends the base PRC authExtEntry." ::= { authClasses 2 } authChapExtEntry OBJECT-TYPE SYNTAX AuthChapExtEntry STATUS current DESCRIPTION "Entry oid for the AuthChapExtTable PRC. InstanceId's for this extended PRC are assigned by the base PRC [SPPI]." EXTENDS { authExtEntry } UNIQUENESS { } ::= { authChapExtTable 1 } AuthChapExtEntry::= SEQUENCE { authChapExtId Unsigned32, authChapExtChal OCTET STRING, authChapExtResp OCTET STRING } authChapExtId OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "CHAP Id field." ::= { authChapExtEntry 1 } authChapExtChal OBJECT-TYPE SYNTAX OCTET STRING STATUS current Weiss et al. Expires October 2000 [Page 71] Internet Draft Binding Authentication to Provisioning July 2001 DESCRIPTION "CHAP Challenge octet string. The challenge is generated by the PEP." ::= { authChapExtEntry 2 } authChapExtResp OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "CHAP Challenge Response octet string. The challenge response is sent to the PDP along with the challenge." ::= { authChapExtEntry 3 } -- -- AuthPapExt Table -- authPapExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AuthPapExtEntry PIB-ACCESS notify STATUS current DESCRIPTION "This is a concrete PRC used to contain PAP authentication fields. This PRC extends the base PRC authExtEntry." ::= { authClasses 3 } authPapExtEntry OBJECT-TYPE SYNTAX AuthPapExtEntry STATUS current DESCRIPTION "Entry oid for the AuthPapExtTable PRC. InstanceId's for this extended PRC are assigned by the base PRC [SPPI]." EXTENDS { authExtEntry } UNIQUENESS { } ::= { authPapExtTable 1 } AuthPapExtEntry::= SEQUENCE { authPapExtPwd OCTET STRING } authPapExtPwd OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "PAP password octet string." Weiss et al. Expires October 2000 [Page 72] Internet Draft Binding Authentication to Provisioning July 2001 ::= { authPapExtEntry 1 } -- -- AuthEapReqExt Table -- authEapReqExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AuthEapReqExtEntry PIB-ACCESS notify STATUS current DESCRIPTION "This is a concrete PRC used to contain EAP authentication fields. This PRC extends the base PRC authExtEntry. The PEP uses this PRC to send EAP messages to the PDP." ::= { authClasses 4 } authEapReqExtEntry OBJECT-TYPE SYNTAX AuthEapReqExtEntry STATUS current DESCRIPTION "Entry oid for the authEapReqExtTable PRC. InstanceId's for this extended PRC are assigned by the base PRC [SPPI]." EXTENDS { authExtEntry } UNIQUENESS { } ::= { authEapReqExtTable 1 } AuthEapReqExtEntry::= SEQUENCE { authEapReqExtSpecific OCTET STRING } authEapReqExtSpecific OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "Opaque EAP Request octet string." ::= { authEapReqExtEntry 1 } -- -- AuthEapRespExt Table -- authEapRespExtTable OBJECT-TYPE SYNTAX SEQUENCE OF AuthEapRespExtEntry PIB-ACCESS install STATUS current Weiss et al. Expires October 2000 [Page 73] Internet Draft Binding Authentication to Provisioning July 2001 DESCRIPTION "This is a concrete PRC used to contain EAP authentication fields. This PRC extends the base PRC authExtEntry. The PDP responds using this PRC for EAP exchanges." ::= { authClasses 5 } authEapRespExtEntry OBJECT-TYPE SYNTAX AuthEapRespExtEntry STATUS current DESCRIPTION "Entry oid for the authEapRespExtTable PRC. InstanceId's for this extended PRC are assigned by the base PRC [SPPI]." EXTENDS { authExtEntry } UNIQUENESS { } ::= { authEapRespExtTable 1 } AuthEapRespExtEntry::= SEQUENCE { authEapRespExtSpecific OCTET STRING } authEapRespExtSpecific OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "Opaque EAP Response octet string." ::= { authEapRespExtEntry 1 } -- -- conformance section tbd -- END 8. Security Considerations A COPS client-type implemented within the framework outlined in this document necessarily transmits sensitive authentication credentials between the PEP and the PDP. The COPS protocol provides optional message level security for authentication, replay protection, and message integrity for communications occurring between the PEP and the PDP by the use of the COPS Message Integrity Object [COPS]. Additionally, COPS optionally reuses existing protocols for security such as IPSEC [IPSEC] or TLS to authenticate and secure COPS communications. Careful consideration should be given to using these mechanisms to reduce the probability of compromising authentication Weiss et al. Expires October 2000 [Page 74] Internet Draft Binding Authentication to Provisioning July 2001 credentials. Furthermore, using these mechanisms cannot protect communication between an external authentication server and the PDP. So, when the PDP acts a proxy for an authentication server, consideration must be given to securing communications between the PDP and the authentication server as well. A discussion of applicable security techniques would be specific to any given authentication protocol and is outside the scope of this document. 9. References [MODEL] Y. Bernet, S. Blake, A. Smith, D. Grossman, "An Informal Management Model for Diffserv Routers," draft-ietf-diffserv-model-06.txt, February 2002. [DSPIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, C. Bell, A. Smith, F. Reichmeyer, "Differentiated Services Quality of Service Policy Information Base," draft-ietf-diffserv-pib-03.txt, March 2, 2001. [FWPIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer, ôFramework Policy Information Base," draft-ietf-rap-frameworkpib-04.txt, March 1, 2001. [AUTH] B. Lloyd, W. Simpson, ôPPP Authentication Protocols,ö RFC 1334, October 1992. [CHAP] W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [EAP] L. Blunk, J. Vollbrecht, ôPPP Extensible Authentication Protocol (EAP)ö, RFC 2284, March 1998. [NAI] B. Aboba, M. Beadles, ôThe Network Access Identifier,ö RFC 2486, January 1999. [IPSEC] R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, August 1995. [COPS] D. Durham, et al., "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [COPSPR] K. Chan, et al., "COPS Usage for Policy Provisioning (COPS- PR)", RFC 3084, March 2001. Weiss et al. Expires October 2000 [Page 75] Internet Draft Binding Authentication to Provisioning July 2001 10. Author Information and Acknowledgments Walter Weiss Ellacoya Networks 7 Henry Clay Drive Merrimack, NH 03054 Phone: +1 603 879 7364 E-mail: wweiss@ellacoya.com John Vollbrecht Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 Phone: +1 734 821 1205 E-Mail: jrv@interlinknetworks.com David Spence Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 Phone: +1 734 821 1203 E-Mail: dspence@interlinknetworks.com David Rago Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 Phone: +1 734 821 1241 E-Mail: drago@interlinknetworks.com Freek Dijkstra Physics and Astronomy Department Utrecht University Princetonplein 5 3584 CC Utrecht The Netherlands Phone: +31 30 2537724 Email: F.Dijkstra@phys.uu.nl Cees de Laat Faculty of Science, Informatics Institute, University of Amsterdam Kruislaan 403 1098 SJ Amsterdam The Netherlands Phone: +31 20 5257590 E-Mail: delaat@science.uva.nl Weiss et al. Expires October 2000 [Page 76] Internet Draft Binding Authentication to Provisioning July 2001 Leon Gommans Enterasys Networks EMEA, Kerkplein 24 2841 XM Moordrecht The Netherlands Phone: +31 182 379278 E-Mail: leon.gommans@enterasys.com Amol Kulkarni Intel 2111 NE 25th Avenue Hillsboro, OR 97124 Phone: 503.712.1168 E-Mail: Amol.Kulkarni@intel.com Ravi Sahita Intel 2111 NE 25th Avenue Hillsboro, OR 97124 Phone: 503.712.1554 E-Mail: Ravi.Sahita@intel.com Kwok Ho Chan Nortel Networks, Inc. 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288 8175 E-Mail: khchan@nortelnetworks.com Weiss et al. Expires October 2000 [Page 77]