rfc2868.txt

RFC 的详细文档！

      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If the value of the Tag field is greater than 0x00
      and less than or equal to 0x1F, it SHOULD be interpreted as
      indicating which tunnel (of several alternatives) this attribute
      pertains.  If the Tag field is greater than 0x1F, it SHOULD be
      interpreted as the first byte of the following String field.

   String
      This field must be present.  The String field contains the
      authentication name of the tunnel initiator.  The authentication
      name SHOULD be represented in the UTF-8 charset.

3.10.  Tunnel-Server-Auth-ID

   Description

      This Attribute specifies the name used by the tunnel terminator
      during the authentication phase of tunnel establishment.  The
      Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the
      RADIUS server) in the Access-Request packet, and MUST be included
      in the Access-Accept packet if an authentication name other than
      the default is desired.  This Attribute SHOULD be included in
      Accounting-Request packets which contain Acct-Status-Type
      attributes with values of either Start or Stop and which pertain
      to a tunneled session.

   A summary of the Tunnel-Server-Auth-ID Attribute format is shown
   below.  The fields are transmitted from left to right.






Zorn, et al.                 Informational                     [Page 14]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |      Tag      |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      91 for Tunnel-Server-Auth-ID.

   Length
      >= 3

   Tag
      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If the value of the Tag field is greater than 0x00
      and less than or equal to 0x1F, it SHOULD be interpreted as
      indicating which tunnel (of several alternatives) this attribute
      pertains.  If the Tag field is greater than 0x1F, it SHOULD be
      interpreted as the first byte of the following String field.

   String
      This field must be present.  The String field contains the
      authentication name of the tunnel terminator.  The authentication
      name SHOULD be represented in the UTF-8 charset.

4.  Table of Attributes

   The following table provides a guide to which of the above attributes
   may be found in which kinds of packets, and in what quantity.

Request Accept Reject Challenge Acct-Request #  Attribute
0+      0+     0      0         0-1          64 Tunnel-Type
0+      0+     0      0         0-1          65 Tunnel-Medium-Type
0+      0+     0      0         0-1          66 Tunnel-Client-Endpoint
0+      0+     0      0         0-1          67 Tunnel-Server-Endpoint
0       0+     0      0         0            69 Tunnel-Password
0+      0+     0      0         0-1          81 Tunnel-Private-Group-ID
0       0+     0      0         0-1          82 Tunnel-Assignment-ID
0+      0+     0      0         0            83 Tunnel-Preference
0+      0+     0      0         0-1          90 Tunnel-Client-Auth-ID
0+      0+     0      0         0-1          91 Tunnel-Server-Auth-ID

   The following table defines the meaning of the above table entries.

0     This attribute MUST NOT be present in packet.
0+    Zero or more instances of this attribute MAY be present in packet.
0-1   Zero or one instance of this attribute MAY be present in packet.



Zorn, et al.                 Informational                     [Page 15]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


5.  Security Considerations

   The Tunnel-Password Attribute may contain information which should
   only be known to a tunnel endpoint.  However, the method used to hide
   the value of the attribute is such that intervening RADIUS proxies
   will have knowledge of the contents.  For this reason, the Tunnel-
   Password Attribute SHOULD NOT be included in Access-Accept packets
   which may pass through (relatively) untrusted RADIUS proxies.  In
   addition, the Tunnel-Password Attribute SHOULD NOT be returned to an
   unauthenticated client; if the corresponding Access-Request packet
   did not contain a verified instance of the Signature Attribute [15],
   the Access-Accept packet SHOULD NOT contain an instance of the
   Tunnel-Password Attribute.

   Tunnel protocols offer various levels of security, from none (e.g.,
   PPTP) to strong (e.g., IPSec).  Note, however, that in the compulsory
   tunneling case any security measures in place only apply to traffic
   between the tunnel endpoints.  In particular, end-users SHOULD NOT
   rely upon the security of the tunnel to protect their data;
   encryption and/or integrity protection of tunneled traffic MUST NOT
   be considered as a replacement for end-to-end security.

6.  IANA Considerations

   This document defines a number of "magic" numbers to be maintained by
   the IANA.  This section explains the criteria to be used by the IANA
   to assign additional numbers in each of these lists.  The following
   subsections describe the assignment policy for the namespaces defined
   elsewhere in this document.

6.1.  Tunnel-Type Attribute Values

   Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1;
   the remaining values are available for assignment by the IANA with
   IETF Consensus [16].

6.2.  Tunnel-Medium-Type Attribute Values

   Values 1-15 of the Tunnel-Medium-Type Attribute are defined in
   Section 5.2; the remaining values are available for assignment by the
   IANA with IETF Consensus [16].

7.  References

   [1]  Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
        G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637,
        July 1999.




Zorn, et al.                 Informational                     [Page 16]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


   [2]  Valencia, A., Littlewood, M. and T. Kolar, T., "Cisco Layer Two
        Forwarding (Protocol) 'L2F'", RFC 2341, May 1998.

   [3]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
        B. Palter, "Layer Two Tunnelling Protocol (L2TP)", RFC 2661,
        August 1999.

   [4]  Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC
        2107, February 1997.

   [5]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

   [6]  Perkins, C., "IP Encapsulation within IP", RFC 2003, October
        1996.

   [7]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
        October 1996.

   [8]  Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC
        1827, August 1995.

   [9]  Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
        Encapsulation (GRE)", RFC 1701, October 1994.

   [10] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.

   [11] Zorn, G. and D. Mitton, "RADIUS Accounting Modifications for
        Tunnel Protocol Support", RFC 2867, June 2000.

   [12] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
        Authentication Dial in User Service (RADIUS)", RFC 2865, June
        2000.

   [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [14] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        October 1994.

   [15] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC
        2869, June 2000.

   [16] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [17] Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.



Zorn, et al.                 Informational                     [Page 17]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


8.  Acknowledgements

   Thanks to Dave Mitton for pointing out a nasty circular dependency in
   the original Tunnel-Password attribute definition and (in no
   particular order) to Kory Hamzeh, Bertrand Buclin, Andy Valencia,
   Bill Westfield, Kris Michielsen, Gurdeep Singh Pall, Ran Atkinson,
   Aydin Edguer, and Bernard Aboba for useful input and review.

9.  Chair's Address

   The RADIUS Working Group can be contacted via the current chair:

   Carl Rigney
   Livingston Enterprises
   4464 Willow Road
   Pleasanton, California  94588

   Phone: [phone]
   EMail: [e-mail]

10.  Authors' Addresses

   Questions about this memo can also be directed to:

   Glen Zorn
   Cisco Systems, Inc.
   500 108th Avenue N.E., Suite 500
   Bellevue, Washington 98004
   USA

   Phone: [phone]
   FAX:   [phone]
   EMail: [e-mail]


   Dory Leifer
   Ascend Communications
   1678 Broadway
   Ann Arbor, MI 48105

   Phone:  [phone]
   EMail: [e-mail]









Zorn, et al.                 Informational                     [Page 18]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


   John Shriver
   Intel Corporation
   28 Crosby Drive
   Bedford, MA  01730

   Phone:  [phone]
   EMail: [e-mail]


   Allan Rubens
   Ascend Communications
   1678 Broadway
   Ann Arbor, MI 48105

   Phone:  [phone]
   EMail: [e-mail]


   Matt Holdrege
   ipVerse
   223 Ximeno Ave.
   Long Beach, CA 90803

   EMail: [e-mail]


   Ignacio Goyret
   Lucent Technologies
   One Ascend Plaza
   1701 Harbor Bay Parkway
   Alameda, CA 94502

   Phone:  [phone]
   EMail: [e-mail]

















Zorn, et al.                 Informational                     [Page 19]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


11.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Zorn, et al.                 Informational                     [Page 20]