📄 rfc2989.txt
字号:
Aboba, et al. Informational [Page 7]
RFC 2989 Network Access AAA Evaluation Criteria November 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Reliable AAA transport | M | | M |
| mechanism | 22 | | 31 32 |
| h | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Run Over IPv4 | M | M | M |
| | 11 | 1 | 33 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Run Over IPv6 | M | | S |
| | 11 | 1 | 47 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Support Proxy and | M | | M |
| Routing Brokers | 12 | | 31 39 |
| i | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Auditability | S | | |
| j | 25 | | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Dual App and Transport | | O | M |
| Security not required | | 6 | 40 |
| k | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Ability to carry | M | | S |
| service-specific attr. | 43 | | 31 33 |
| l | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
Aboba, et al. Informational [Page 8]
RFC 2989 Network Access AAA Evaluation Criteria November 2000
Clarifications
[a] The AAA protocol must be capable of supporting millions of users
and tens of thousands of simultaneous requests. The AAA
architecture and protocol MUST be capable of supporting tens of
thousands of devices, AAA servers, proxies and brokers.
[b] In the event of failure to communicate with a given server, the
protocol must provide a mechanism to change service to another
backup or secondary server.
[c] This requirement refers to the ability to support mutual
authentication between the AAA client and server.
[d] The AAA protocol requires authentication, integrity protection
and confidentiality at the transmission layer. This security
model is also referred to as hop-by-hop security, whereas the
security is established between two communicating peers. All of
the security is removed when the AAA message is processed by a
receiving AAA entity.
[e] The AAA protocol requires confidentiality at the object level,
where an object consists of one or more attributes. Object
level confidentiality implies that only the target AAA entity
for whom the data is ultimately destined may decrypt the data,
regardless of the fact that the message may traverse one or more
intermediate AAA entities (e.g., proxies, brokers).
[f] The AAA protocol requires authentication and integrity
protection at the object level, which consists of one or more
attributes. Object level authentication must be persistent
across one or more intermediate AAA entity (e.g., proxy, broker,
etc), meaning that any AAA entity in a proxy chain may verify
the authentication. This implies that data that is covered by
object level security CANNOT be modified by intermediate
servers.
[g] The AAA protocol MUST be capable of transporting certificates.
This requirement is intended as an optimization, in lieu of
requiring that an out-of-band protocol be used to fetch
certificates.
[h] This requirement refers to resilience against packet loss,
including:
1. Hop-by-hop retransmission and fail-over so that reliability
does not solely depend on single hop transport
retransmission.
Aboba, et al. Informational [Page 9]
RFC 2989 Network Access AAA Evaluation Criteria November 2000
2. Control of the retransmission mechanism by the AAA
application.
3. Acknowledgment by the transport that a message was delivered
successfully, separate from message semantics or syntax
evaluation.
5. Piggy-backing of acknowledgments in AAA messages.
6. Timely delivery of AAA responses.
[i] In the Mobile IP AAA architecture, brokers can be in the
forwarding path, in which case they act as transparent proxies
(proxy brokers). Alternatively, it is also possible to conceive
of brokers operating as certifying authorities outside of the
forwarding path (routing brokers).
[j] An auditable process is one in which it is possible to
definitively determine what actions have been performed on AAA
packets as they travel from the home AAA server to the network
device and back.
[k] The AAA protocol MUST allow communication to be secured.
However, the AAA protocol MUST also allow an underlying security
service (e.g., IP Security) to be used. When the latter is
used, the former MUST NOT be required.
[l] The AAA protocol MUST be extensible by third parties (e.g.,
other IETF Working Groups), in order to define attributes that
are specific to the service being defined. This requirement
simply means that the AAA protocol MUST allow groups other than
the AAA WG to define standard attributes.
Aboba, et al. Informational [Page 10]
RFC 2989 Network Access AAA Evaluation Criteria November 2000
2.2. Authentication Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Authentication | NASREQ | ROAMOPS | MOBILE |
| Reqts. | | | IP |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| NAI Support | M | M | S/M |
| a | 9 | 2 |32,34,39/|
| | | | 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| CHAP Support | M | M | |
| b | 10 | 3 | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| EAP Support | M | S | |
| c | 10 | 3 | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| PAP/Clear-Text Support | M | B | |
| d | 26 | 3 | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Re-authentication | M | | S |
| on demand | 17 | | 33 |
| e | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Authorization Only | M | | |
| without Authentication | 9 | | |
| f | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
Aboba, et al. Informational [Page 11]
RFC 2989 Network Access AAA Evaluation Criteria November 2000
Clarifications
[a] The AAA protocol MUST allow the use of Network Access
Identifiers (NAI) [8] to identify users and/or devices.
[b] The AAA protocol MUST allow CHAP [20] authentication information
to be transported. This is commonly used by Network Access
Servers that request authentication of a PPP user.
[c] The AAA protocol MUST allow for Extensible Authentication
Protocol (EAP) [14] payload to be transported. Since some EAP
authentication mechanisms require more than one round trip, the
AAA protocol must allow for such authentication mechanisms to be
used. The actual EAP authentication mechanism negotiated MUST
be transparent to the AAA protocol. When EAP is used,
authentication typically occurs between the user being
authenticated and his/her home AAA server.
[d] While PAP is deprecated, it is still in widespread use for its
original intended purpose, which is support of clear-text
passwords. As a result, a AAA protocol will need to be able to
securely transport clear-text passwords. This includes
providing for confidentiality of clear-text passwords traveling
over the wire, as well as protecting against disclosure of
clear-text passwords to proxies in the forwarding path.
[e] The AAA protocol MUST allow for a user to be re-authenticated
on-demand. The protocol MUST allow for this event to be
triggered by either the user, access device (AAA client), or the
home or visited AAA server.
[f] The AAA protocol MUST NOT require that credentials of the user
be provided during authorization. The AAA protocol supports
authorization by identification or assertion only.
Aboba, et al. Informational [Page 12]
RFC 2989 Network Access AAA Evaluation Criteria November 2000
2.3. Authorization Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Authorization | NASREQ | ROAMOPS | MOBILE |
| Reqts. | | | IP |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static and Dynamic | | | |
| IPv4/6 Address Assign. | M | M | M |
| a | 11 | 5 | 32 36 |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| RADIUS gateway | M | M | M |
| capability | 44 | 3 | 45 |
| b | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Reject | M | M | M |
| capability | 12 | 4 | 39 |
| c | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Precludes layer 2 | N | N | |
| tunneling | 11 | 5 | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Re-Authorization on | M | | S |
| demand | 18 | | 30 33 |
| d | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Support for Access Rules,| M | | |
| Restrictions, Filters | 11, 19 | | |
| e | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| State Reconciliation | M | | |
| f | 20 | | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Unsolicited Disconnect | M | | |
| g | 18 | | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Aboba, et al. Informational [Page 13]
RFC 2989 Network Access AAA Evaluation Criteria November 2000
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
Clarifications
[a] The AAA protocol MUST allow a server to provide a static or
dynamic address during the authorization phase of a user and/or
device. The address assigned MUST be either of type IPv4 or
IPv6. If both the client AND the server are aware of a pre-
configured address, then it is considered static. Anything else
is dynamic.
[b] This requirement refers to the ability of a new AAA protocol be
sufficiently compatible with the large installed base of
attributes for existing approaches (RADIUS), such that a server
implementation could speak both protocols, or translate between
them.
[c] This requirement refers to the ability of a proxy broker to deny
access without forwarding the access request to the AAA server,
or to deny access after receiving an access accept from the AAA
server.
[d] This requirement refers to the ability of the AAA client or
server to trigger re-authorization, or to the ability of the
server to send updated authorization information to the device,
such as "stop service." Authorization can allow for a time
period, then additional authorization can be sought to continue.
A server can initially authorize a user to connect and receive
services, but later decide the user is no longer allowed use of
the service, for example after N minutes. Authorizations can
have a time limit. Re-authorization does not necessarily imply
re-authentication.
[e] This requirement refers to the ability to of the protocol to
describe access operational limitations and authorization
restrictions to usage to the NAS which includes (but is not
limited to):
1. Session expirations and Idle Timeouts
2. Packet filters
3. Static routes
4. QoS parameters
Aboba, et al. Informational [Page 14]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -