doc: Add RFC documents

1 files changed, 227 insertions, 0 deletions

diff --git a/doc/rfc/rfc6448.txt b/doc/rfc/rfc6448.txt
new file mode 100644
index 0000000..8376b33
--- /dev/null
+++ b/doc/rfc/rfc6448.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          R. Yount
+Request for Comments: 6448                    Carnegie Mellon University
+Category: Standards Track                                  November 2011
+ISSN: 2070-1721
+
+
+          The Unencrypted Form of Kerberos 5 KRB-CRED Message
+
+Abstract
+
+   The Kerberos 5 KRB-CRED message is used to transfer Kerberos
+   credentials between applications.  When used with a secure transport,
+   the unencrypted form of the KRB-CRED message may be desirable.  This
+   document describes the unencrypted form of the KRB-CRED message.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6448.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+Yount                        Standards Track                    [Page 1]
+
+RFC 6448             Kerberos 5 Unencrypted KRB-CRED       November 2011
+
+
+1.  Introduction
+
+   There are applications that need to transfer Kerberos credentials
+   between them without having a prior relationship with established
+   Kerberos keys.  When transferred over a transport that provides
+   confidentiality and integrity, the unencrypted form of the KRB-CRED
+   message MAY be used.  One application employing this method is the
+   Kerberos attribute transport mechanism, described in Section 2.7 of
+   the Security Assertion Markup Language (SAML) V2.0 Kerberos Attribute
+   Profile [SAMLv2-KRB-ATTRIB].
+
+   In the SAML application, the Identity Provider (IdP) somehow obtains
+   a Kerberos service ticket from the Kerberos Key Distribution Center
+   (KDC) when required by the SAML system and transfers the credential
+   to a Service Provider (SP) within an attribute statement.  The SP can
+   then use the credential to access a Kerberos protected service.
+
+   The Kerberos 5 specification as described in [RFC4120] mentions the
+   non-standard legacy use of unencrypted KRB-CRED messages with the
+   Generic Security Service Application Program Interface (GSS-API)
+   [RFC1964] by the MIT, Heimdal, and Microsoft Kerberos
+   implementations.  This document provides a formal specification of
+   the unencrypted form of the KRB-CRED message to enable its continued
+   use in new applications.
+
+2.  Requirements Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+3.  The Unencrypted Form of the KRB-CRED Message
+
+   The unencrypted form of the KRB-CRED message contains EncryptedData
+   as defined in Section 5.2.9 of [RFC4120].  The encryption type
+   (etype) MUST be specified as 0.  The optional key version number
+   (kvno) SHOULD NOT be present and MUST be ignored by the recipient if
+   present.  The ciphertext (cipher) is a copy of the EncKrbCredPart,
+   which is in cleartext, as defined in Section 5.8.1 of [RFC4120].
+
+4.  Kerberos Encryption Type 0 Is Not an Encryption System
+
+   The Kerberos Encryption Type 0 is an invalid value [RFC3961].  This
+   means that no encryption type with value 0 will ever be defined; no
+   encryption or key management operations will use this value.  Layers
+   above the encryption layer often transport encryption types as
+   integer values.  These layers are free to use a 0 in an encryption
+
+
+
+
+Yount                        Standards Track                    [Page 2]
+
+RFC 6448             Kerberos 5 Unencrypted KRB-CRED       November 2011
+
+
+   type integer as a flag or sentinel value, or for other context-
+   specific purposes.  For example, Section 3 of this specification
+   defines the semantics of a 0 carried in the KRB-CRED message's
+   encryption type field.  In the context of the KRB-CRED message, it is
+   a message-specific indicator to be interpreted as the message is not
+   encrypted.  This approach was chosen due to existing Kerberos
+   implementations that conform to this specification.
+
+5.  Security Considerations
+
+   The KRB-CRED message contains sensitive information related to
+   Kerberos credentials being transferred, such as their secret session
+   keys, client and server principal names, and validity period.
+   Possession of this information, along with the ticket itself, would
+   allow an attacker to impersonate the client named in the ticket.  The
+   possibility of modification of the KRB-CRED message enables the
+   attacker to substitute the credentials.  This can result in the
+   recipient using the credentials of a client that was not intended.
+   As a result, the KRB-CRED message must be carefully safeguarded.
+
+   The use of an unencrypted form of the KRB-CRED message MUST only be
+   used with a transport where sender and recipient identities can be
+   established to be known to each other.  The transport MUST also
+   provide confidentiality, integrity, and mutual authentication.
+   Examples of transports that MAY be securely used to transport an
+   unencrypted KRB-CRED message would include Transport Layer Security
+   (TLS) [RFC5246], where mutual authentication has been established, or
+   the use of messages where the KRB-CRED is encoded within an encrypted
+   and signed SAML 2.0 [OASIS-SAMLv2] statement.
+
+6.  Acknowledgements
+
+   The following individuals have contributed to the development of this
+   specification.
+
+      Thomas Hardjono, Massachusetts Institute of Technology
+
+      Josh Howlett, Individual
+
+      Jeffrey Hutzelman, Carnegie Mellon University
+
+7.  IANA Considerations
+
+   The reference for Kerberos Encryption Type 0 has been updated to
+   point to this document.
+
+
+
+
+
+
+Yount                        Standards Track                    [Page 3]
+
+RFC 6448             Kerberos 5 Unencrypted KRB-CRED       November 2011
+
+
+8.  References
+
+8.1.  Normative References
+
+   [OASIS-SAMLv2]
+              Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E.
+              Maler, Ed., "Assertions and Protocol for the OASIS
+              Security Assertion Markup Language (SAML) V2.0", OASIS
+              Standard saml-core-2.0-os, March 2005.
+
+   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+              RFC 1964, June 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+8.2.  Informative References
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, February 2005.
+
+   [SAMLv2-KRB-ATTRIB]
+              Howlett, J., Ed., and T. Hardjono, Ed., "SAML V2.0
+              Kerberos Attribute Profile Version 1.0",
+              sstc-saml-attribute-kerberos.odt, August 2011.
+
+Author's Address
+
+   Russell J. Yount
+   Carnegie Mellon University
+   5000 Forbes Avenue
+   Pittsburgh, Pennsylvania  15213
+   US
+
+   Phone: +1 412 268 8391
+   EMail: rjy@cmu.edu
+
+
+
+
+
+
+
+
+Yount                        Standards Track                    [Page 4]
+