rfc2989.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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]