One document matched: draft-ietf-krb-wg-iakerb-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC4120 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>
<!ENTITY RFC4121 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4121.xml'>
<!ENTITY RFC2743 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml'>
<!ENTITY RFC4178 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4178.xml'>
<!ENTITY RFC3961 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3961.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<rfc ipr='full3978' updates="4120" category="std" docName="draft-ietf-krb-wg-iakerb-00">
<front><title abbrev="IAKERB">Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API
(IAKERB)</title>
<author initials="L." surname="Zhu" fullname="Larry Zhu">
<organization>Microsoft Corporation</organization>
<address><postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<email>lzhu@microsoft.com</email></address>
</author>
<author initials="J." surname="Altman" fullname="Jeffery Altman">
<organization>Secure Endpoints</organization> <address>
<postal>
<street> 255 W 94th St </street>
<city>New York</city>
<region>NY</region>
<code>10025</code>
<country>US</country>
</postal>
<email>jaltman@secure-endpoints.com</email></address>
</author>
<date year="2007"></date>
<area>Security</area><workgroup>NETWORK WORKING GROUP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document defines extensions to the Kerberos protocol and the GSS-API Kerberos mechanism
that enable a GSS-API Kerberos client to exchange messages with the KDC using
the GSS-API acceptor as the proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is
accessible to the application server.</t>
</abstract>
</front><middle>
<section anchor="introduction" title="Introduction">
<t>When authenticating using Kerberos V5, clients obtain tickets from a
KDC and present them to services. This model of operation cannot work if the client does not have
access to the KDC. For example, in remote access scenarios,
the client must initially authenticate to an access point in
order to gain full access to the network. Here the client may be
unable to directly contact the KDC either because it does not have an
IP address, or the access point packet filter does not allow the
client to send packets to the Internet before it authenticates to the
access point. </t>
<t>Recent advancements in extending Kerberos permit
Kerberos authentication to complete with the assistance of a proxy. The Kerberos <xref target="RFC4120"/> pre-authentication framework <xref target="KRB-PAFW"/>
prevents the exposure of weak client keys over the open network.
The Kerberos support of anonymity [KRB-ANON] provides for privacy and further complicates traffic analysis.
The kdc-referrals option defined in <xref target="KRB-PAFW"/> may reduce the number of messages exchanged while obtaining a ticket to exactly two
even in cross-realm authentications.</t>
<t> Building upon these Kerberos extensions, this document extends <xref target="RFC4120"/> and
<xref target="RFC4121"/> such that the client can communicate with the KDC using a Generic Security Service
Application Program Interface (GSS-API) <xref target="RFC2743"/> acceptor as the proxy. The GSS-API acceptor relays
the KDC request and reply messages between the client and the KDC.
The GSS-API acceptor, when relaying the Kerberos messages, is called an IAKERB proxy.
Consequently, IAKERB as defined in this document requires the use of GSS-API.</t>
</section>
<section title="Conventions Used in This Document">
<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" pageno="false" format="default"></xref>.</t>
</section>
<section anchor="defs" title="GSS-API Encapsulation">
<t> The mechanism Objection Identifier (OID) for GSS-API IAKERB, in accordance
with the mechanism proposed by <xref target="RFC4178"/>
for negotiating protocol variations, is id-kerberos-iakerb:</t>
<figure>
<artwork>
id-kerberos-iakerb ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
iakerb(5) }
</artwork>
</figure>
<t> The initial context establishment token of IAKERB MUST have the generic token framing described in section 3.1 of
<xref target="RFC2743"/> with the mechanism OID being id-kerberos-iakerb, and any subsequent IAKERB context establishment token MUST NOT
have this token framing.</t>
<t> The client starts by constructing the ticket request, and if the ticket request
is being made to the KDC, the client, instead of contacting the KDC directly, encapsulates the request message
into the output token of the GSS_Init_security_context() call and returns GSS_S_CONTINUE_NEEDED <xref target="RFC2743"/> indicating that
at least one more token is required in order to establish the context. The output
token is then passed for use as the input token to the GSS_Accept_sec_context() call in accordance with GSS-API. The GSS-API acceptor extracts
the Kerberos request in the input token, locates the target KDC, and sends the request on behalf of the client.
After receiving the KDC reply, the GSS-API
acceptor then encapsulates the reply message into the output token of GSS_Accept_sec_context(). The GSS-API acceptor returns GSS_S_CONTINUE_NEEDED <xref target="RFC2743"/> indicating that
at least one more token is required in order to establish the context. The output token is passed to the initiator in accordance with GSS-API.</t>
<figure>
<artwork>
Client --------- IAKERB proxy ---------- KDC
</artwork>
</figure>
<t> The innerToken described in section 3.1 of
<xref target="RFC2743"/> and subsequent GSS-API mechanism tokens have the following formats: it starts with a two-octet token-identifier
(TOK_ID), followed by an IAKERB message or a Kerberos message. </t>
<t> Only one IAKERB specific message, namely the IAKERB_PROXY message, is defined in this document.
The TOK_ID values for Kerberos messages are the
same as defined in <xref target="RFC4121"/>.</t>
<figure>
<artwork>
Token TOK_ID Value in Hex
--------------------------------------
IAKERB_PROXY 05 01
</artwork>
</figure>
<t>The content of the IAKERB_PROXY message is defined as an IAKERB-HEADER structure immediately followed by a Kerberos message.
The Kerberos message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, or a KRB-ERROR as defined in <xref target="RFC4120"/>.</t>
<figure>
<artwork>
IAKERB-HEADER ::= SEQUENCE {
target-realm [1] UTF8String,
-- The name of the target realm.
cookie [2] OCTET STRING OPTIONAL,
-- Opaque data, if sent by the server,
-- MUST be copied by the client verbatim into
-- the next IAKRB_PROXY message.
...
}
</artwork>
</figure>
<t> The IAKERB-HEADER structure and all the Kerberos messages MUST
be encoded using Abstract Syntax Notation One (ASN.1) Distinguished Encoding Rules (DER) [X680] [X690]. </t>
<t>The IAKERB client fills out the IAKERB-HEADER structure as follows:
the target-realm contains the realm name the ticket request is addressed to. In the initial message from the client, the cookie field is absent.
The client MUST specify a target-realm. If the client does not
know the realm of the client's true principal name [REFERALS], it MUST specify a realm it knows. This can be the realm of the client's host.</t>
<t> Upon receipt of the IAKERB_PROXY message,
the GSS-API acceptor inspects the target-realm field in the IAKERB_HEADER, and locates a KDC of that realm, and sends the ticket request to that KDC.</t>
<t> When the GSS-API acceptor is unable to obtain an IP address for a KDC in the
client's realm, it sends a KRB_ERROR message with the code KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client and the context fails to establish. There is no accompanying error data defined in
this document for this error code.</t>
<figure>
<artwork>
KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85
-- The IAKERB proxy could not find a KDC.
</artwork>
</figure>
<t>When the GSS-API acceptor has an IP address for a KDC in the client realm,
but does not receive a response from any KDC in the realm (including
in response to retries), it sends a KRB_ERROR message with the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client and the context fails to establish. There is no accompanying error data defined
in this document for this error code.</t>
<figure>
<artwork>
KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86
-- The KDC did not respond to the IAKERB proxy.
</artwork>
</figure>
<t>The IAKERB proxy can send opaque data in the cookie field of the IAKERB-HEADER structure in the server reply to the client,
in order to, for example, minimize the amount of state information kept by the GSS-API acceptor.
The content and the encoding of
the cookie field is a local matter of the IAKERB proxy. The client MUST copy the cookie verbatim
from the previous server response whenever the cookie is present into the subsequent tokens that contains an IAKERB_PROXY message. </t>
<t>When the client obtained a service ticket,
the client sends a KRB_AP_REQ message to the server, and performs the client-server application exchange as defined in
<xref target="RFC4120"/> and <xref target="RFC4121"/>. </t>
<t> For implementations comforming to this specification, both the authenticator subkey and
the GSS_EXTS_FINISHED extension as defined in <xref target="PKU2U"/> MUST be present in
the AP-REQ authenticator.
This checksum provides
integrity protection for the messages exchanged including
the unauthenticated clear texts in the IAKERB-HEADER structure.</t>
<t>If the pre-authentication data is encrypted in the long-term
password-based key of the principal, the risk of security
exposures is significant. Implementations
SHOULD provide the AS_REQ armoring as defined in
<xref target="KRB-PAFW"/> unless an alternative protection is deployed.
In addition, the anonymous
Kerberos FAST option is RECOMMENDED for the client to complicate
traffic analysis.</t>
</section>
<section title="Addresses in Tickets">
<t>In IAKERB, the machine sending requests to the KDC is the GSS-API acceptor and
not the client. As a result, the client should not include its
addresses in any KDC requests for two reasons. First, the KDC may
reject the forwarded request as being from the wrong client. Second,
in the case of initial authentication for a dial-up client, the
client machine may not yet possess a network address. Hence, as
allowed by <xref target="RFC4120"/>, the addresses field of the AS-REQ and TGS-REQ
requests SHOULD be blank and the caddr field of the ticket SHOULD
similarly be left blank.</t>
</section>
<section anchor="securityconsideration" title="Security Considerations" toc="default">
<t> A typical IAKERB client sends the AS_REQ with pre-authentication data
encrypted in the long-term keys of the user before the server is authenticated. This enables offline
attacks by un-trusted servers. To mitigate this threat, the
client SHOULD use Kerberos FAST<xref target="KRB-PAFW"/> and require KDC authentication to protect
the user's credentials.</t>
<t>The client name is in clear text in the authentication exchange
messages and ticket granting service exchanges according to
<xref target="RFC4120"/> whereas the client name is encrypted in client-
server application exchange messages. By using the IAKERB proxy
to relay the ticket requests and responses, the client's identity
could be revealed in the client-server traffic where the same identity
could have been concealed if IAKERB were not used.
Hence, to complicate traffic analysis and provide privacy for the IAKERB client,
the IAKERB client SHOULD request the anonymous Kerberos FAST option <xref target="KRB-PAFW"/>.</t>
<t>Similar to other network access protocols, IAKERB allows an
unauthenticated client (possibly outside the security perimeter of an
organization) to send messages that are proxied to interior servers.</t>
<t> In a scenario where DNS SRV RR's are being used to locate the
KDC, IAKERB is being used, and an external attacker can modify DNS
responses to the IAKERB proxy, there are several countermeasures to
prevent arbitrary messages from being sent to internal servers:<vspace blankLines="1"/>
<list style="numbers"><t> KDC port numbers can be statically configured on the IAKERB
proxy. In this case, the messages will always be sent to KDC's. For
an organization that runs KDC's on a static port (usually port 88)
and does not run any other servers on the same port, this
countermeasure would be easy to administer and should be effective.<vspace blankLines="1"/></t>
<t> The proxy can do application level sanity checking and filtering.
This countermeasure should eliminate many of the above attacks.<vspace blankLines="1"/></t>
<t> DNS security can be deployed. This countermeasure is probably
overkill for this particular problem, but if an organization has
already deployed DNS security for other reasons, then it might make
sense to leverage it here. Note that Kerberos could be used to
protect the DNS exchanges. The initial DNS SRV KDC lookup by the
proxy will be unprotected, but an attack here is at most a denial of
service (the initial lookup will be for the proxy's KDC to facilitate
Kerberos protection of subsequent DNS exchanges between itself and
the DNS server).</t>
</list>
</t>
</section>
<section title="Acknowledgements">
<t> Jonathan Trostle, Michael Swift, Bernard Aboba
and Glen Zorn wrote earlier revision of this document.</t>
<t>The hallway conversations between Larry Zhu
and Nicolas Williams formed the basis of this document.</t>
</section>
<section title="IANA Considerations">
<t>There is no IANA action required for this document.</t>
</section>
</middle>
<back>
<references title="Normative References">&RFC2119;&RFC4120;&RFC4121;&RFC2743;&RFC4178;&RFC3961;
<reference anchor="GSS-EXTS">
<front>
<title>Kerberos Version 5 GSS-API Channel Binding Hash Agility</title>
<author initials="S." surname="Emery">
<organization></organization>
</author>
<date year="2007"/>
</front>
<seriesInfo name="internet-draft" value="draft-ietf-krb-wg-gss-cb-hash-agility-03.txt"/>
</reference>
</references>
<references title="Informative references">
<reference anchor="KRB-PAFW">
<front>
<title>A Generalized Framework for Kerberos Pre-Authentication</title>
<author initials="L." surname="Zhu">
<organization></organization>
</author>
<author initials="S." surname="Hartman">
<organization></organization>
</author>
<date year="2007"/>
</front>
<seriesInfo name="internet-draft" value="draft-ietf-krb-wg-preauth-framework-06.txt"/>
</reference>
<reference anchor="PKU2U">
<front>
<title>Public Key Cryptography Based User-to-User Authentication - (PKU2U)</title>
<author initials="L." surname="Zhu">
<organization></organization>
</author>
<author initials="J." surname="Altman">
<organization></organization>
</author>
<date year="2007"/>
</front>
<seriesInfo name="internet-draft" value="draft-zhu-pku2u"/>
</reference>
<reference anchor="KRB-ANON">
<front>
<title>Kerberos Anonymity Support</title>
<author initials="L." surname="Zhu">
<organization></organization>
</author>
<author initials="P." surname="Leach">
<organization></organization>
</author>
<date year="2007"/>
</front>
<seriesInfo name="internet-draft"
value="draft-ietf-krb-wg-anon-04.txt"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:11:05 |