idnits 2.17.1 draft-ietf-krb-wg-clear-text-cred-00.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 (June 28, 2011) is 4657 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 June 28, 2011 5 Expires: December 30, 2011 7 The Unencrypted Form Of Kerberos 5 KRB-CRED Message 8 draft-ietf-krb-wg-clear-text-cred-00 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 December 30, 2011. 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 tranferred 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 Security Assertion Markup Language (SAML) 2.0 57 [OASIS.saml-core-2.0-os] attribute transport. 59 In the SAML application, the Identity Provider (IdP) somehow obtains 60 a Kerberos service ticket from the Kerberos Key Distribution Center 61 (KDC) when required by the SAML system and transfers the credential 62 to a Service Provider (SP) within an attribute statement. The SP can 63 then use the credential to access a Kerberos protected service. 65 The Kerberos 5 specification as described in [RFC4120] mentions the 66 non-standard legacy use of unencypted KRB-CRED with Generic Security 67 Services Application Programming Interface (GSS-API) [RFC1964] by the 68 MIT, Heimdal, and Microsoft Kerberos implementations. This document 69 provides a formal specification of the unencrypted form of the KRB- 70 CRED message. 72 2. Requirements notation 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 3. The Unencrypted Form Of The KRB-CRED 80 The unencrypted form of the KRB-CRED contains EncryptedData as 81 defined in Section 5.2.9 [RFC4120]. The encryption type (etype) MUST 82 BE specified as 0. The optional key version number (kvno) SHOULD NOT 83 be present. The cipher text (cipher) is a copy of the EncKrbCredPart 84 as defined in Section 5.8.1 [RFC4120] which is in clear text. 86 4. Security Considerations 88 The KRB-CRED message contains sensitive information related to 89 Kerberos credentials being transferred, such as their secret session 90 keys, client and server principal names, and validity period. 91 Possession of this information, along with the ticket itself, would 92 allow an attacker to impersonate the client named in the ticket. The 93 possibility of modification of the KRB-CRED enables the substitution 94 of a credential by the attacker which can result in the recipients 95 use the credentials of a client which was not intended. As a result, 96 the KRB-CRED message must be carefully safeguarded. 98 The use of an unencrypted form of the KRB-CRED message MUST only be 99 used with a transport where sender and recipient identities can been 100 established be known to each other and provides confidentiality and 101 integrity. Examples of transports which MAY be securely used to 102 transport an unencrypted KRB-CRED message would include Transport 103 Layer Security (TLS) [RFC5246] where mutual authentication has been 104 established and those encoded within encrypted and signed SAML 105 Security Assertion Markup Language (SAML) 2.0 106 [OASIS.saml-core-2.0-os] statement. 108 5. Acknowledgements 110 The following individuals have contributed to the development of this 111 specification. 113 Thomas HardJono, Massachusetts Institute of Technology 115 Josh Howlett, Individual 117 Jeffrey Hutzelman, Carnegie Mellon University 119 6. IANA Considerations 121 This memo includes no request to IANA. 123 7. Normative References 125 [OASIS.saml-core-2.0-os] 126 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 127 "Assertions and Protocol for the OASIS Security Assertion 128 Markup Language (SAML) V2.0", OASIS Standard saml-core- 129 2.0-os, March 2005. 131 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 132 RFC 1964, June 1996. 134 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 135 Requirement Levels", BCP 14, RFC 2119, March 1997. 137 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 138 Kerberos Network Authentication Service (V5)", RFC 4120, 139 July 2005. 141 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 142 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 144 Author's Address 146 Russell J. Yount 147 Carnegie Mellon University 148 5000 Forbes Avenue 149 Pittsburgh, Pennsylvania 15213 150 US 152 Phone: +1 412 268 8391 153 Email: rjy@cmu.edu