diff options
Diffstat (limited to 'doc/standardisation/draft-zhu-ws-kerb-01.txt')
| -rw-r--r-- | doc/standardisation/draft-zhu-ws-kerb-01.txt | 505 |
1 files changed, 0 insertions, 505 deletions
diff --git a/doc/standardisation/draft-zhu-ws-kerb-01.txt b/doc/standardisation/draft-zhu-ws-kerb-01.txt deleted file mode 100644 index 7fa7075d3..000000000 --- a/doc/standardisation/draft-zhu-ws-kerb-01.txt +++ /dev/null @@ -1,505 +0,0 @@ - - -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] - - |