--- 1/draft-ietf-kitten-sasl-saml-ec-14.txt 2017-04-25 06:13:10.879948195 -0700 +++ 2/draft-ietf-kitten-sasl-saml-ec-15.txt 2017-04-25 06:13:10.943949709 -0700 @@ -1,106 +1,106 @@ Network Working Group S. Cantor Internet-Draft Shibboleth Consortium Intended status: Standards Track S. Josefsson -Expires: April 12, 2016 SJD AB - October 10, 2015 +Expires: October 26, 2017 SJD AB + April 24, 2017 SAML Enhanced Client SASL and GSS-API Mechanisms - draft-ietf-kitten-sasl-saml-ec-14.txt + draft-ietf-kitten-sasl-saml-ec-15.txt Abstract Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on April 12, 2016. + This Internet-Draft will expire on October 26, 2017. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . . 7 - 4. SAML Enhanced Client SASL Mechanism Specification . . . . . . 10 - 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 10 - 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 11 - 4.4. User Authentication with Identity Provider . . . . . . . . 11 - 4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 11 - 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 12 - 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 13 - 5.1. GSS-API Credential Delegation . . . . . . . . . . . . . . 13 - 5.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 14 - 5.3. Session Key Derivation . . . . . . . . . . . . . . . . . . 15 - 5.3.1. Generated by Identity Provider . . . . . . . . . . . . 15 - 5.3.2. Alternate Key Derivation Mechanisms . . . . . . . . . 16 - 5.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 17 - 5.5. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 17 - 5.6. GSS-API Principal Name Types for SAML EC . . . . . . . . . 17 - 5.6.1. User Naming Considerations . . . . . . . . . . . . . . 18 - 5.6.2. Service Naming Considerations . . . . . . . . . . . . 19 - 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 - 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 28 - 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 28 - 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 29 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 - 8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 30 - 8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 30 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 - 9.2. Normative References for GSS-API Implementers . . . . . . 32 - 9.3. Informative References . . . . . . . . . . . . . . . . . . 33 - Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 35 - Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 37 - Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 38 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . 5 + 4. SAML Enhanced Client SASL Mechanism Specification . . . . . . 8 + 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 8 + 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 9 + 4.4. User Authentication with Identity Provider . . . . . . . 9 + 4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 9 + 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . 10 + 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 10 + 5.1. GSS-API Credential Delegation . . . . . . . . . . . . . . 11 + 5.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 12 + 5.3. Session Key Derivation . . . . . . . . . . . . . . . . . 12 + 5.3.1. Generated by Identity Provider . . . . . . . . . . . 13 + 5.3.2. Alternate Key Derivation Mechanisms . . . . . . . . . 14 + 5.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . 14 + 5.5. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . 15 + 5.6. GSS-API Principal Name Types for SAML EC . . . . . . . . 15 + 5.6.1. User Naming Considerations . . . . . . . . . . . . . 16 + 5.6.2. Service Naming Considerations . . . . . . . . . . . . 17 + 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . 26 + 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . 26 + 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 27 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 27 + 8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . 27 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 28 + 9.2. Normative References for GSS-API Implementers . . . . . . 29 + 9.3. Informative References . . . . . . . . . . . . . . . . . 30 + Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 31 + Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 33 + Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 33 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] is a modular specification that provides various means for a user to be identified to a relying party (RP) through the exchange of (typically signed) assertions issued by an identity provider (IdP). It includes a number of protocols, protocol bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles [OASIS.saml-profiles-2.0-os] designed for different use cases. @@ -323,22 +323,22 @@ Figure 2: Authentication flow 4. SAML Enhanced Client SASL Mechanism Specification Based on the previous figures, the following operations are defined by the SAML SASL mechanism: 4.1. Advertisement To advertise that a server supports this mechanism, during - application session initiation, it displays the name "SAML20EC" - and/or "SAML20EC-PLUS" in the list of supported SASL mechanisms. + application session initiation, it displays the name "SAML20EC" and/ + or "SAML20EC-PLUS" in the list of supported SASL mechanisms. In accordance with [RFC5801] the "-PLUS" variant indicates that the server supports channel binding and would be selected by a client with that capability. 4.2. Initiation A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If supported by the application protocol, the client MAY include an initial response, otherwise it waits until the server has issued an @@ -600,47 +600,47 @@ MUST encrypt the assertion (implying that it MUST have the means to do so, typically knowledge of a key associated with the RP). If multiple assertions are issued (allowed, but not typical), the element need only be included in one of the assertions issued for use by the relying party. A copy of the element is also added as a SOAP header block in the response from the identity provider to the client (and then removed when constructing the response to the acceptor). - If this mechanism is used by the initiator, then the SOAP header block attached to the final client response - message will identify this via the omission of the Algorithm + If this mechanism is used by the initiator, then the + SOAP header block attached to the final client + response message will identify this via the omission of the Algorithm attribute and will identify the chosen encryption type using the element: 17 Both the initiator and acceptor MUST execute the chosen encryption type's random-to-key function over the pseudorandom value provided by the element. The result of that function is used as the protocol and session key. Support for subkeys from the initiator or acceptor is not specified. 5.3.2. Alternate Key Derivation Mechanisms In the event that a client is proving possession of a secret or private key, a formal key agreement algorithm might be supported. - This specification does not define such a mechanism, but the element is extensible to allow for future work in this - space by means of the Algorithm attribute and an optional child element to carry extensible content related to key + This specification does not define such a mechanism, but the + element is extensible to allow for future work in + this space by means of the Algorithm attribute and an optional + child element to carry extensible content related to key establishment. However a key is derived, the element will identify the chosen encrytion type, and both the initiator and acceptor MUST execute the encryption type's random-to-key function over the result of the key agreement or derivation process. The result of that function is used as the protocol key. 5.4. Per-Message Tokens @@ -721,22 +721,22 @@ constructed as a UTF-8 string in the following form: name = element-value "!" Format "!" NameQualifier "!" SPNameQualifier "!" SPProvidedID The "element-value" token refers to the content of the element. The other tokens refer to the identically named XML attributes defined for use with the element. If an attribute is not present, which is common, it is omitted (i.e., replaced with the empty string). The Format value is never omitted; if not present, - the SAML-equivalent value of - "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" is used. + the SAML-equivalent value of "urn:oasis:names:tc:SAML:1.1:nameid- + format:unspecified" is used. Not all SAML assertions contain a element. In the event that no such element is present, including the exceptional cases of a element or a element that cannot be decrypted, the GSS_C_NT_ANONYMOUS name type MUST be used for the initiator name. As noted in the previous section, it is expected that most applications able to rely on SAML authentication would make use of naming extensions to obtain additional information about the user @@ -1163,38 +1164,38 @@ Registrant Contact: the IESG 9. References 9.1. Normative References [OASIS.saml-bindings-2.0-os] Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Maler, "Bindings for the OASIS Security Assertion Markup - Language (SAML) V2.0", OASIS - Standard saml-bindings-2.0-os, March 2005. + Language (SAML) V2.0", OASIS Standard saml-bindings- + 2.0-os, March 2005. [OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core- 2.0-os, March 2005. [OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard OASIS.saml-profiles-2.0-os, March 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ - RFC2119, March 1997, + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, . [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, DOI 10.17487/RFC2617, June 1999, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, @@ -1204,67 +1205,67 @@ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ - RFC5246, August 2008, + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, . [SAMLECP20] Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile Version 2.0", OASIS Committee Specification OASIS.sstc- saml-ecp-v2.0-cs01, August 2013. [W3C.soap11] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", W3C Note soap11, May 2000, . 9.2. Normative References for GSS-API Implementers [RFC2743] Linn, J., "Generic Security Service Application Program - Interface Version 2, Update 1", RFC 2743, DOI 10.17487/ - RFC2743, January 2000, + Interface Version 2, Update 1", RFC 2743, + DOI 10.17487/RFC2743, January 2000, . [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for - Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, - February 2005, . + Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February + 2005, . [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) - Encryption for Kerberos 5", RFC 3962, DOI 10.17487/ - RFC3962, February 2005, + Encryption for Kerberos 5", RFC 3962, + DOI 10.17487/RFC3962, February 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, DOI 10.17487/RFC4121, July 2005, . [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application - Program Interface (GSS-API)", RFC 4401, DOI 10.17487/ - RFC4401, February 2006, + Program Interface (GSS-API)", RFC 4401, + DOI 10.17487/RFC4401, February 2006, . [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program - Interface (GSS-API) Mechanism", RFC 4402, DOI 10.17487/ - RFC4402, February 2006, + Interface (GSS-API) Mechanism", RFC 4402, + DOI 10.17487/RFC4402, February 2006, . [RFC5554] Williams, N., "Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings", RFC 5554, DOI 10.17487/RFC5554, May 2009, . [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms @@ -1281,42 +1282,42 @@ [RFC7056] Hartman, S. and J. Howlett, "Name Attributes for the GSS- API Extensible Authentication Protocol (EAP) Mechanism", RFC 7056, DOI 10.17487/RFC7056, December 2013, . 9.3. Informative References [OASIS.saml-metadata-2.0-os] Cantor, S., Moreh, J., Philpott, R., and E. Maler, "Metadata for the Security Assertion Markup Language - (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, - March 2005. + (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March + 2005. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext - Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ - RFC2616, June 1999, + Transfer Protocol -- HTTP/1.1", RFC 2616, + DOI 10.17487/RFC2616, June 1999, . [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, October 2004, . [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, . [W3C.REC-xmlschema-1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, - "XML Schema Part 1: Structures", W3C REC-xmlschema-1, - May 2001, . + "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May + 2001, . [WSS-SAML] Monzillo, R., "Web Services Security SAML Token Profile Version 1.1.1", OASIS Standard OASIS.wss-SAMLTokenProfile, May 2012. Appendix A. XML Schema The following schema formally defines the "urn:ietf:params:xml:ns:samlec" namespace used in this document, in