SAML Profile for the Metadata Query ProtocolIndependentian@iay.org.ukmetadataSAML
This document profiles the Metadata Query Protocol for use
with SAML metadata.
This document is a product of the Research and Education Federations (REFEDS) Working Group process.
Discussion of this draft takes place on the MDX
mailing list (mdx@lists.iay.org.uk), which is accessed from
.
XML versions, latest edits and the issues list for this document
are available from .
The changes in this draft are summarized in .
This document profiles the Metadata Query Protocol for use
with SAML metadata.
The Research and Education Federations group ()
is the voice that articulates the mutual needs of research and education
identity federations worldwide. It aims to represent the requirements of
research and education in the ever-growing space of access and identity
management.
From time to time REFEDS
will wish to publish a document in the Internet RFC series. Such
documents will be published as part of the RFC Independent Submission
Stream ; however the REFEDS working group sign-off process will
have been followed for these documents, as described in
the REFEDS Participant's Agreement.
This document is a product of the REFEDS Working Group process.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
This document makes use of the Augmented BNF metalanguage defined in .
Requests compliant with this profile MUST include the following HTTP header to indicate that
the metadata returned should be SAML metadata (see Appendix A of ):
Each entity known to the responder MUST be associated with the unique identifier
of the entity, corresponding to the entityID attribute
of the entity's EntityDescriptor element in SAML metadata.
SAML 2.0 includes profiles based on the transfer
of an "artifact" containing the unique identifier of a SAML entity transformed by
means of the
SHA-1 hash algorithm (see
sections 3.6 and 3.6.4).
In order to support use cases in which clients may be in possession of only such a transformed
representation of a SAML entity's unique identifier without any way to establish the original
entity identifier, a responder compliant with this profile MUST associate each entity
with an identifier matching the
sha1id production in the following ABNF grammar, and treat
such an identifier as equivalent to
the corresponding untransformed identifier:
In the above, the sha1hex component encodes the 20-octet
(160-bit) binary SHA-1 hash value as a sequence of 40 lower case hexadecimal digits.
For example, the identifier
transformed by means of SHA-1 hashing would become
Responder implementations MAY detect malformed SHA-1 transformed identifiers
(for example where the string of characters
following the "}" contains characters other than hexadecimal digits, or is other than
exactly 40 characters in length) and return an HTTP status code of 400
("bad request"). Alternatively, implementations MAY process these as normal
identifiers and return an HTTP status code of 404 ("not found") if appropriate.
Entities MAY also be associated with any number of additional responder-defined
identifiers naming arbitrary groups of entities.
A request may return information for any number of entities, including none. Responses compliant with
this profile MUST use the appropriate representation described below depending on the number of
EntityDescriptor elements returned.
A response which returns no EntityDescriptor elements
MUST be represented by an HTTP status code of 404 ("not found").
A response which returns a single EntityDescriptor element
MUST use that element as its document element.
The responder MUST NOT make use of a EntitiesDescriptor
element in this situation (see section 2.3).
Such a response MUST include the following HTTP header to indicate that
the metadata returned is SAML metadata:
A response which returns more than one EntityDescriptor element
MUST consist of a document element which is an EntitiesDescriptor
element, containing the returned EntityDescriptor elements
as children. Responses MUST NOT contain nested EntitiesDescriptor
elements.
Such a response MUST include the following HTTP header to indicate that
the metadata returned is SAML metadata:
As SAML metadata contains information necessary for the secure operation of interacting services it is
strongly RECOMMENDED that a mechanism for integrity checking is provided to clients.
It is RECOMMENDED that the integrity checking mechanism provided by a responder is a digital
signature embedded in the returned metadata document, as defined by
section 3.
Such digital signatures:
SHOULD use an RSA keypair whose modulus is no less than 2048 bits in length.MUST NOT use the SHA-1 cryptographic hash algorithm as a digest algorithm.MUST NOT use the MD5 cryptographic hash algorithm as a digest algorithm.SHOULD otherwise follow current cryptographic best practices in algorithm selection.
This profile mandates the availability of an identifier synonym mechanism based on
the SHA-1 cryptographic hash algorithm. Although SHA-1 is now regarded as weak enough
to exclude it from use in new cryptographic systems, its use in this profile is
necessary for full support of the SAML 2.0 standard.
The use of SHA-1 in section 3.6.4 of ,
and its resulting use in this protocol, would be
vulnerable to an attack in which metadata was introduced
into a system by an attacker capable of creating an entity
identifier with the same SHA-1 hash as that of an existing
entity's identifier.
Such an identifier is known as a second preimage
of the original, and SHA-1's resistance to discovery of
it is referred to as SHA-1's second-preimage
resistance.
As demonstrated by the the and
attacks, the SHA-1 algorithm is
known to have weak collision resistance.
However, at the time of writing no attacks are known on
SHA-1's second-preimage resistance; a result in this area
would be required to provide the basis of an attack based
on duplicating the SHA-1 hash of an existing identifier.
As a result, the use of SHA-1 in SAML and in this protocol
is not believed to introduce a security concern.
Implementations may guard against the possibility of a future
practical attack on the second-preimage resistance of SHA-1
by treating two entities whose
entityID values have the same SHA-1 equivalent as an
indicator of malicious intent on the part of the owner of one of the entities.
This document has no actions for IANA.
The editor would like to acknowledge the following individuals for their contributions to this document:
Scott Cantor (The Ohio State University)Leif Johansson (SUNET)Joe St Sauver (University of Oregon)Tom Scavo (Internet2)Metadata Query Protocol
Bindings for the Security Assertion Markup Language
(SAML) V2.0
Metadata for the Security Assertion Markup Language
(SAML) V2.0Internet2cantor.2@osu.eduSigabajmoreh@sigaba.comRSA Securityrphilpott@rsasecurity.comSun Microsystemseve.maler@sun.comAugmented BNF for Syntax Specifications: ABNFREFEDS Home PageResearch and Education FederationsREFEDS Participant's AgreementResearch and Education FederationsAssertions and Protocol for the OASIS Security Assertion Markup Language
(SAML) V2.0Internet2cantor.2@osu.eduNokiaJohn.Kemp@nokia.comRSA Securityrphilpott@rsasecurity.comSun Microsystemseve.maler@sun.comMDX Mailing Listmd-query ProjectSHAtteredSHA-1 is a Shambles
Initial version.
Added REFEDS RFC stream boilerplate.
Bump reference to the Metadata Query Protocol.
Rework to make the role of transformed identifiers
clearer. This changes the semantics slightly (malformed transformed identifiers
may now result in a 404 return rather than 400) but this gives implementers more
latitude in the way that they handle the feature.
Bump reference to the Metadata Query Protocol.
Bump reference to the Metadata Query Protocol.
Added an Editorial Note to help direct readers
back to the discussion.
Fix reference to the Metadata Query Protocol.
Bump reference to the Metadata Query Protocol.
Bump reference to the Metadata Query Protocol.
Bump reference to the Metadata Query Protocol.
Bump reference to the Metadata Query Protocol.
Modernise normative language to include .
Improved references to RFCs.
Bump reference to the Metadata Query Protocol.
Bump reference to the Metadata Query Protocol.
Replace citations in the abstract with straight textual
mentions, as required by the ID-NITS checklist.
Bump reference to the Metadata Query Protocol.
Strengthen so that SHA-1
now MUST NOT be used in the context of digital signatures.
This brings the section in line with current best practice
recommendations, particularly in light of the
and
attacks.
Revised on the use of SHA-1
in transformed identifiers to:
Make clear that this is a SAML-level issue, not one
introduced by the query protocol.
Reference the attacks demonstrating SHA-1's weak
collision resistance.
Identify second-preimage resistance as the potential
source of the attack we'd be concerned about for
the query protocol.
Note that SHA-1's second-preimage resistance is
at present uncompromised.