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]
