idnits 2.17.1 draft-ietf-krb-wg-clear-text-cred-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 26, 2011) is 4651 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Yount 3 Internet-Draft Carnegie Mellon University 4 Intended status: Standards Track July 26, 2011 5 Expires: January 27, 2012 7 The Unencrypted Form Of Kerberos 5 KRB-CRED Message 8 draft-ietf-krb-wg-clear-text-cred-01 10 Abstract 12 The Kerberos 5 KRB-CRED message is used to transfer Kerberos 13 credentials between applications. When used with a secure transport 14 the unencrypted form of the KRB-CRED message may be desirable. This 15 document describes the unencrypted form of the KRB-CRED message. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 27, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 There are applications which need to transfer Kerberos credentials 52 between them without having a prior relationship with established 53 Kerberos keys. When transferred over a transport that provides 54 confidentiality and integrity, the unencrypted form of the KRB-CRED 55 message MAY be used. One application employing this method is the 56 Kerberos attribute transport mechanism described in section 2.8 of 57 the SAML V2.0 Kerberos Attribute Profile 58 [sstc-saml-attribute-kerberos]. 60 In the SAML application, the Identity Provider (IdP) somehow obtains 61 a Kerberos service ticket from the Kerberos Key Distribution Center 62 (KDC) when required by the SAML system and transfers the credential 63 to a Service Provider (SP) within an attribute statement. The SP can 64 then use the credential to access a Kerberos protected service. 66 The Kerberos 5 specification as described in [RFC4120] mentions the 67 non-standard legacy use of unencrypted KRB-CRED with Generic Security 68 Services Application Programming Interface (GSS-API) [RFC1964] by the 69 MIT, Heimdal, and Microsoft Kerberos implementations. This document 70 provides a formal specification of the unencrypted form of the KRB- 71 CRED message. 73 2. Requirements notation 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 3. The Unencrypted Form Of The KRB-CRED 81 The unencrypted form of the KRB-CRED contains EncryptedData as 82 defined in Section 5.2.9 [RFC4120]. The encryption type (etype) MUST 83 BE specified as 0. The optional key version number (kvno) SHOULD NOT 84 be present and MUST be ignored by the recipient if present. The 85 cipher text (cipher) is a copy of the EncKrbCredPart as defined in 86 Section 5.8.1 [RFC4120] which is in clear text. 88 4. Kerberos Encryption Type 0 Is Not An Encryption System 90 The Kerberos Encryption Type 0 is an invalid value [RFC3961]. Layers 91 above the encryption layer are left to interpret its use in their own 92 context specific manner. The use of encryption type 0 in the 93 unencrypted form of the KRB-CRED is not to specify an encryption 94 type. In the context of the KRB-CRED it is a message specific 95 indicator to be interpreted as the message is not encrypted. This 96 approach was chosen due to existing Kerberos implementations which 97 conform to this specification. 99 5. Security Considerations 101 The KRB-CRED message contains sensitive information related to 102 Kerberos credentials being transferred, such as their secret session 103 keys, client and server principal names, and validity period. 104 Possession of this information, along with the ticket itself, would 105 allow an attacker to impersonate the client named in the ticket. The 106 possibility of modification of the KRB-CRED enables the attacker to 107 substitute the credentials. This can result in the recipient using 108 the credentials of a client which was not intended. As a result, the 109 KRB-CRED message must be carefully safeguarded. 111 The use of an unencrypted form of the KRB-CRED message MUST only be 112 used with a transport where sender and recipient identities can been 113 established to be known to each other. The transport MUST also 114 provide confidentiality and integrity. Examples of transports which 115 MAY be securely used to transport an unencrypted KRB-CRED message 116 would include Transport Layer Security (TLS) [RFC5246] where mutual 117 authentication has been established and those encoded within 118 encrypted and signed SAML Security Assertion Markup Language (SAML) 119 2.0 [OASIS.saml-core-2.0-os] statement. 121 6. Acknowledgements 123 The following individuals have contributed to the development of this 124 specification. 126 Thomas Hardjono, Massachusetts Institute of Technology 128 Josh Howlett, Individual 130 Jeffrey Hutzelman, Carnegie Mellon University 132 7. IANA Considerations 134 The reference for Kerberos encryption type 0 should be updated to 135 point to this document. 137 8. References 138 8.1. Normative References 140 [OASIS.saml-core-2.0-os] 141 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 142 "Assertions and Protocol for the OASIS Security Assertion 143 Markup Language (SAML) V2.0", OASIS Standard saml-core- 144 2.0-os, March 2005. 146 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 147 RFC 1964, June 1996. 149 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 150 Requirement Levels", BCP 14, RFC 2119, March 1997. 152 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 153 Kerberos Network Authentication Service (V5)", RFC 4120, 154 July 2005. 156 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 157 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 159 8.2. Informative References 161 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 162 Kerberos 5", RFC 3961, February 2005. 164 [sstc-saml-attribute-kerberos] 165 Howlett, J. and T. Hardjono, "SAML V2.0 Kerberos Attribute 166 Profile Version 1.0, OASIS Security Services Draft, sstc- 167 saml-attribute-kerberos.odt (work in progress)", 168 December 2010. 170 Author's Address 172 Russell J. Yount 173 Carnegie Mellon University 174 5000 Forbes Avenue 175 Pittsburgh, Pennsylvania 15213 176 US 178 Phone: +1 412 268 8391 179 Email: rjy@cmu.edu