如果已经协商过了EAP，但RADIUS代理或服务器不支持，那么服务器或代理必须用Access-Reject报文响应。在这些情况下，NAS必须发送一个LCP-Terminate并且切断用户。这是正确的行为，因为认证对等端期望协商EAP，但期望不能被满足。对于支持EAP的认证对等端，如果最初已经协商了EAP，那么解决重新协商认证协议。需要注意的是因RADIUS代理服务器不支持EAP而出现的问题是很难诊断的。因为从一个地方拨号接入的用户（代理支持EAP）或许能够用EAP成功认证，而同一个用户从另一个地方拨号进入时（代理不支持EAP），或许始终被切断。
8. References
[1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC2865, June
2000.
[2] Rigney, C., "RADIUS Accounting", RFC2866, June 2000.
[3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC2284, March 1998.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March, 1997.
[5] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994.
[6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
2868, June 2000.
[7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC2867, June 2000.
[8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
Rigney, et al. Informational [Page 43]
RFC2869 RADIUS Extensions June 2000
[9] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC2104, February 1997.
[10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC2434, October 1998.
[11] Slatalla, M., and Quittner, J., "Masters of Deception."
HarperCollins, New York, 1995.
9. Acknowledgements
RADIUS and RADIUS Accounting were originally developed by Livingston
Enterprises (now part of Lucent Technologies) for their PortMaster
series of Network Access Servers.
The section on ARAP is adopted with permission from "Using RADIUS to
Authenticate Apple Remote Access Connections" by Ward Willats of Cyno
Technologies (ward@cyno.com).
The section on Acct-Interim-Interval is adopted with permission from
an earlier work in progress by Pat Calhoun of Sun Microsystems, Mark
Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies.
The section on EAP is adopted with permission from an earlier work in
progress by Pat Calhoun of Sun Microsystems, Allan Rubens of Merit
Network, and Bernard Aboba of Microsoft. Thanks also to Dave Dawson
and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of
Microsoft for useful discussions of this problem space.
10. 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: +1 925 737 2100
EMail: cdr@telemancy.com
Rigney, et al. Informational [Page 44]
RFC2869 RADIUS Extensions June 2000
11. Authors' Addresses
Questions about this memo can also be directed to:
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
EMail: cdr@telemancy.com
Questions on ARAP and RADIUS may be directed to:
Ward Willats
Cyno Technologies
1082 Glen Echo Ave
San Jose, CA 95125
Phone: +1 408 297 7766
EMail: ward@cyno.com
Rigney, et al. Informational [Page 45]
RFC2869 RADIUS Extensions June 2000
Questions on EAP and RADIUS may be directed to any of the following:
Pat R. Calhoun
Network and Security Research Center
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, CA 94025
Phone: +1 650 786 7733
EMail: pcalhoun@eng.sun.com
Allan C. Rubens
Tut Systems, Inc.
220 E. Huron, Suite 260
Ann Arbor, MI 48104
Phone: +1 734 995 1697
EMail: arubens@tutsys.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 936 6605
EMail: bernarda@microsoft.com
Rigney, et al. Informational [Page 46]
RFC2869 RADIUS Extensions June 2000
12. 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.