Versions Compared

Old Version 17

changes.mady.by.user trscavo@internet2.edu

Saved on

compared with

New Version 18

changes.mady.by.user trscavo@internet2.edu

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. From the logout framing questions: Should logout requests/responses be required to be signed?  If the answer is yes, then the SP needs to handle keys. This XML encryption discussion may drive the answer to this question.
  2. Do we want to require encryption if we don’t also require non-practically-breakable algorithms? (This could be an issue/limitation in 800-63, where XML encryption is required but not secure algorithms). May need other requirements listed as well.
  3. In practice, confidentiality of user data in transit is provided by TLS or XML encryption (or both).
    1. Used in conjunction with a back channel protocol (such as artifact resolution or attribute query), TLS provides end-to-end confidentiality of user data in transit. In practice, XML encryption is not used on the back channel.
    2. The primary use of XML encryption today is in conjunction with SAML2 Web Browser SSO on a front channel. In that case, XML encryption is necessary for end-to-end confidentiality of user data in transit. OTOH, if you trust the browser (or don't care), TLS is sufficient (and of course TLS protects against other threats as well).
    3. An emerging use of XML encryption is in conjunction with SAML2 Single Logout but this is a completely new use case with little or no deployed base. (As Shibboleth IdP V3 proliferates, this may change.) We'll come back to this use case.
  4. An important open question is: What protocols will the deployment profile mandate? What protocols will be discouraged (if any)?
    1. The use of XML encryption in conjunction with SSO is reasonably well understood. For example, if the deployment profile mandates support for SAML2 Artifact Resolution, the need to support inbound XML encryption at the SP is reduced. OTOH, if the deployment profile discourages the use of back-channel protocols (or ignores them altogether), the need to support inbound XML encryption at the SP is heightened.
    2. SLO is a more complicated use case. If the deployment profile mandates support for unconstrained SAML2 Single Logout, inbound XML encryption at the IdP is necessary to preserve privacy both in transit and at rest. The need to support inbound XML encryption may at the IdP may be reduced by constraining the name identifier format and/or the binding used to transmit the LogoutRequest.
    3. Claim: The cost-benefit ratio associated with inbound XML encryption at the IdP is inordinately high. Can it be avoided?
  5. A deployment that does not support seamless encryption key rollover does not fully support inbound XML encryption.
    1. Seamless encryption key rollover requires your SAML software to be configurable with multiple decryption keys. (Multiple encryption certificates in metadata do not facilitate encryption key rollover.)
    2. If your SAML software can not be configured with multiple decryption keys, and you publish an encryption certificate in metadata, seamless encryption key rollover is not possible. In that case, it is better not to publish an encryption certificate in metadata in the first place.
  6. Possibly relevant facts about the Federation Manager:
    1. The FM requires an encryption certificate in SP metadata.
    2. The FM does not support an encryption certificate in IdP metadata.
    3. The FM does not require protocol endpoints in SP metadata to be HTTPS-protected.
    4. The FM requires protocol endpoints in IdP metadata to be HTTPS-protected.

...