mirror of
https://github.com/samba-team/samba.git
synced 2024-12-23 17:34:34 +03:00
7055827b8f
This makes it clearer that we always want to do heimdal changes via the lorikeet-heimdal repository. Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz> Autobuild-User(master): Joseph Sutton <jsutton@samba.org> Autobuild-Date(master): Wed Jan 19 21:41:59 UTC 2022 on sn-devel-184
506 lines
19 KiB
Plaintext
506 lines
19 KiB
Plaintext
|
||
|
||
NETWORK WORKING GROUP L. Zhu
|
||
Internet-Draft Microsoft Corporation
|
||
Updates: 4120 (if approved) October 2006
|
||
Intended status: Standards Track
|
||
Expires: April 4, 2007
|
||
|
||
|
||
Kerberos for Web Services
|
||
draft-zhu-ws-kerb-01
|
||
|
||
Status of this Memo
|
||
|
||
By submitting this Internet-Draft, each author represents that any
|
||
applicable patent or other IPR claims of which he or she is aware
|
||
have been or will be disclosed, and any of which he or she becomes
|
||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||
|
||
Internet-Drafts are working documents of the Internet Engineering
|
||
Task Force (IETF), its areas, and its working groups. Note that
|
||
other groups may also distribute working documents as Internet-
|
||
Drafts.
|
||
|
||
Internet-Drafts are draft documents valid for a maximum of six months
|
||
and may be updated, replaced, or obsoleted by other documents at any
|
||
time. It is inappropriate to use Internet-Drafts as reference
|
||
material or to cite them other than as "work in progress."
|
||
|
||
The list of current Internet-Drafts can be accessed at
|
||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||
|
||
The list of Internet-Draft Shadow Directories can be accessed at
|
||
http://www.ietf.org/shadow.html.
|
||
|
||
This Internet-Draft will expire on April 4, 2007.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2006).
|
||
|
||
Abstract
|
||
|
||
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, Kerberos is suitable for securing
|
||
communication between the client and web services over the Internet.
|
||
|
||
|
||
|
||
|
||
Zhu Expires April 4, 2007 [Page 1]
|
||
|
||
Internet-Draft WS-KERB October 2006
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
|
||
3. GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . . 3
|
||
4. Addresses in Tickets . . . . . . . . . . . . . . . . . . . . . 6
|
||
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
|
||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
|
||
8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
|
||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||
Intellectual Property and Copyright Statements . . . . . . . . . . 9
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Zhu Expires April 4, 2007 [Page 2]
|
||
|
||
Internet-Draft WS-KERB October 2006
|
||
|
||
|
||
1. Introduction
|
||
|
||
The Kerberos [RFC4120] pre-authentication framework [KRB-PAFW]
|
||
promises minimal or no exposure of weak client keys and strong client
|
||
authentication. The Kerberos support of anonymity [KRB-ANON]
|
||
provides for privacy. These advancements make Kerberos suitable over
|
||
the Internet.
|
||
|
||
The traditional client-push Kerberos protocol does not work well in
|
||
the Web services environments where the KDC is not accessible to the
|
||
client, but is accessible to the web server. For example, the KDC is
|
||
commonly placed behind a firewall together with the application
|
||
server. The lack of accessibility to the KDC by the client could
|
||
also occur are when the client does not have an IP address prior to
|
||
authenticating to an access point.
|
||
|
||
Generic Security Service Application Program Interface (GSS-API)
|
||
[RFC2743] allows security mechanisms exchange arbitrary messages
|
||
between the initiator and the acceptor via the application traffic,
|
||
independent of the underlying transports. A protocol based on
|
||
[RFC4121] is thus defined to allow the GSS-API initiator to exchange
|
||
Kerberos messages with the KDC by using the GSS-API acceptor as the
|
||
proxy. The acceptor-pull model defined in this specification is
|
||
benefical for initiators with limited processing power such as mobile
|
||
devices, or when the transport layer between the initiator and the
|
||
acceptor has high network latency.
|
||
|
||
Client --------- WS-KERB proxy ---------- KDC
|
||
|
||
The Kerberos client MUST avoid exposure of long term client keys to
|
||
the GSS-API acceptor, before and after the Kerberos server is
|
||
authenticated. This can be accomplished by using Kerberos-FAST [KRB-
|
||
PAFW]. Furthermore, the initiator can use the anonymous option as
|
||
defined in Section 6.5.2 of [KRB-PAFW], to hide the client identity
|
||
from adversary who can eavesdrop the application traffic.
|
||
|
||
|
||
2. Conventions Used in This Document
|
||
|
||
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 [RFC2119].
|
||
|
||
|
||
3. GSS-API Encapsulation
|
||
|
||
The mechanism Objection Identifier (OID) for GSS-API WS-KERB, in
|
||
accordance with the mechanism proposed by [RFC4178] for negotiating
|
||
|
||
|
||
|
||
Zhu Expires April 4, 2007 [Page 3]
|
||
|
||
Internet-Draft WS-KERB October 2006
|
||
|
||
|
||
protocol variations, is id-kerberos-ws.
|
||
|
||
id-kerberos-ws ::=
|
||
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
|
||
webService(6) }
|
||
|
||
The first token of the GSS-API WS-KERB mechanism MUST have the
|
||
generic token framing described in section 3.1 of [RFC2743] with the
|
||
mechanism OID being id-kerberos-ws, and any subsequent GSS-API WS-
|
||
KERB token MUST NOT have this framing.
|
||
|
||
The GSS-API WS-KERB mechanism MUST always provide mutual
|
||
authentication, even if the initiator does not ask for it. When
|
||
mutual-authentication is performed, the GSS-API acceptor will always
|
||
send back an AP-REP, and as described later in this section this
|
||
mechanism provides integrity protection for all initiator-acceptor
|
||
proxy message exchanges.
|
||
|
||
The innerToken described in section 3.1 of [RFC2743] and subsequent
|
||
GSS-API tokens have the following formats: it starts with a two-octet
|
||
token-identifier (TOK_ID), followed by a WS-KERB message or a
|
||
Kerberos message.
|
||
|
||
|
||
Token/Message TOK_ID Value in Hex
|
||
-----------------------------------------
|
||
WS_KRB_PROXY 05 01
|
||
|
||
Only one WS-KERB specific message, namely the WS_KRB_PROXY message,
|
||
is defined in this document. The TOK_ID values for [RFC4120]
|
||
Kerberos messages are the same as those defined for the GSS-API
|
||
Kerberos mechanism [RFC4121].
|
||
|
||
The message of the WS_KRB_PROXY type is defined as a WS-KRB-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 [RFC4120].
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Zhu Expires April 4, 2007 [Page 4]
|
||
|
||
Internet-Draft WS-KERB October 2006
|
||
|
||
|
||
WS-KRB-HEADER ::= SEQUENCE {
|
||
proxy-data [1] ProxyData,
|
||
...
|
||
}
|
||
|
||
ProxyData :: = SEQUENCE {
|
||
realm [1] Realm,
|
||
cookie [3] OCTET STRING OPTIONAL,
|
||
-- opaque data, if sent by the acceptor,
|
||
-- MUST be copied by the client unchanged into
|
||
-- the next WS-KERB message.
|
||
...
|
||
}
|
||
|
||
|
||
The WS-KRB-HEADER structure and all the Kerberos messages MUST be
|
||
encoded using Abstract Syntax Notation One (ASN.1) Distinguished
|
||
Encoding Rules (DER) [X680] [X690].
|
||
|
||
The GSS-API initiator fills out the realm field in the ProxyData of
|
||
the first request with the client realm. If the client does not know
|
||
the client realm [REFERALS], it MUST fill it out using the client's
|
||
default realm name such as the realm of the client host. Typically
|
||
the Kerberos message in the first WS_KRB_PROXY message from the
|
||
client is an AS-REQ message.
|
||
|
||
Upon receipt of the WS_KRB_PROXY message, the GSS-API WS-KERB
|
||
acceptor MUST use the proxy-data in the message from the client to
|
||
locate the KDC and sends the encapsulated Kerberos message to that
|
||
KDC. Unless otherwise specified, the acceptor can locate the KDC per
|
||
Section 7.2.3.2 of [RFC4120].
|
||
|
||
In order to reduce the number of roundtrips between the initiator and
|
||
the acceptor, the acceptor SHOULD process any message exchange with
|
||
the KDC if the exchange is unauthenticated, such as client-referral
|
||
message exchange [REFERALS]. If the acceptor can not process the KDC
|
||
response by itself, for example when the knowledge of the client keys
|
||
is required, it sends back to the client the KDC reply message
|
||
encapsulated in a WS_KRB_PROXY message. The acceptor MUST fill out
|
||
the realm name whose KDC produced the response. The acceptor SHOULD
|
||
use the kdc-referrals option described in Section 6.5.2 of [KRB-PAFW]
|
||
to allow the KDC of the client's realm to obtain a service ticket
|
||
addressed to the acceptor, thus further reduce the number of
|
||
roundtrips between the GSS-API initiator and the GSS-API acceptor.
|
||
The GSS-API acceptor can send opaque data in the cookie field of the
|
||
WS-KRB-HEADER structure in the reply from the acceptor to the
|
||
initiator, in order to, for example, to facilitate state managements
|
||
on the GSS-API acceptor. The content and the encoding of the cookie
|
||
|
||
|
||
|
||
Zhu Expires April 4, 2007 [Page 5]
|
||
|
||
Internet-Draft WS-KERB October 2006
|
||
|
||
|
||
field is a local matter of the acceptor. The initiator MUST copy the
|
||
verbatim cookie from the previous acceptor response, when the cookie
|
||
is present, whenever it sends an additional WS-KRB-PROXY message to
|
||
the acceptor. The client processes the KDC response, and fills out
|
||
the realm name it believes to whom the acceptor should send the
|
||
encapsulated Kerberos message.
|
||
|
||
When the client obtains a service ticket, the initiator then sends a
|
||
KRB_AP_REQ message to the acceptor, and proceed as defined in
|
||
[RFC4121]. A GSS-API authenticator extension [GSS-EXTS] MUST be sent
|
||
by the initiator. The extension type is 2 and the content is the
|
||
ASN.1 DER encoding of the type Checksum. The checksum is performed
|
||
over all GSS-API messages as exchanged between the initiator and the
|
||
acceptor before the KRB_AP_REQ message, and in the order of the
|
||
exchange. The checksum type is the required checksum type for the
|
||
enctype of the subkey in the authenticator, the protocol key is the
|
||
authenticator subkey, and the key usage number is TBA-1. The
|
||
acceptor MUST verify this checksum in the GSS-API authenticator
|
||
extension, then respond with an AP-REP extension [GSS-EXTS]. The AP-
|
||
REP extension type is 2 and the the content is the ASN.1 DER encoding
|
||
of the type Checksum. This checksum is performed over all GSS-API
|
||
messages as exchanged between the initiator and the acceptor before
|
||
the KRB_AP_REQ message, and in the order of the exchange. The
|
||
checksum type is the required checksum type for the enctype of the
|
||
authenticator subkey in the request, and the protocol key is the
|
||
authenticator subkey, and the key usage number is TBA-2. The
|
||
initiator MUST then verify this checksum.
|
||
|
||
|
||
4. Addresses in Tickets
|
||
|
||
In WS-KERB, the machine sending requests to the KDC is the GSS-API
|
||
acceptor and not the initiator. As a result, the initiator 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 [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.
|
||
|
||
|
||
5. Security Considerations
|
||
|
||
Similar to other network access protocols, WS-KERB allows an
|
||
unauthenticated client (possibly outside the security perimeter of an
|
||
organization) to send messages that are proxied to interior servers.
|
||
|
||
|
||
|
||
|
||
Zhu Expires April 4, 2007 [Page 6]
|
||
|
||
Internet-Draft WS-KERB October 2006
|
||
|
||
|
||
In a scenario where DNS SRV RR's are being used to locate the KDC,
|
||
WS-KERB is being used, and an external attacker can modify DNS
|
||
responses to the WS-KERB proxy, there are several countermeasures to
|
||
prevent arbitrary messages from being sent to internal servers:
|
||
|
||
1. KDC port numbers can be statically configured on the WS-KERB
|
||
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.
|
||
|
||
2. The proxy can do application level sanity checking and filtering.
|
||
This countermeasure should eliminate many of the above attacks.
|
||
|
||
3. 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).
|
||
|
||
|
||
6. Acknowledgements
|
||
|
||
The acceptor-proxy idea is based on the early revisions of this
|
||
document written by Jonathan Trostle, Michael Swift, Bernard Aboba
|
||
and Glen Zorn.
|
||
|
||
The rest of the ideas mostly came from hallway conversations between
|
||
the author and Nicolas Williams.
|
||
|
||
|
||
7. IANA Considerations
|
||
|
||
There is no IANA action required for this document.
|
||
|
||
|
||
8. Normative References
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC2743] Linn, J., "Generic Security Service Application Program
|
||
Interface Version 2, Update 1", RFC 2743, January 2000.
|
||
|
||
|
||
|
||
Zhu Expires April 4, 2007 [Page 7]
|
||
|
||
Internet-Draft WS-KERB October 2006
|
||
|
||
|
||
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
|
||
Kerberos Network Authentication Service (V5)", RFC 4120,
|
||
July 2005.
|
||
|
||
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
|
||
Version 5 Generic Security Service Application Program
|
||
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
|
||
July 2005.
|
||
|
||
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
|
||
Simple and Protected Generic Security Service Application
|
||
Program Interface (GSS-API) Negotiation Mechanism",
|
||
RFC 4178, October 2005.
|
||
|
||
[KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity
|
||
Support", draft-ietf-krb-wg-anon, work in progress.
|
||
|
||
[KRB-PAFW] Zhu, etl, "Kerberos Pre-Authentication framework",
|
||
draft-ietf-krb-wg-preauth-framework, work in progress.
|
||
|
||
[GSS-EXTS] Emery, S., draft-ietf-krb-wg-gss-cb-hash-agility, work in
|
||
progess.
|
||
|
||
[REFERALS] Raeburn, K., "Generating KDC Referrals to Locate Kerberos
|
||
Realms", draft-ietf-krb-wg-kerberos-referrals, work in
|
||
progress.
|
||
|
||
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
|
||
Information technology - Abstract Syntax Notation One
|
||
(ASN.1): Specification of basic notation.
|
||
|
||
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
|
||
Information technology - ASN.1 encoding Rules:
|
||
Specification of Basic Encoding Rules (BER), Canonical
|
||
Encoding Rules (CER) and Distinguished Encoding Rules
|
||
(DER).
|
||
|
||
|
||
Author's Address
|
||
|
||
Larry Zhu
|
||
Microsoft Corporation
|
||
One Microsoft Way
|
||
Redmond, WA 98052
|
||
US
|
||
|
||
Email: lzhu@microsoft.com
|
||
|
||
|
||
|
||
|
||
|
||
Zhu Expires April 4, 2007 [Page 8]
|
||
|
||
Internet-Draft WS-KERB October 2006
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2006).
|
||
|
||
This document is subject to the rights, licenses and restrictions
|
||
contained in BCP 78, and except as set forth therein, the authors
|
||
retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at
|
||
ietf-ipr@ietf.org.
|
||
|
||
|
||
Acknowledgment
|
||
|
||
Funding for the RFC Editor function is provided by the IETF
|
||
Administrative Support Activity (IASA).
|
||
|
||
|
||
|
||
|
||
|
||
Zhu Expires April 4, 2007 [Page 9]
|
||
|
||
|