draft-ietf-kitten-sasl-saml-ec-12.txt   draft-ietf-kitten-sasl-saml-ec-13.txt 
Network Working Group S. Cantor Network Working Group S. Cantor
Internet-Draft Shibboleth Consortium Internet-Draft Shibboleth Consortium
Intended status: Standards Track S. Josefsson Intended status: Standards Track S. Josefsson
Expires: July 2, 2015 SJD AB Expires: March 28, 2016 SJD AB
December 29, 2014 September 25, 2015
SAML Enhanced Client SASL and GSS-API Mechanisms SAML Enhanced Client SASL and GSS-API Mechanisms
draft-ietf-kitten-sasl-saml-ec-12.txt draft-ietf-kitten-sasl-saml-ec-13.txt
Abstract Abstract
Security Assertion Markup Language (SAML) 2.0 is a generalized Security Assertion Markup Language (SAML) 2.0 is a generalized
framework for the exchange of security-related information between framework for the exchange of security-related information between
asserting and relying parties. Simple Authentication and Security asserting and relying parties. Simple Authentication and Security
Layer (SASL) and the Generic Security Service Application Program Layer (SASL) and the Generic Security Service Application Program
Interface (GSS-API) are application frameworks to facilitate an Interface (GSS-API) are application frameworks to facilitate an
extensible authentication model. This document specifies a SASL and extensible authentication model. This document specifies a SASL and
GSS-API mechanism for SAML 2.0 that leverages the capabilities of a GSS-API mechanism for SAML 2.0 that leverages the capabilities of a
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 2, 2015. This Internet-Draft will expire on March 28, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 48 skipping to change at page 2, line 48
7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 28 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 28
7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 28 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 29 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 30 8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 30
8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 30 8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31
9.2. Normative References for GSS-API Implementers . . . . . . 32 9.2. Normative References for GSS-API Implementers . . . . . . 32
9.3. Informative References . . . . . . . . . . . . . . . . . . 33 9.3. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 35
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 36 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 37
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 37 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Security Assertion Markup Language (SAML) 2.0 Security Assertion Markup Language (SAML) 2.0
[OASIS.saml-core-2.0-os] is a modular specification that provides [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) various means for a user to be identified to a relying party (RP)
through the exchange of (typically signed) assertions issued by an through the exchange of (typically signed) assertions issued by an
identity provider (IdP). It includes a number of protocols, protocol identity provider (IdP). It includes a number of protocols, protocol
bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles
[OASIS.saml-profiles-2.0-os] designed for different use cases. [OASIS.saml-profiles-2.0-os] designed for different use cases.
skipping to change at page 12, line 13 skipping to change at page 12, line 13
there are a few requirements outlined in [SAMLECP20] that make there are a few requirements outlined in [SAMLECP20] that make
reference to a response URL that is normally used to regulate where reference to a response URL that is normally used to regulate where
the client returns information to the RP. There are also security- the client returns information to the RP. There are also security-
related checks built into the profile that involve this location. related checks built into the profile that involve this location.
For compatibility with existing IdP and profile behavior, and to For compatibility with existing IdP and profile behavior, and to
provide for mutual authentication, the SASL server MUST populate the provide for mutual authentication, the SASL server MUST populate the
responseConsumerURL and AssertionConsumerServiceURL attributes with responseConsumerURL and AssertionConsumerServiceURL attributes with
its service name. The service name is used directly rather than its service name. The service name is used directly rather than
transformed into an absolute URI if it is not already one, and MUST transformed into an absolute URI if it is not already one, and MUST
be percent-encoded per [RFC3986]. The value MUST be securely be percent-encoded per [RFC3986].
associated with the SAML entityID claimed by the SASL server by the
identity provider, such as through the use of SAML metadata The value MUST be securely associated with the SAML entityID claimed
[OASIS.saml-metadata-2.0-os]. by the SASL server by the identity provider, such as through the use
of SAML metadata [OASIS.saml-metadata-2.0-os]. If metadata is used,
a SASL service's <SPSSODescriptor> role MUST contain a corresponding
<AssertionConsumerService> whose Location attribute contains the
appropriate service name, as described above. The Binding attribute
MUST be one of "urn:ietf:params:xml:ns:samlec" (RECOMMENDED) or
"urn:oasis:names:tc:SAML:2.0:bindings:PAOS" (for compatibility with
older implementations of the ECP profile in existing identity
provider software).
Finally, note that the use of HTTP status signaling between the RP Finally, note that the use of HTTP status signaling between the RP
and client mandated by [SAMLECP20] may not be applicable. and client mandated by [SAMLECP20] may not be applicable.
5. SAML EC GSS-API Mechanism Specification 5. SAML EC GSS-API Mechanism Specification
This section and its sub-sections and all normative references of it This section and its sub-sections and all normative references of it
not referenced elsewhere in this document are INFORMATIONAL for SASL not referenced elsewhere in this document are INFORMATIONAL for SASL
implementors, but they are NORMATIVE for GSS-API implementors. implementors, but they are NORMATIVE for GSS-API implementors.
skipping to change at page 19, line 34 skipping to change at page 19, line 34
mechanism as the effective AssertionConsumerService "location" mechanism as the effective AssertionConsumerService "location"
associated with the service. associated with the service.
This value is used in the construction of the responseConsumerURL and This value is used in the construction of the responseConsumerURL and
AssertionConsumerServiceURL attributes, and for eventual comparison AssertionConsumerServiceURL attributes, and for eventual comparison
and validation by the client before completing the exchange. The and validation by the client before completing the exchange. The
service name is used directly rather than transformed into an service name is used directly rather than transformed into an
absolute URI if it is not already one, and MUST be percent-encoded absolute URI if it is not already one, and MUST be percent-encoded
per [RFC3986]. The value MUST be securely associated with the SAML per [RFC3986]. The value MUST be securely associated with the SAML
entityID claimed by the server by the identity provider, such as entityID claimed by the server by the identity provider, such as
through the use of SAML metadata [OASIS.saml-metadata-2.0-os]. through the use of SAML metadata [OASIS.saml-metadata-2.0-os], as
described previously.
6. Example 6. Example
Suppose the user has an identity at the SAML IdP saml.example.org and Suppose the user has an identity at the SAML IdP saml.example.org and
a Jabber Identifier (jid) "somenode@example.com", and wishes to a Jabber Identifier (jid) "somenode@example.com", and wishes to
authenticate his XMPP connection to xmpp.example.com (and example.com authenticate his XMPP connection to xmpp.example.com (and example.com
and example.org have established a SAML-capable trust relationship). and example.org have established a SAML-capable trust relationship).
The authentication on the wire would then look something like the The authentication on the wire would then look something like the
following: following:
skipping to change at page 21, line 37 skipping to change at page 21, line 37
c2FtbDpJc3N1ZXI+CiAgICA8L2VjcDpSZXF1ZXN0PgogICAgPHNhbWxlYzpTZXNz c2FtbDpJc3N1ZXI+CiAgICA8L2VjcDpSZXF1ZXN0PgogICAgPHNhbWxlYzpTZXNz
aW9uS2V5IHhtbG5zOnNhbWxlYz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzYW1s aW9uS2V5IHhtbG5zOnNhbWxlYz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzYW1s
ZWMiCiAgICAgIHhtbG5zOlM9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3Nv ZWMiCiAgICAgIHhtbG5zOlM9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3Nv
YXAvZW52ZWxvcGUvIgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIgogICAgICBT YXAvZW52ZWxvcGUvIgogICAgICBTOm11c3RVbmRlcnN0YW5kPSIxIgogICAgICBT
OmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25l OmFjdG9yPSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2FjdG9yL25l
eHQiPgogICAgICA8c2FtbGVjOkVuY1R5cGU+MTc8L3NhbWxlYzpFbmNUeXBlPgog eHQiPgogICAgICA8c2FtbGVjOkVuY1R5cGU+MTc8L3NhbWxlYzpFbmNUeXBlPgog
ICAgICA8c2FtbGVjOkVuY1R5cGU+MTg8L3NhbWxlYzpFbmNUeXBlPgogICAgPHNh ICAgICA8c2FtbGVjOkVuY1R5cGU+MTg8L3NhbWxlYzpFbmNUeXBlPgogICAgPHNh
bWxlYzpTZXNzaW9uS2V5PgogIDwvUzpIZWFkZXI+CiAgPFM6Qm9keT4KICAgIDxz bWxlYzpTZXNzaW9uS2V5PgogIDwvUzpIZWFkZXI+CiAgPFM6Qm9keT4KICAgIDxz
YW1scDpBdXRoblJlcXVlc3QKICAgICAgSUQ9ImMzYTRmOGI5YzJkIiBWZXJzaW9u YW1scDpBdXRoblJlcXVlc3QKICAgICAgSUQ9ImMzYTRmOGI5YzJkIiBWZXJzaW9u
PSIyLjAiIElzc3VlSW5zdGFudD0iMjAwNy0xMi0xMFQxMTozOTozNFoiCiAgICAg PSIyLjAiIElzc3VlSW5zdGFudD0iMjAwNy0xMi0xMFQxMTozOTozNFoiCiAgICAg
IFByb3RvY29sQmluZGluZz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmJp IEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0ieG1wcEB4bXBwLmV4YW1wbGUu
bmRpbmdzOlBBT1MiCiAgICAgIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0i Y29tIj4KICAgICAgPHNhbWw6SXNzdWVyIHhtbG5zOnNhbWw9InVybjpvYXNpczpu
eG1wcEB4bXBwLmV4YW1wbGUuY29tIj4KICAgICAgPHNhbWw6SXNzdWVyIHhtbG5z YW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPgogICAgICAgaHR0cHM6Ly94bXBw
OnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPgog LmV4YW1wbGUuY29tCiAgICAgIDwvc2FtbDpJc3N1ZXI+CiAgICAgIDxzYW1scDpO
ICAgICAgaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tCiAgICAgIDwvc2FtbDpJc3N1 YW1lSURQb2xpY3kgQWxsb3dDcmVhdGU9InRydWUiCiAgICAgICAgRm9ybWF0PSJ1
ZXI+CiAgICAgIDxzYW1scDpOYW1lSURQb2xpY3kgQWxsb3dDcmVhdGU9InRydWUi cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6bmFtZWlkLWZvcm1hdDpwZXJzaXN0
CiAgICAgICAgRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6bmFt ZW50Ii8+CiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQgQ29tcGFy
ZWlkLWZvcm1hdDpwZXJzaXN0ZW50Ii8+CiAgICAgIDxzYW1scDpSZXF1ZXN0ZWRB aXNvbj0iZXhhY3QiPgogICAgICAgPHNhbWw6QXV0aG5Db250ZXh0Q2xhc3NSZWY+
dXRobkNvbnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPgogICAgICAgPHNhbWw6QXV0 CiAgICAgICB1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQ
aG5Db250ZXh0Q2xhc3NSZWY+CiAgICAgICB1cm46b2FzaXM6bmFtZXM6dGM6U0FN YXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydAogICAgICAgPC9zYW1sOkF1dGhuQ29u
TDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydAogICAg dGV4dENsYXNzUmVmPgogICAgICA8L3NhbWxwOlJlcXVlc3RlZEF1dGhuQ29udGV4
ICAgPC9zYW1sOkF1dGhuQ29udGV4dENsYXNzUmVmPgogICAgICA8L3NhbWxwOlJl dD4gCiAgICA8L3NhbWxwOkF1dGhuUmVxdWVzdD4KICA8L1M6Qm9keT4KPC9TOkVu
cXVlc3RlZEF1dGhuQ29udGV4dD4gCiAgICA8L3NhbWxwOkF1dGhuUmVxdWVzdD4K dmVsb3BlPgo=
ICA8L1M6Qm9keT4KPC9TOkVudmVsb3BlPgo=
</challenge> </challenge>
The Base64 [RFC4648] decoded envelope: The Base64 [RFC4648] decoded envelope:
<S:Envelope <S:Envelope
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header> <S:Header>
<paos:Request xmlns:paos="urn:liberty:paos:2003-08" <paos:Request xmlns:paos="urn:liberty:paos:2003-08"
messageID="c3a4f8b9c2d" S:mustUnderstand="1" messageID="c3a4f8b9c2d" S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:actor="http://schemas.xmlsoap.org/soap/actor/next"
skipping to change at page 22, line 35 skipping to change at page 22, line 33
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
S:mustUnderstand="1" S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next"> S:actor="http://schemas.xmlsoap.org/soap/actor/next">
<samlec:EncType>17</samlec:EncType> <samlec:EncType>17</samlec:EncType>
<samlec:EncType>18</samlec:EncType> <samlec:EncType>18</samlec:EncType>
<samlec:SessionKey> <samlec:SessionKey>
</S:Header> </S:Header>
<S:Body> <S:Body>
<samlp:AuthnRequest <samlp:AuthnRequest
ID="c3a4f8b9c2d" Version="2.0" IssueInstant="2007-12-10T11:39:34Z" ID="c3a4f8b9c2d" Version="2.0" IssueInstant="2007-12-10T11:39:34Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"
AssertionConsumerServiceURL="xmpp@xmpp.example.com"> AssertionConsumerServiceURL="xmpp@xmpp.example.com">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
https://xmpp.example.com https://xmpp.example.com
</saml:Issuer> </saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true" <samlp:NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
<samlp:RequestedAuthnContext Comparison="exact"> <samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef> <saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef> </saml:AuthnContextClassRef>
skipping to change at page 31, line 28 skipping to change at page 31, line 28
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005. 2.0-os, March 2005.
[OASIS.saml-profiles-2.0-os] [OASIS.saml-profiles-2.0-os]
Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra,
P., Philpott, R., and E. Maler, "Profiles for the OASIS P., Philpott, R., and E. Maler, "Profiles for the OASIS
Security Assertion Markup Language (SAML) V2.0", OASIS Security Assertion Markup Language (SAML) V2.0", OASIS
Standard OASIS.saml-profiles-2.0-os, March 2005. Standard OASIS.saml-profiles-2.0-os, March 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, DOI 10.17487/RFC2617, June 1999,
<http://www.rfc-editor.org/info/rfc2617>.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Security Layer (SASL)", RFC 4422, June 2006. Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
"Generic Security Service Application Program Interface Authentication and Security Layer (SASL)", RFC 4422,
(GSS-API) Authentication and Key Exchange for the Secure DOI 10.17487/RFC4422, June 2006,
Shell (SSH) Protocol", RFC 4462, May 2006. <http://www.rfc-editor.org/info/rfc4422>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and <http://www.rfc-editor.org/info/rfc5246>.
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[SAMLECP20] [SAMLECP20]
Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile
Version 2.0", OASIS Committee Specification OASIS.sstc- Version 2.0", OASIS Committee Specification OASIS.sstc-
saml-ecp-v2.0-cs01, August 2013. saml-ecp-v2.0-cs01, August 2013.
[W3C.soap11] [W3C.soap11]
Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer,
"Simple Object Access Protocol (SOAP) 1.1", W3C "Simple Object Access Protocol (SOAP) 1.1", W3C
Note soap11, May 2000, <http://www.w3.org/TR/SOAP/>. Note soap11, May 2000, <http://www.w3.org/TR/SOAP/>.
9.2. Normative References for GSS-API Implementers 9.2. Normative References for GSS-API Implementers
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, DOI 10.17487/
RFC2743, January 2000,
<http://www.rfc-editor.org/info/rfc2743>.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005. Kerberos 5", RFC 3961, DOI 10.17487/RFC3961,
February 2005, <http://www.rfc-editor.org/info/rfc3961>.
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962, February 2005. Encryption for Kerberos 5", RFC 3962, DOI 10.17487/
RFC3962, February 2005,
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform <http://www.rfc-editor.org/info/rfc3962>.
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005. DOI 10.17487/RFC4121, July 2005,
<http://www.rfc-editor.org/info/rfc4121>.
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API
Extension for the Generic Security Service Application Extension for the Generic Security Service Application
Program Interface (GSS-API)", RFC 4401, February 2006. Program Interface (GSS-API)", RFC 4401, DOI 10.17487/
RFC4401, February 2006,
<http://www.rfc-editor.org/info/rfc4401>.
[RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the
Kerberos V Generic Security Service Application Program Kerberos V Generic Security Service Application Program
Interface (GSS-API) Mechanism", RFC 4402, February 2006. Interface (GSS-API) Mechanism", RFC 4402, DOI 10.17487/
RFC4402, February 2006,
<http://www.rfc-editor.org/info/rfc4402>.
[RFC5554] Williams, N., "Clarifications and Extensions to the [RFC5554] Williams, N., "Clarifications and Extensions to the
Generic Security Service Application Program Interface Generic Security Service Application Program Interface
(GSS-API) for the Use of Channel Bindings", RFC 5554, (GSS-API) for the Use of Channel Bindings", RFC 5554,
May 2009. DOI 10.17487/RFC5554, May 2009,
<http://www.rfc-editor.org/info/rfc5554>.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
Service Application Program Interface (GSS-API) Mechanisms Service Application Program Interface (GSS-API) Mechanisms
in Simple Authentication and Security Layer (SASL): The in Simple Authentication and Security Layer (SASL): The
GS2 Mechanism Family", RFC 5801, July 2010. GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801,
July 2010, <http://www.rfc-editor.org/info/rfc5801>.
[RFC6680] Williams, N., Johansson, L., Hartman, S., and S. [RFC6680] Williams, N., Johansson, L., Hartman, S., and S.
Josefsson, "Generic Security Service Application Josefsson, "Generic Security Service Application
Programming Interface (GSS-API) Naming Extensions", Programming Interface (GSS-API) Naming Extensions",
RFC 6680, August 2012. RFC 6680, DOI 10.17487/RFC6680, August 2012,
<http://www.rfc-editor.org/info/rfc6680>.
[RFC7056] Hartman, S. and J. Howlett, "Name Attributes for the GSS- [RFC7056] Hartman, S. and J. Howlett, "Name Attributes for the GSS-
API Extensible Authentication Protocol (EAP) Mechanism", API Extensible Authentication Protocol (EAP) Mechanism",
RFC 7056, December 2013. RFC 7056, DOI 10.17487/RFC7056, December 2013,
<http://www.rfc-editor.org/info/rfc7056>.
9.3. Informative References 9.3. Informative References
[OASIS.saml-metadata-2.0-os] [OASIS.saml-metadata-2.0-os]
Cantor, S., Moreh, J., Philpott, R., and E. Maler, Cantor, S., Moreh, J., Philpott, R., and E. Maler,
"Metadata for the Security Assertion Markup Language "Metadata for the Security Assertion Markup Language
(SAML) V2.0", OASIS Standard saml-metadata-2.0-os, (SAML) V2.0", OASIS Standard saml-metadata-2.0-os,
March 2005. March 2005.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/
RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920,
October 2004, <http://www.rfc-editor.org/info/rfc3920>.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, June 2006. Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
<http://www.rfc-editor.org/info/rfc4559>.
[W3C.REC-xmlschema-1] [W3C.REC-xmlschema-1]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures", W3C REC-xmlschema-1, "XML Schema Part 1: Structures", W3C REC-xmlschema-1,
May 2001, <http://www.w3.org/TR/xmlschema-1/>. May 2001, <http://www.w3.org/TR/xmlschema-1/>.
[WSS-SAML] [WSS-SAML]
Monzillo, R., "Web Services Security SAML Token Profile Monzillo, R., "Web Services Security SAML Token Profile
Version 1.1.1", OASIS Standard OASIS.wss-SAMLTokenProfile, Version 1.1.1", OASIS Standard OASIS.wss-SAMLTokenProfile,
May 2012. May 2012.
skipping to change at page 37, line 9 skipping to change at page 38, line 9
Appendix B. Acknowledgments Appendix B. Acknowledgments
The authors would like to thank Klaas Wierenga, Sam Hartman, Nico The authors would like to thank Klaas Wierenga, Sam Hartman, Nico
Williams, Jim Basney, and Venkat Yekkirala for their contributions. Williams, Jim Basney, and Venkat Yekkirala for their contributions.
Appendix C. Changes Appendix C. Changes
This section to be removed prior to publication. This section to be removed prior to publication.
o 13, clarify SAML metadata usage, adding a recommended Binding
value alongside the backward-compatibility usage of PAOS
o 12, clarifying comments based on WG feedback, with a normative o 12, clarifying comments based on WG feedback, with a normative
change to use enctype numbers instead of names change to use enctype numbers instead of names
o 11, update EAP Naming reference to RFC o 11, update EAP Naming reference to RFC
o 10, update SAML ECP reference to final CS o 10, update SAML ECP reference to final CS
o 09, align delegation signaling to updated ECP draft o 09, align delegation signaling to updated ECP draft
o 08, more corrections, added a delegation signaling header o 08, more corrections, added a delegation signaling header
 End of changes. 30 change blocks. 
63 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/