idnits 2.17.1 draft-ietf-krb-wg-clear-text-cred-03.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 (September 23, 2011) is 4598 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 September 23, 2011 5 Expires: March 26, 2012 7 The Unencrypted Form Of Kerberos 5 KRB-CRED Message 8 draft-ietf-krb-wg-clear-text-cred-03 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 March 26, 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 to enable its continued use in new applications. 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]. This 91 means that no [RFC3961] encryption type with value 0 will ever be 92 defined; no encryption or key management operations will use this 93 value. Layers above the encryption layer often transport encryption 94 types as integer values. These layers are free to use a 0 in an 95 encryption type integer as a flag or sentinal value or for other 96 context-specific purposes. For example, section 3 of this 97 specification defines the semantics of a 0 carried in the KRB-CRED 98 message's encryption type field. In the context of the KRB-CRED it 99 is a message specific indicator to be interpreted as the message is 100 not encrypted. This approach was chosen due to existing Kerberos 101 implementations which conform to this specification. 103 5. Security Considerations 105 The KRB-CRED message contains sensitive information related to 106 Kerberos credentials being transferred, such as their secret session 107 keys, client and server principal names, and validity period. 108 Possession of this information, along with the ticket itself, would 109 allow an attacker to impersonate the client named in the ticket. The 110 possibility of modification of the KRB-CRED enables the attacker to 111 substitute the credentials. This can result in the recipient using 112 the credentials of a client which was not intended. As a result, the 113 KRB-CRED message must be carefully safeguarded. 115 The use of an unencrypted form of the KRB-CRED message MUST only be 116 used with a transport where sender and recipient identities can been 117 established to be known to each other. The transport MUST also 118 provide confidentiality, integrity, and mutual authentication. 119 Examples of transports which MAY be securely used to transport an 120 unencrypted KRB-CRED message would include Transport Layer Security 121 (TLS) [RFC5246] where mutual authentication has been established and 122 those encoded within encrypted and signed SAML Security Assertion 123 Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] statement. 125 6. Acknowledgements 127 The following individuals have contributed to the development of this 128 specification. 130 Thomas Hardjono, Massachusetts Institute of Technology 132 Josh Howlett, Individual 134 Jeffrey Hutzelman, Carnegie Mellon University 136 7. IANA Considerations 138 The reference for Kerberos encryption type 0 should be updated to 139 point to this document. 141 8. References 143 8.1. Normative References 145 [OASIS.saml-core-2.0-os] 146 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 147 "Assertions and Protocol for the OASIS Security Assertion 148 Markup Language (SAML) V2.0", OASIS Standard saml-core- 149 2.0-os, March 2005. 151 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 152 RFC 1964, June 1996. 154 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 155 Requirement Levels", BCP 14, RFC 2119, March 1997. 157 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 158 Kerberos Network Authentication Service (V5)", RFC 4120, 159 July 2005. 161 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 162 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 164 8.2. Informative References 166 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 167 Kerberos 5", RFC 3961, February 2005. 169 [sstc-saml-attribute-kerberos] 170 Howlett, J. and T. Hardjono, "SAML V2.0 Kerberos Attribute 171 Profile Version 1.0, OASIS Security Services Draft, sstc- 172 saml-attribute-kerberos.odt (work in progress)", 173 December 2010. 175 Author's Address 177 Russell J. Yount 178 Carnegie Mellon University 179 5000 Forbes Avenue 180 Pittsburgh, Pennsylvania 15213 181 US 183 Phone: +1 412 268 8391 184 Email: rjy@cmu.edu