One document matched: draft-ietf-krb-wg-clear-text-cred-03.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc1964 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1964.xml'>
    <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc3961 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3961.xml'>
    <!ENTITY rfc4120 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>
    <!ENTITY rfc5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
    <!ENTITY SAML20 SYSTEM "http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-core-2.0-os.xml"> 
]>

<rfc ipr="trust200902" docName="draft-ietf-krb-wg-clear-text-cred-03"
category="std">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="no" ?>

<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes" ?>

<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes"?>


<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

    <front>

        <title abbrev="Kerberos 5 Unencrypted KRB-CRED">The Unencrypted Form Of Kerberos 5 KRB-CRED Message</title>

        <author initials='R.J.Y.' surname="Yount" fullname='Russell J. Yount'>
            <organization>Carnegie Mellon University</organization>
            <address>
                <postal>
                    <street>5000 Forbes Avenue</street>
                    <city>Pittsburgh</city>
                    <region>Pennsylvania</region>
                    <code>15213</code>
                    <country>US</country>
                </postal>
                <phone>+1 412 268 8391</phone>
                <email>rjy@cmu.edu</email>
           </address>
        </author>

        <date day="23" month="September" year="2011" />

        <area>Security</area>

        <keyword>Kerberos</keyword>

        <abstract>
	  <t>
          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.
          </t>
        </abstract>

    </front>

    <middle>

        <section title="Introduction">
        <t>
        There are applications which 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.8 of the <xref target="sstc-saml-attribute-kerberos">SAML V2.0 Kerberos Attribute Profile</xref>.
        </t>
        <t>
        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. 
        </t>
        <t>
        The Kerberos 5 specification as described in <xref target="RFC4120"/> mentions the
        non-standard legacy use of unencrypted KRB-CRED with 
        Generic Security Services Application Programming Interface (GSS-API) <xref target="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.
        </t>
        </section>

        <section title="Requirements notation">
            <t>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 <xref target="RFC2119"/>.</t>
        </section>

        <section title="The Unencrypted Form Of The KRB-CRED">
        <t>
        The unencrypted form of the KRB-CRED contains EncryptedData as defined
        in Section 5.2.9 <xref target="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 cipher text (cipher) is a copy of the EncKrbCredPart as defined in Section 5.8.1
        <xref target="RFC4120"/> 
        which is in clear text. 
        </t>
        </section>

        <section title="Kerberos Encryption Type 0 Is Not An Encryption System">
        <t>
        The Kerberos Encryption Type 0 is an invalid value <xref target="RFC3961"/>. 
        This means that no <xref target="RFC3961"/> 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 type integer as a flag or sentinal 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 it is a message specific indicator to be interpreted
	as the message is not encrypted.  
        This approach was chosen due to existing Kerberos implementations which
        conform to this specification.
        </t>
        </section>

        <section title="Security Considerations">
          <t>
           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 enables
           the attacker to substitute the credentials. This can result in the
           recipient using the credentials of a client which was not intended.
           As a result, the KRB-CRED message must be carefully safeguarded.
           </t>
           <t>
           The use of an unencrypted form of the KRB-CRED message MUST only be used with a transport where
           sender and recipient identities can been established to be known to each other. The transport MUST also 
           provide confidentiality, integrity, and mutual authentication. 
           Examples of transports which MAY be securely used to transport an unencrypted KRB-CRED message
           would include Transport Layer Security (TLS) <xref target="RFC5246"/> where mutual authentication has been established
           and those encoded within encrypted and signed
           SAML <xref target="OASIS.saml-core-2.0-os">Security Assertion Markup Language (SAML) 2.0</xref>
           statement.
          </t>
        </section>

        <section anchor="Acknowledgements" title="Acknowledgements">
        <t>The following individuals have contributed to the development of this specification.</t>
        <t>Thomas Hardjono, Massachusetts Institute of Technology</t>
        <t>Josh Howlett, Individual</t>
        <t>Jeffrey Hutzelman, Carnegie Mellon University</t>
        </section>

        <section anchor="IANA" title="IANA Considerations">
            <t>The reference for Kerberos encryption type 0 should be updated to point to this document.</t>
        </section>

    </middle>

    <back>

        <references title='Normative References'>
	    &rfc1964;
	    &rfc2119;
	    &rfc4120;
	    &rfc5246;
            &SAML20;
	</references>

        <references title='Informative References'>
	    <reference anchor="sstc-saml-attribute-kerberos">
	    	<front>
		<title>SAML V2.0 Kerberos Attribute Profile Version 1.0, OASIS Security Services Draft, sstc-saml-attribute-kerberos.odt (work in progress)</title>
		<author surname="Howlett" initials="J"/>
		<author surname="Hardjono" initials="T"/>
		<date year="2010" month="December"/>
	    	</front>
	    </reference>
	    &rfc3961;
	</references>

    </back>

        <!-- Change Log

v00 2010-09-02  RJY   Initial version
v01 2010-12-06  RJY   Wording cleanup
v00 2011-06-28  RJY   Renamed from draft-yount-krb-cred-clear-text-01
v01 2011-07-21	RJY   In section "Security Considerations" some grammatical improvements(break sentences up)
v01 2011-07-21	RJY   In section "The Unencrypted Form Of The KRB-CRED" added "and MUST be ignored by the recipient if present."
v01 2011-07-22	RJY   Added RFC3961 as informative referencesd
v01 2011-07-22	RJY   SAML V2.0 Kerberos Attribute Profile Version 1.0 as informative references 
v01 2011-07-23	RJY   Added section "Kerberos Encryption Type 0 Is Not An Encryption System"
v01 2011-07-23  RJY   Changed reference of SAML20 to be sstc-saml-attribute-kerberos in introduction
v01 2011-07-25  RJY   Additional grammar corrections
v02 2011-08-15  RJY   added "to enable its continued use in new applications" in Introduction
v02 2011-08-15  RJY   added "and end to end security" in Security Considerations 
v02 2011-08-15  RJY   changed "MUST BE" to "MUST be" in The Unencrypted Form Of The KRB-CRED
v03 2011-09-23  RJY   changed "end to end security" to be "mutual authentication" in security considerations; Hartman's wording
v03 2011-09-23  RJY   update section 4; Hartman's wording
 -->


</rfc>