--- 1/draft-ietf-kitten-sasl-saml-ec-05.txt 2013-01-29 23:21:36.823876799 +0100 +++ 2/draft-ietf-kitten-sasl-saml-ec-06.txt 2013-01-29 23:21:36.875876008 +0100 @@ -1,19 +1,19 @@ Network Working Group S. Cantor Internet-Draft Shibboleth Consortium Intended status: Standards Track S. Josefsson -Expires: June 6, 2013 SJD AB - December 3, 2012 +Expires: August 2, 2013 SJD AB + January 29, 2013 SAML Enhanced Client SASL and GSS-API Mechanisms - draft-ietf-kitten-sasl-saml-ec-05.txt + draft-ietf-kitten-sasl-saml-ec-06.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 @@ -30,25 +30,25 @@ 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 June 6, 2013. + This Internet-Draft will expire on August 2, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 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 @@ -63,43 +63,43 @@ 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 10 4.4. User Authentication with Identity Provider . . . . . . . . 10 4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 10 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 10 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 12 5.1. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 12 5.2. Session Key Derivation . . . . . . . . . . . . . . . . . . 13 - 5.2.1. Generated by Identity Provider . . . . . . . . . . . . 13 - 5.2.2. Derived Session Keys . . . . . . . . . . . . . . . . . 14 - 5.3. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 14 + 5.2.1. Generated by Identity Provider . . . . . . . . . . . . 14 + 5.2.2. Alternate Key Derivation Mechanisms . . . . . . . . . 14 + 5.3. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 15 5.4. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 15 5.5. GSS-API Principal Name Types for SAML EC . . . . . . . . . 15 5.5.1. User Naming Considerations . . . . . . . . . . . . . . 16 5.5.2. Service Naming Considerations . . . . . . . . . . . . 17 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 26 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 26 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 28 8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 9.2. Normative References for GSS-API Implementers . . . . . . 30 9.3. Informative References . . . . . . . . . . . . . . . . . . 31 - Appendix A. Appendix A. XML Schema . . . . . . . . . . . . . . . 32 - Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 34 - Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 + Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 32 + Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 33 + Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 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. @@ -476,99 +476,110 @@ described by [SAMLECP20]. 5.2. Session Key Derivation Some GSS-API features (discussed in the following sections) require a session key be established as a result of security context establishment. In the common case of a "bearer" assertion in SAML, a mechanism is defined to communicate a key to both parties via the identity provider. In other cases such as assertions based on "holder of key" confirmation bound to a client-controlled key, there - may be additional methods supported. + may be additional methods defined in the future, and extension points + are provided for this purpose. Information defining or describing the session key, or a process for - deriving one, is communicated using a element, - defined by the XML schema in Appendix A. This element can be used as - a SOAP header block or as an extension within a SAML assertion, - depending on the context of communication. The content of the - element further depends on the specific use in the mechanism and is - discussed below. + deriving one, is communicated between the initiator and acceptor + using a element, defined by the XML schema in + Appendix A. This element is a SOAP header block. The content of the + element further depends on the specific use in the mechanism. The + Algorithm XML attribute identifies a mechanism for key derivation. + It is omitted to identify the use of an Identity Provider-generated + key (see following section) or will contain a URI value identifying a + derivation mechanism defined outside this specification. Each header + block's mustUnderstand and actor attributes MUST be set to "1" and + "http://schemas.xmlsoap.org/soap/actor/next" respectively. + + In the acceptor's first response message containing its SAML request, + one or more SOAP header blocks MUST be included. + The element MUST contain one or more elements containing + the name of a supported encryption type defined in accordance with + [RFC3961]. + + In the final client response message, a single + SOAP header block MUST be included. A single element MUST + be included to identify the chosen encryption type used by the + initiator. + + All parties MUST support the "aes128-cts-hmac-sha1-96" encryption + type, defined by [RFC3962]. + + Further details depend on the mechanism used, one of which is + described in the following section. 5.2.1. Generated by Identity Provider The identity provider, if issuing a bearer assertion for use with this mechanism, SHOULD provide a generated key for use by the initiator and acceptor. This key is used as the protocol key for a specific encryption type defined in accordance with [RFC3961]. The key is base64-encoded and placed inside a - element. + element. The identity provider does not participate in the selection + of the encryption type and simply generates enough pseudorandom bits + to supply key material to the other parties. - Regardless of the encryption type chosen, the identity provider MUST - produce a key by generating sufficient pseudorandom bits and - executing the chosen encryption type's random-to-key function over - the input. The result of that function is the key to be encoded and - placed inside the element. + The resulting element is placed within the + element of the assertion issued. A copy of the element + is also added as a SOAP header block in the response from the + identity provider to the client. - The resulting element is placed within a - element whose EncType XML attribute is set to the - appropriate encryption type name used. The - element is placed within the element of the assertion - issued. A copy of the element is also added as a SOAP header block - in the response from the identity provider to the client. + 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: - The identity provider is left to determine which encryption type the - parties should use. It is unspecified how the initiator's - capabilities are determined in this respect, but the acceptor MAY - indicate the encryption types it supports in its SAML metadata by - means of a element in a - element, and an identity provider may leverage this information. The - omission of the element's Algorithm XML attribute represents support - for the key generation mechanism described in this section. Zero or - more elements may appear, each contaning an - encryption type name supported. + + aes128-cts-hmac-sha1-96 + - All parties MUST support the "aes128-cts-hmac-sha1-96" encryption - type, defined by [RFC3962]. + 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 key. -5.2.2. Derived Session Keys +5.2.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 may be supported. For - example, if the server has an elliptic curve public key, the ECDH-ES - key agreement algorithm, as defined in [XMLENC11] may be used. - - In such a case, the initiator communicates to the acceptor what - algorithm to use and any inputs to the process using a SOAP header block containing a element, - added to the client response to the acceptor. The - element will typically contain an or element conforming to [XMLENC11]. The - element may also contain other extensible content related to key - establishment mechanisms defined elsewhere. - - As in the method described above, the outer element's EncType XML - attribute is set to the encryption type name from the registry - established by [RFC3961]. + 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 + establishment. - Regardless of the encryption type chosen, initiator and acceptor MUST - execute the chosen 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. + 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.3. Per-Message Tokens The per-message tokens SHALL be the same as those for the Kerberos V5 GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections). The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail - (GSS_C_CONF_FLAG) security context flags are always set to TRUE. + (GSS_C_INTEG_FLAG) security context flags are always set to TRUE. The "protocol key" SHALL be a key established in a manner described in the previous section. "Specific keys" are then derived as usual as described in Section 2 of [RFC4121], [RFC3961], and [RFC3962]. The terms "protocol key" and "specific key" are Kerberos V5 terms [RFC3961]. SAML20EC is PROT_READY as soon as the SAML response message has been seen. @@ -714,70 +725,87 @@ The initial response is "n,," which signals that channel binding is not used, there is no authorization identity, and the client does not support key-based confirmation or want mutual authentication. Step 5: Server sends a challenge to client in the form of a SOAP envelope containing its SAML : -PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy -LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN -TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v -cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVxdWVzdCB4 -bWxuczpwYW9zPSJ1cm46bGliZXJ0eTpwYW9zOjIwMDMtMDgiDQogICAgICBtZXNzYWdlSUQ9 -ImMzYTRmOGI5YzJkIiBTOm11c3RVbmRlcnN0YW5kPSIxIg0KICAgICAgUzphY3Rvcj0iaHR0 -cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgcmVzcG9u -c2VDb25zdW1lclVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIg0KICAgICAgc2Vydmlj -ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiLz4NCiAg -ICA8ZWNwOlJlcXVlc3QNCiAgICAgIHhtbG5zOmVjcD0idXJuOm9hc2lzOm5hbWVzOnRjOlNB -TUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiDQogICAgICBTOmFjdG9yPSJodHRwOi8vc2NoZW1h -cy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiDQogICAgICBTOm11c3RVbmRlcnN0YW5k -PSIxIiBQcm92aWRlck5hbWU9IkphYmJlciBhdCBleGFtcGxlLmNvbSI+DQogICAgICA8c2Ft -bDpJc3N1ZXI+aHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tPC9zYW1sOklzc3Vlcj4NCiAgICA8 -L2VjcDpSZXF1ZXN0Pg0KICA8L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpB -dXRoblJlcXVlc3QNCiAgICAgIElEPSJjM2E0ZjhiOWMyZCIgVmVyc2lvbj0iMi4wIiBJc3N1 -ZUluc3RhbnQ9IjIwMDctMTItMTBUMTE6Mzk6MzRaIg0KICAgICAgUHJvdG9jb2xCaW5kaW5n -PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YmluZGluZ3M6UEFPUyINCiAgICAgIEFz -c2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0iaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tIj4N -CiAgICAgIDxzYW1sOklzc3VlciB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN -TDoyLjA6YXNzZXJ0aW9uIj4NCiAgICAgICBodHRwczovL3htcHAuZXhhbXBsZS5jb20NCiAg -ICAgIDwvc2FtbDpJc3N1ZXI+DQogICAgICA8c2FtbHA6TmFtZUlEUG9saWN5IEFsbG93Q3Jl -YXRlPSJ0cnVlIg0KICAgICAgICBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIu -MDpuYW1laWQtZm9ybWF0OnBlcnNpc3RlbnQiLz4NCiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRB -dXRobkNvbnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPg0KICAgICAgIDxzYW1sOkF1dGhuQ29u -dGV4dENsYXNzUmVmPg0KICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpj -bGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQogICAgICAgPC9zYW1sOkF1dGhu -Q29udGV4dENsYXNzUmVmPg0KICAgICAgPC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQ+ -IA0KICAgIDwvc2FtbHA6QXV0aG5SZXF1ZXN0Pg0KICA8L1M6Qm9keT4NCjwvUzpFbnZlbG9w -ZT4NCg== + PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT + QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h + bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj + aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K + ICAgIDxwYW9zOlJlcXVlc3QgeG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoy + MDAzLTA4IgogICAgICBtZXNzYWdlSUQ9ImMzYTRmOGI5YzJkIiBTOm11c3RVbmRl + cnN0YW5kPSIxIgogICAgICBTOmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2Fw + Lm9yZy9zb2FwL2FjdG9yL25leHQiCiAgICAgIHJlc3BvbnNlQ29uc3VtZXJVUkw9 + InhtcHBAeG1wcC5leGFtcGxlLmNvbSIKICAgICAgc2VydmljZT0idXJuOm9hc2lz + Om5hbWVzOnRjOlNBTUw6Mi4wOnByb2ZpbGVzOlNTTzplY3AiLz4KICAgIDxlY3A6 + UmVxdWVzdAogICAgICB4bWxuczplY3A9InVybjpvYXNpczpuYW1lczp0YzpTQU1M + OjIuMDpwcm9maWxlczpTU086ZWNwIgogICAgICBTOmFjdG9yPSJodHRwOi8vc2No + ZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25leHQiCiAgICAgIFM6bXVzdFVu + ZGVyc3RhbmQ9IjEiIFByb3ZpZGVyTmFtZT0iSmFiYmVyIGF0IGV4YW1wbGUuY29t + Ij4KICAgICAgPHNhbWw6SXNzdWVyPmh0dHBzOi8veG1wcC5leGFtcGxlLmNvbTwv + c2FtbDpJc3N1ZXI+CiAgICA8L2VjcDpSZXF1ZXN0PgogICAgPHNhbWxlYzpTZXNz + aW9uS2V5IHhtbG5zOnNhbWxlYz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzYW1s + ZWMiCiAgICAgIHhtbG5zOlM9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3Nv + YXAvZW52ZWxvcGUvIgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIgogICAgICBT + OmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25l + eHQiPgogICAgICA8c2FtbGVjOkVuY1R5cGU+YWVzMTI4LWN0cy1obWFjLXNoYTEt + OTY8L3NhbWxlYzpFbmNUeXBlPgogICAgICA8c2FtbGVjOkVuY1R5cGU+YWVzMjU2 + LWN0cy1obWFjLXNoYTEtOTY8L3NhbWxlYzpFbmNUeXBlPgogICAgPHNhbWxlYzpT + ZXNzaW9uS2V5PgogIDwvUzpIZWFkZXI+CiAgPFM6Qm9keT4KICAgIDxzYW1scDpB + dXRoblJlcXVlc3QKICAgICAgSUQ9ImMzYTRmOGI5YzJkIiBWZXJzaW9uPSIyLjAi + IElzc3VlSW5zdGFudD0iMjAwNy0xMi0xMFQxMTozOTozNFoiCiAgICAgIFByb3Rv + Y29sQmluZGluZz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmJpbmRpbmdz + OlBBT1MiCiAgICAgIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0ieG1wcEB4 + bXBwLmV4YW1wbGUuY29tIj4KICAgICAgPHNhbWw6SXNzdWVyIHhtbG5zOnNhbWw9 + InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPgogICAgICAg + aHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tCiAgICAgIDwvc2FtbDpJc3N1ZXI+CiAg + ICAgIDxzYW1scDpOYW1lSURQb2xpY3kgQWxsb3dDcmVhdGU9InRydWUiCiAgICAg + ICAgRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6bmFtZWlkLWZv + cm1hdDpwZXJzaXN0ZW50Ii8+CiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRBdXRobkNv + bnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPgogICAgICAgPHNhbWw6QXV0aG5Db250 + ZXh0Q2xhc3NSZWY+CiAgICAgICB1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6 + YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydAogICAgICAgPC9z + YW1sOkF1dGhuQ29udGV4dENsYXNzUmVmPgogICAgICA8L3NhbWxwOlJlcXVlc3Rl + ZEF1dGhuQ29udGV4dD4gCiAgICA8L3NhbWxwOkF1dGhuUmVxdWVzdD4KICA8L1M6 + Qm9keT4KPC9TOkVudmVsb3BlPg== The Base64 [RFC4648] decoded envelope: https://xmpp.example.com + + aes128-cts-hmac-sha1-96 + aes256-cts-hmac-sha1-96 + https://xmpp.example.com Step 7: IdP responds to client with a SOAP response containing a SAML containing a short-lived SSO assertion (shown as an - encrypted variant in the example). A session key is included in the - assertion and in a header for the client. + encrypted variant in the example). A generated key is included in + the assertion and in a header for the client. - - + 3w1wSBKUosRLsU69xGK7dg== - https://saml.example.org - + Step 8: Client sends SOAP envelope containing the SAML as a response to the SASL server's challenge: -PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy -LjA6YXNzZXJ0aW9uIg0KICAgIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN -TDoyLjA6cHJvdG9jb2wiDQogICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v -cmcvc29hcC9lbnZlbG9wZS8iPg0KICA8UzpIZWFkZXI+DQogICAgPHBhb3M6UmVzcG9uc2Ug -eG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoyMDAzLTA4Ig0KICAgICAgUzphY3Rvcj0i -aHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9hY3Rvci9uZXh0Ig0KICAgICAgUzpt -dXN0VW5kZXJzdGFuZD0iMSIgcmVmVG9NZXNzYWdlSUQ9IjZjM2E0ZjhiOWMyZCIvPg0KICA8 -L1M6SGVhZGVyPg0KICA8UzpCb2R5Pg0KICAgIDxzYW1scDpSZXNwb25zZSBJRD0iZDQzaDk0 -cjM4OTMwOXIiIFZlcnNpb249IjIuMCINCiAgICAgICAgSXNzdWVJbnN0YW50PSIyMDA3LTEy -LTEwVDExOjQyOjM0WiIgSW5SZXNwb25zZVRvPSJjM2E0ZjhiOWMyZCINCiAgICAgICAgRGVz -dGluYXRpb249Imh0dHBzOi8veG1wcC5leGFtcGxlLmNvbSI+DQogICAgICA8c2FtbDpJc3N1 -ZXI+aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnPC9zYW1sOklzc3Vlcj4NCiAgICAgIDxzYW1s -cDpTdGF0dXM+DQogICAgICAgIDxzYW1scDpTdGF0dXNDb2RlDQogICAgICAgICAgICBWYWx1 -ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnN0YXR1czpTdWNjZXNzIi8+DQogICAg -ICA8L3NhbWxwOlN0YXR1cz4NCiAgICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4NCiAg -ICAgICAgPCEtLSBjb250ZW50cyBlbGlkZWQgLS0+DQogICAgICA8L3NhbWw6RW5jcnlwdGVk -QXNzZXJ0aW9uPg0KICAgIDwvc2FtbHA6UmVzcG9uc2U+DQogIDwvUzpCb2R5Pg0KPC9TOkVu -dmVsb3BlPg0K + PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT + QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h + bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj + aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K + ICAgIDxwYW9zOlJlc3BvbnNlIHhtbG5zOnBhb3M9InVybjpsaWJlcnR5OnBhb3M6 + MjAwMy0wOCIKICAgICAgUzphY3Rvcj0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5v + cmcvc29hcC9hY3Rvci9uZXh0IgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIiBy + ZWZUb01lc3NhZ2VJRD0iNmMzYTRmOGI5YzJkIi8+CiAgICA8c2FtbGVjOlNlc3Np + b25LZXkgeG1sbnM6c2FtbGVjPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNhbWxl + YyIKICAgICAgeG1sbnM6Uz0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29h + cC9lbnZlbG9wZS8iCiAgICAgIFM6bXVzdFVuZGVyc3RhbmQ9IjEiCiAgICAgIFM6 + YWN0b3I9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvYWN0b3IvbmV4 + dCI+CiAgICAgIDxzYW1sZWM6RW5jVHlwZT5hZXMxMjgtY3RzLWhtYWMtc2hhMS05 + Njwvc2FtbGVjOkVuY1R5cGU+CiAgICA8c2FtbGVjOlNlc3Npb25LZXk+CiAgPC9T + OkhlYWRlcj4KICA8UzpCb2R5PgogICAgPHNhbWxwOlJlc3BvbnNlIElEPSJkNDNo + OTRyMzg5MzA5ciIgVmVyc2lvbj0iMi4wIgogICAgICAgIElzc3VlSW5zdGFudD0i + MjAwNy0xMi0xMFQxMTo0MjozNFoiIEluUmVzcG9uc2VUbz0iYzNhNGY4YjljMmQi + CiAgICAgICAgRGVzdGluYXRpb249InhtcHBAeG1wcC5leGFtcGxlLmNvbSI+CiAg + ICAgIDxzYW1sOklzc3Vlcj5odHRwczovL3NhbWwuZXhhbXBsZS5vcmc8L3NhbWw6 + SXNzdWVyPgogICAgICA8c2FtbHA6U3RhdHVzPgogICAgICAgIDxzYW1scDpTdGF0 + dXNDb2RlCiAgICAgICAgICAgIFZhbHVlPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FN + TDoyLjA6c3RhdHVzOlN1Y2Nlc3MiLz4KICAgICAgPC9zYW1scDpTdGF0dXM+CiAg + ICAgIDxzYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgICAgICA8IS0tIGNvbnRl + bnRzIGVsaWRlZCwgY29weSBvZiBzYW1sZWM6R2VuZXJhdGVkS2V5IGluIEFkdmlj + ZSAtLT4KICAgICAgPC9zYW1sOkVuY3J5cHRlZEFzc2VydGlvbj4KICAgIDwvc2Ft + bHA6UmVzcG9uc2U+CiAgPC9TOkJvZHk+CjwvUzpFbnZlbG9wZT4K The Base64 [RFC4648] decoded envelope: + + aes128-cts-hmac-sha1-96 + https://saml.example.org - + - Step 9: Server informs client of successful authentication: Step 9 (alt): Server informs client of failed authentication: @@ -1154,25 +1191,20 @@ [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, July 2010. [RFC6680] Williams, N., Johansson, L., Hartman, S., and S. Josefsson, "Generic Security Service Application Programming Interface (GSS-API) Naming Extensions", RFC 6680, August 2012. - [XMLENC11] - Hirsch, F. and T. Roessler, "XML Encryption Syntax and - Processing Version 1.1", W3C Editor's Draft W3C.xmlenc- - core-11-ed, September 2012. - 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. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext @@ -1183,21 +1215,21 @@ [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows", RFC 4559, 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, . -Appendix A. Appendix A. XML Schema +Appendix A. XML Schema The following schema formally defines the "urn:ietf:params:xml:ns:samlec" namespace used in this document, in conformance with [W3C.REC-xmlschema-1] While XML validation is optional, the schema that follows is the normative definition of the constructs it defines. Where the schema differs from any prose in this specification, the schema takes precedence. - - - - - - - - - - - - - - - + + - + + + + + + + + + + + + + + + Appendix B. Acknowledgments The authors would like to thank Klaas Wierenga, Sam Hartman, Nico Williams, and Jim Basney for their contributions. Appendix C. Changes This section to be removed prior to publication. + o 06, simplified session key schema, moved responsibility for + random-to-key to the endpoints, and defined advertisement of + session key algorithm and enctypes by acceptor + o 05, revised session key material, added requirement for random-to- key, revised XML schema to capture enctype name, updated GSS naming reference o 04, stripped down the session key material to simplify it, and define an IdP-brokered keying approach, moved session key XML constructs from OASIS draft into this one o 03, added TLS key export as a session key option, revised GSS naming material based on list discussion