eIDAS SAML Detailed Analysis - RUB-NDS/FutureTrust GitHub Wiki

In the following we describe further relevant security properties of the eIDAS architecture. The information is taken from (eIDAS Spec, 2015^[1] and (Subgroup, eIDAS - Cryptographic requirements for the Interoperability Framework, 2015)^[2].

The security of eIDAS relies on the identification of eIDAS-Nodes via SAML Metadata. The exchange of metadata follows these principles:

• The trust anchor for the eIDAS-Nodes are the MSs, there is no central trust anchor. Exchange of trust anchors is bilateral between the MSs.
• Metadata of the eIDAS-Connectors and eIDAS-Proxy-Services is signed by the trust anchor or another entity, e.g. the operator of an eIDAS-Node, which is authorized by a certificate chain which starts at the trust anchor.
• Metadata of eIDAS-Middleware-Services are unsigned.
• SAML metadata must be signed with one of the algorithms specified in Table 5 Signature Algorithms. The X.509 certificate chain which is used in the SAML metadata must also use these algorithms.

In the following we summarize the properties of cryptographic algorithms used to sign and encrypt SAML messages (Subgroup, eIDAS - Cryptographic requirements for the Interoperability Framework, 2015):

• SAML request and SAML response messages must be signed by the sending party. For signature creation only SHA-256 is supported as hashing algorithm and one of the algorithms from Table 5 Signature Algorithms must be used.
• The SAML assertion within the SAML response message must be encrypted. The Assertion must be encrypted with an ephemeral session key using one of the algorithms specified in Table 1 Content Encryption Algorithms.
• The session key must be encrypted with either a public key of the endpoint or a shared key. For the encryption with a public key one of the algorithms from Table 2 Key Transport Algorithms must be used. For the encryption with a symmetric key one of the algorithms specified in Table 3 Key Agreement Algorithms must be used and the key must be wrapped with one of the algorithms specified in Table 4 Key Wrapping Algorithms. Additionally, the receiver must support additional ephemeral data (KA-Nonce element) to be included into the derivation of the key encryption key.
• If elliptic curves are used, they must be named elliptic curves, e.g. BrainpoolP256r1.

Algorithm
https://www.w3.org/2008/xmlsec/namespaces.html#aes128-gcm
https://www.w3.org/2008/xmlsec/namespaces.html#aes256-gcm

Table 1: Content Encryption Algorithms

Algorithm	Minimal key length
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p	3072
http://www.w3.org/2009/xmlenc11#rsa-oaep	3072

Table 2: Key Transport Algorithms

Algorithm	Minimal key length
https://www.w3.org/2008/xmlsec/namespaces.html#ECDH-ES	256

Table 3: Key Agreement Algorithms

Algorithm	Minimal key length
https://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#kw-aes128	128
https://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#kw-aes256	256

Table 4: Key Wrapping Algorithms

Algorithm	Minimal key length
RSASSA-PSS	3072
ECDSA	256

Table 5: Signature Algorithms

In the following the structure of the SAML messages is explained. The information is taken from^[3].

Authentication requests shall be submitted via HTTP Redirect or HTTP POST binding.

The eIDAS-Service must verify the integrity/authenticity of the SAML Request. For this the signature certificate of the eIDAS-Connector is extracted from the SAML-Metadata.

eIDAS-Connectors must support ForceAuthn. The value must be set to “true”.

eIDAS-Connectors must support isPassive. The value should be set to “false”.

RequestedAuthnContext shall be used to indicate the requested eIDAS Levels of Assurance. Implementations must support the eIDAS Levels of Assurance (LoA). Possible LoA values are listed in Table 6 Possible Levels of Assurance. eIDAS-Connectors should request a specific LoA. eIDAS-Connectors requesting a LoA must limit the value of the comparison attribute of RequestedAuthnContext to "minimum".

Levels of Assurance
http://eidas.europa.eu/LoA/low
http://eidas.europa.eu/LoA/substantial
http://eidas.europa.eu/LoA/high

Table 6: Possible Levels of Assurance

The HTTP POST binding shall be used for this message.

The eIDAS-Connector must verify the signature of the Response and of the Assertion if it is signed.

The elements AuthnContext and AuthnContextClassRef must contain a URI describing an eIDAS LoA.

A SAML assertion must include at least the attributes requested as mandatory (indicated in the SAML authentication request by the attribute isRequired=“true”), otherwise the SAML response must include an appropriate error message.

The eIDAS Attribute Profile^[4] specifies how to express the eIDAS minimum data set (like name, date of birth and unique identifiers for natural persons) and the optional data (like address or place of birth). The Attribute Profile is an XML schema based on the ISA Core Person Vocabulary for natural persons and the ISA Core Business Vocabulary for legal persons. The Core Vocabularies are data representation standards that have been developed by European public administrations through the European Commission’s Interoperability Solutions for European Public Administrations (ISA) Programme. The detailed description can be found in (eIDAS Technical Subgroup, 2015)^[4].

1. ^ eIDAS Spec. (2015, November 26). eIDAS Technical Subgroup. eIDAS Technical Specifications v1.0. https://joinup.ec.europa.eu/software/cefeid/document/eidas-technical-specifications-v10.
2. ^ Subgroup, e. T. (11 2015). eIDAS - Cryptographic requirements for the Interoperability Framework. Retrieved from https://joinup.ec.europa.eu/sites/default/files/eidas_-_crypto_requirements_for_the_eidas_interoperability_framework_v1.0.pdf
3. ^ eIDAS Technical Subgroup. (2015). eIDAS SAML Message Format. Retrieved from https://joinup.ec.europa.eu/sites/default/files/eidas_message_format_v1.0.pdf
4. ^ ^ eIDAS Technical Subgroup. (2015). eIDAS SAML Attribute Profile. Retrieved from https://joinup.ec.europa.eu/sites/default/files/eidas_saml_attribute_profile_v1.0_2.pdf