rfc3182.txt

RFC 的详细文档！

6.2 Message Reception (Router)

   RSVP message is processed as specified in [RFC 2205] with following
   modifications.

   1. If router is not policy aware then it SHOULD send the RSVP message
      to the PDP and wait for response.  If the router is policy unaware
      then it ignores the policy data objects and continues processing
      the RSVP message.

   2. Reject the message if the response from the PDP is negative.

   3. Continue processing the RSVP message.

6.3 Authentication (Router/PDP)

   1. Retrieve the AUTH_DATA policy element.  Check the PE type field
      and return an error if the identity type is not supported.

   2. Verify user credential

      -  Simple authentication: e.g., Get user ID and validate it, or
         get executable name and validate it.

      -  Kerberos: Send the Kerberos ticket to the KDC to obtain the
         session key.  Using the session key authenticate the user.

      -  Public Key: Validate the certificate that it was issued by a
         trusted Certificate Authority (CA) and authenticate the user or
         application by verifying the digital signature.

7. Error Signaling

   If PDP fails to verify the AUTH_DATA policy element then it MUST
   return policy control failure (Error Code = 02) to the PEP.  The
   error values are described in [RFC 2205] and [POL-EXT].  Also PDP
   SHOULD supply a policy data object containing an AUTH_DATA Policy
   Element with A-Type=POLICY_ERROR_CODE containing more details on the
   Policy Control failure (see section 3.3.4).  The PEP will include
   this Policy Data object in the outgoing RSVP Error message.

8. IANA Considerations

   Following the policies outlined in [IANA-CONSIDERATIONS], Standard
   RSVP Policy Elements (P-type values) are assigned by IETF Consensus
   action as described in [POL-EXT].





Yadav, et al.               Standards Track                    [Page 13]

RFC 3182            Identity Representation for RSVP        October 2001


   P-Type AUTH_USER is assigned the value 2.  P-Type AUTH_APP is
   assigned the value 3.

   Following the policies outlined in [IANA-CONSIDERATIONS],
   authentication attribute types (A-Type) in the range 0-127 are
   allocated through an IETF Consensus action, A-Type values between
   128-255 are reserved for Private Use and are not assigned by IANA.

   A-Type POLICY_LOCATOR is assigned the value 1.  A-Type CREDENTIAL is
   assigned the value 2.  A-Type DIGITAL_SIGNATURE is assigned the value
   3.  A-Type POLICY_ERROR_OBJECT is assigned the value 4.

   Following the policies outlined in [IANA-CONSIDERATIONS],
   POLICY_LOCATOR SubType values in the range 0-127 are allocated
   through an IETF Consensus action, POLICY_LOCATOR SubType values
   between 128-255 are reserved for Private Use and are not assigned by
   IANA.

   POLICY_LOCATOR SubType ASCII_DN is assigned the value 1, SubType
   UNICODE_DN is assigned the value 2, SubType ASCII_DN_ENCRYPT is
   assigned the value 3 and SubType UNICODE_DN_ENCRYPT is assigned the
   value 4.

   Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL
   SubType values in the range 0-127 are allocated through an IETF
   Consensus action, CREDENTIAL SubType values between 128-255 are
   reserved for Private Use and are not assigned by IANA.

   CREDENTIAL SubType ASCII_ID is assigned the value 1, SubType
   UNICODE_ID is assigned the value 2, SubType KERBEROS_TKT is assigned
   the value 3, SubType X509_V3_CERT is assigned the value 4, SubType
   PGP_CERT is assigned the value 5.

   Following the policies outlined in [IANA-CONSIDERATIONS], ErrorValues
   in the range 0-32767 are allocated through an IETF Consensus action,
   ErrorValues between 32768-65535 are reserved for Private Use and are
   not assigned by IANA.

   ErrorValue ERROR_NO_MORE_INFO is assigned the value 1,
   UNSUPPORTED_CREDENTIAL_TYPE is assigned the value 2,
   INSUFFICIENT_PRIVILEGES is assigned the value 3, EXPIRED_CREDENTIAL
   is assigned the value 4, and IDENTITY_CHANGED is assigned the value
   5.








Yadav, et al.               Standards Track                    [Page 14]

RFC 3182            Identity Representation for RSVP        October 2001


9. Security Considerations

   The purpose of this memo is to describe a mechanism to authenticate
   RSVP requests based on user identity in a secure manner.  RSVP
   INTEGRITY object is used to protect the policy object containing user
   identity information from security (replay) attacks.  Combining the
   AUTH_DATA policy element and the INTEGRITY object results in a secure
   access control that enforces authentication based on both the
   identity of the user and the identity of the originating node.

   Simple authentication does not contain credential that can be
   securely authenticated and is inherently less secured.

   The Kerberos authentication mechanism is reasonably well secured.

   User authentication using a public key certificate is known to
   provide the strongest security.

10. Acknowledgments

   We would like to thank Andrew Smith, Bob Lindell and many others for
   their valuable comments on this memo.

11. References

   [ASCII]               Coded Character Set -- 7-Bit American Standard
                         Code for Information Interchange, ANSI X3.4-
                         1986.

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

   [POL-EXT]             Herzog, S., "RSVP Extensions for Policy
                         Control", RFC 2750, January 2000.

   [POL-FRAME]           Yavatkar, R., Pendarakis, D. and R. Guerin, "A
                         Framework for Policy-based Admission Control
                         RSVP", RFC 2753, January 2000.

   [RFC 1510]            Kohl, J. and C. Neuman, "The Kerberos Network
                         Authentication Service (V5)", RFC 1510,
                         September 1993.

   [RFC 1704]            Haller, N. and R. Atkinson, "On Internet
                         Authentication", RFC 1704, October 1994.





Yadav, et al.               Standards Track                    [Page 15]

RFC 3182            Identity Representation for RSVP        October 2001


   [RFC 1779]            Killie, S., "A String Representation of
                         Distinguished Names", RFC 1779, March 1995.

   [RFC 2205]            Braden, R., Zhang, L., Berson, S., Herzog, S.
                         and S. Jamin, "Resource ReSerVation Protocol
                         (RSVP) - Version 1 Functional Specification",
                         RFC 2205, September 1997.

   [RFC 2209]            Braden, R. and L. Zhang, "Resource ReSerVation
                         Protocol (RSVP) - Version 1 Message Processing
                         Rules", RFC 2209, September 1997.

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

   [RFC 2751]            Herzog, S., "Signaled Preemption Priority
                         Policy Element", RFC 2751, January 2000.

   [UNICODE]             The Unicode Consortium, "The Unicode Standard,
                         Version 2.0", Addison-Wesley, Reading, MA,
                         1996.

   [X.509]               Housley, R., Ford, W., Polk, W. and D. Solo,
                         "Internet X.509 Public Key Infrastructure
                         Certificate and CRL Profile", RFC 2459, January
                         1999.

   [X.509-ITU]           ITU-T (formerly CCITT) Information technology -
                         Open Systems Interconnection - The Directory:
                         Authentication Framework Recommendation X.509
                         ISO/IEC 9594-8

12. Authors' Addresses

   Satyendra Yadav
   Intel, JF3-206
   2111 NE 25th Avenue
   Hillsboro, OR 97124

   EMail: [e-mail]










Yadav, et al.               Standards Track                    [Page 16]

RFC 3182            Identity Representation for RSVP        October 2001


   Raj Yavatkar
   Intel, JF3-206
   2111 NE 25th Avenue
   Hillsboro, OR 97124

   EMail: [e-mail]


   Ramesh Pabbati
   Microsoft
   1 Microsoft Way
   Redmond, WA 98054

   EMail: [e-mail]


   Peter Ford
   Microsoft
   1 Microsoft Way
   Redmond, WA 98054

   EMail: [e-mail]


   Tim Moore
   Microsoft
   1 Microsoft Way
   Redmond, WA 98054

   EMail: [e-mail]


   Shai Herzog
   PolicyConsulting.Com
   200 Clove Rd.
   New Rochelle, NY 10801

   EMail: [e-mail]


   Rodney Hess
   Intel, BD1
   28 Crosby Drive
   Bedford, MA 01730

   EMail: [e-mail]





Yadav, et al.               Standards Track                    [Page 17]

RFC 3182            Identity Representation for RSVP        October 2001


13. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.



















Yadav, et al.               Standards Track                    [Page 18]