doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc6251.txt b/doc/rfc/rfc6251.txt
new file mode 100644
index 0000000..9cd0511
--- /dev/null
+++ b/doc/rfc/rfc6251.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      S. Josefsson
+Request for Comments: 6251                                        SJD AB
+Category: Informational                                         May 2011
+ISSN: 2070-1721
+
+
+                        Using Kerberos Version 5
+            over the Transport Layer Security (TLS) Protocol
+
+Abstract
+
+   This document specifies how the Kerberos V5 protocol can be
+   transported over the Transport Layer Security (TLS) protocol in order
+   to provide additional security features.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see 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/rfc6251.
+
+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.
+
+
+
+
+
+
+Josefsson                     Informational                     [Page 1]
+
+RFC 6251             Protecting Kerberos V5 with TLS            May 2011
+
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Introduction and Background .....................................2
+   2. Kerberos V5 STARTTLS Extension ..................................3
+   3. Examples ........................................................4
+   4. STARTTLS-Aware KDC Discovery ....................................5
+   5. Server Certificates .............................................6
+   6. IANA Considerations .............................................7
+   7. Acknowledgements ................................................7
+   8. Security Considerations .........................................7
+   9. References ......................................................8
+      9.1. Normative References .......................................8
+      9.2. Informative References .....................................8
+
+1.  Introduction and Background
+
+   This document describes how a Kerberos V5 [RFC4120] implementation
+   may upgrade communication between clients and Key Distribution
+   Centers (KDCs) to use the Transport Layer Security (TLS) [RFC5246]
+   protocol.
+
+   The TLS protocol offers integrity- and privacy-protected exchanges
+   that can be authenticated using X.509 certificates, OpenPGP keys
+   [RFC6091], and usernames and passwords via Secure Remote Password
+   (SRP) [RFC5054].
+
+   There are several reasons to use Kerberos V5 over TLS.
+
+   o  It prevents downgrade attacks affecting, e.g., encryption types
+      and pre-auth data negotiation.  The encryption type field in
+      KDC-REQ and the METHOD-DATA field with the requested pre-auth
+      types from the server in KDC_ERR_PREAUTH_REQUIRED errors in
+      KDC-REP are sent without integrity or privacy protection in
+      Kerberos V5.  This allows an active attacker to replace the
+      encryption type with a compromised encryption type, e.g., 56-bit
+      DES, or request that clients should use a broken pre-auth type.
+
+
+
+Josefsson                     Informational                     [Page 2]
+
+RFC 6251             Protecting Kerberos V5 with TLS            May 2011
+
+
+      Since clients in general cannot know the encryption types other
+      servers support, or the pre-auth types servers prefer or require,
+      it is difficult for the client to detect if there was a man in the
+      middle or if the remote server simply did not support a stronger
+      encryption type or preferred another pre-auth type.
+
+   o  Kerberos exchanges are privacy protected.  Parts of many Kerberos
+      packets are transferred without privacy protection (i.e.,
+      encryption).  That part contains information, such as the client
+      principal name, the server principal name, the encryption types
+      supported by the client, the lifetime of tickets, etc.  Revealing
+      such information is, in some threat models, considered a problem.
+
+   o  It provides additional authentication against the KDC.  In some
+      situations, users are equipped with smart cards with an RSA
+      authentication key.  In others, users have an OpenPGP client on
+      their desktop, with a public OpenPGP key known to the server.
+
+   o  It provides explicit server authentication of the KDC to the
+      client.  In traditional Kerberos V5, authentication of the KDC is
+      proved as a side effect that the KDC knows your encryption key
+      (i.e., your password).
+
+   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 RFC 2119 [RFC2119].
+
+2.  Kerberos V5 STARTTLS Extension
+
+   The STARTTLS extension uses the Kerberos V5 TCP extension mechanism
+   [RFC5021].  The extension uses bit 0 in the extension bitmask.
+
+   The protocol is as follows.  The client requests the extension by
+   setting the STARTTLS bit in the TCP extension mechanism bitmask.
+   (How to deal with extension negotiation failures at this point is
+   described in [RFC5021].)  After the server has sent the 4-octet value
+   0x00000000 to indicate support of this extension, the stream will be
+   controlled by the TLS protocol and its framing.  The TLS protocol is
+   initiated by the client.
+
+   Typically, the client initiates the TLS handshake protocol by sending
+   a client hello, the server responds, and the handshake continues
+   until it either succeeds or fails.
+
+   If, for any reason, the handshake fails, the STARTTLS protocol will
+   also fail, and the TLS error is used as the error indication.  In
+   this case, no further messages can be exchanged over the same TCP
+   session.
+
+
+
+Josefsson                     Informational                     [Page 3]
+
+RFC 6251             Protecting Kerberos V5 with TLS            May 2011
+
+
+   If the handshake succeeds, the Kerberos V5 authentication protocol is
+   performed within the protected TLS channel, like a normal TCP
+   Kerberos V5 exchange.  In particular, this means that every Kerberos
+   V5 packet will be prefixed by a 4-octet length field that indicates
+   the length of the Kerberos V5 packet.
+
+   When no further Kerberos V5 messages need to be transferred in the
+   TLS session, the TLS session MUST be shut down properly using the
+   close_notify alert.  When the TLS session is shut down, the TCP
+   connection cannot be re-used to send any further data and MUST be
+   closed.
+
+3.  Examples
+
+   A complete packet flow for a successful AS-REQ/REP exchange protected
+   by this mechanism will be as follows.  The "STARTTLS-bit" is a
+   4-octet value with only the bit allocated for this extension set, and
+   | is the binary OR operation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                     Informational                     [Page 4]
+
+RFC 6251             Protecting Kerberos V5 with TLS            May 2011
+
+
+       Client                                               Server
+
+        [ Kerberos V5 TCP extension mechanism negotiation starts ]
+
+       0x80000000 | STARTTLS-bit    -------->
+                                                       0x00000000
+                                    <--------
+
+                            [ TLS negotiation starts ]
+
+
+       ClientHello                  -------->
+                                                       ServerHello
+                                                      Certificate*
+                                                ServerKeyExchange*
+                                               CertificateRequest*
+                                    <--------      ServerHelloDone
+       Certificate*
+       ClientKeyExchange
+       CertificateVerify*
+       [ChangeCipherSpec]
+       Finished                     -------->
+                                                [ChangeCipherSpec]
+                                    <--------             Finished
+
+                       [ Kerberos V5 negotiation starts ]
+
+       4-octet length field
+       Kerberos V5 AS-REQ           -------->
+                                                4-octet length field
+                                                Kerberos V5 AS-REP
+                                    <--------
+
+       * Indicates optional or situation-dependent messages that are not
+         always sent
+
+4.  STARTTLS-Aware KDC Discovery
+
+   Section 7.2.3 of Kerberos V5 [RFC4120] describes how Domain Name
+   System (DNS) SRV records [RFC2782] can be used to find the address of
+   a KDC.  We define a new Service of "kerberos-tls" to indicate that
+   the particular KDC is intended to support this STARTTLS extension.
+   The Proto (tcp), Realm, TTL, Class, SRV, Priority, Weight, Port, and
+   Target have the same meaning as in RFC 4120.
+
+
+
+
+
+
+
+Josefsson                     Informational                     [Page 5]
+
+RFC 6251             Protecting Kerberos V5 with TLS            May 2011
+
+
+   For example:
+
+   _kerberos-tls._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
+
+   _kerberos-tls._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
+
+5.  Server Certificates
+
+   The TLS protocol may be used in a mode that provides server
+   authentication using, for example, X.509 and OpenPGP.
+
+   A goal for the protocol described in this memo is that it should be
+   as easy to implement and deploy on clients as support for UDP/TCP.
+   Since many client environments do not have access to long-term
+   storage, or to long-term storage that is sufficiently secure to
+   enable validation of server certificates, the Kerberos V5 STARTTLS
+   protocol does not require clients to verify server certificates.  If
+   server certification had been required, then environments with
+   constrained clients such as those mentioned would be forced to
+   disable TLS; this would arguably be worse than TLS without server
+   certificate validation, as the use of TLS, even without server
+   certificate validation, protects against some attacks that Kerberos
+   V5 over UDP/TCP does not.  For example, even without server
+   certificate validation, TLS does protect against passive network
+   sniffing aimed at tracking Kerberos service usage by a given client.
+
+   However, note that the use of TLS without server certificate
+   verification opens up a range of active attacks such as man in the
+   middle.
+
+   When clients have the ability, they MUST validate the server
+   certificate.  For this reason, if a KDC presents an X.509 server
+   certificate over TLS, it MUST contain an otherName Subject
+   Alternative Name (SAN) identified using a type-id of
+   id-krb5starttls-san.  The intention is to bind the server certificate
+   to the Kerberos realm for the purpose of using Kerberos V5 STARTTLS.
+   The value field of the otherName should contain the realm as the
+   "Realm" ASN.1 type.
+
+          id-krb5starttls-san OBJECT IDENTIFIER ::=
+            { iso(1) identified-organization(3) dod(6) internet(1)
+              private(4) enterprise(1) gnu(11591)
+              shishi(6) krb5starttls-san(1) }
+
+   To validate a server certificate, the client MAY use local
+   configuration (e.g., a list that maps the Kerberos realm to a copy of
+   the server's certificate) and compare that with the authentication
+   information provided from the server via TLS.  For illustration, the
+
+
+
+Josefsson                     Informational                     [Page 6]
+
+RFC 6251             Protecting Kerberos V5 with TLS            May 2011
+
+
+   server certificate could be an X.509 certificate or an OpenPGP key.
+   In this mode, the client needs no processing related to id-
+   krb5starttls-san.
+
+   When the server presents an X.509 server certificate, clients MAY use
+   "Certification Path Validation" as described in [RFC5280] to validate
+   the KDC server certificate.  In addition, unless the client can
+   otherwise verify that the server certificate is bound to the KDC of
+   the target realm, the client MUST verify that the server certificate
+   contains the id-krb5starttls-san SAN and that the value is identical
+   to the intended Kerberos realm.
+
+6.  IANA Considerations
+
+   Per [RFC5021], the IANA has allocated a bit (value 0) in the
+   "Kerberos TCP Extensions" registry for Krb5 over TLS, the extension
+   described in this document.
+
+7.  Acknowledgements
+
+   Miguel A. Garcia, Sam Hartman, Jeffrey Hutzelman, Magnus Nystroem,
+   and Peter Saint-Andre (in alphabetical order) provided comments that
+   improved the protocol and document.
+
+8.  Security Considerations
+
+   The security considerations in Kerberos V5, TLS, and the Kerberos V5
+   TCP extension mechanism are inherited.
+
+   Note that TLS does not protect against man-in-the-middle attacks
+   unless clients verify the KDC's credentials (X.509 certificate,
+   OpenPGP key, etc.) correctly.  Although certificate validation adds
+   an extra layer of protection, that is not considered strictly
+   necessary to improve the security profile of Kerberos V5 as outlined
+   in this document.
+
+   If server authentication is used, some information about the server
+   (such as its name) is visible to passive attackers.
+
+   To protect against the inherent downgrade attack in the extension
+   framework, implementations SHOULD offer a policy mode that requires
+   this extension to always be successfully negotiated, for a particular
+   realm, or generally.  For interoperability with implementations that
+   do not support this extension, the policy mode SHOULD be disabled by
+   default.
+
+
+
+
+
+
+Josefsson                     Informational                     [Page 7]
+
+RFC 6251             Protecting Kerberos V5 with TLS            May 2011
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              July 2005.
+
+   [RFC5021]  Josefsson, S., "Extended Kerberos Version 5 Key
+              Distribution Center (KDC) Exchanges over TCP", RFC 5021,
+              August 2007.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, May 2008.
+
+9.2.  Informative References
+
+   [RFC5054]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
+              "Using the Secure Remote Password (SRP) Protocol for TLS
+              Authentication", RFC 5054, November 2007.
+
+   [RFC6091]  Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
+              for Transport Layer Security (TLS) Authentication",
+              RFC 6091, February 2011.
+
+Author's Address
+
+   Simon Josefsson
+   Simon Josefsson Datakonsult AB
+   Hagagatan 24
+   Stockholm  113 47
+   Sweden
+
+   EMail: simon@josefsson.org
+   URI:   http://josefsson.org/
+
+
+
+
+Josefsson                     Informational                     [Page 8]
+