Support for consuming assertions encrypted using GCM

[skoranda]

The Shibboleth IdP v4 will set the default encryption to be GCM instead of CBC. See

https://wiki.shibboleth.net/confluence/display/IDP4/GCMEncryption

pysaml2 needs to support GCM so that SAML SPs built using pysaml2 can consume and decrypt assertions sent by the Shib IdP v4 that are encrypted using GCM.

[c00kiemon5ter]

pysaml2 uses xmlsec1 by default, as a backend to sign/verify/encrypt/decrypt xml documents.

---

xmlsec1 news:
https://www.aleksey.com/xmlsec/news.html

October 23 2018

• The XML Security Library 1.2.27 release includes the following changes:
  • Added AES-GCM support for OpenSSL and MSCNG (snargit).

---

$ xmlsec1 --version
xmlsec1 1.2.29 (openssl)

$ xmlsec1 --version
xmlsec1 1.2.29 (openssl)

$ openssl list-cipher-algorithms | grep -i gcm
id-aes128-GCM
id-aes192-GCM
id-aes256-GCM
id-aes128-GCM
id-aes192-GCM
id-aes256-GCM

---

I am not sure we need something more than the support in the backends; that seems to be there already. We should definitely make a test and check.

[ioparaskev]

I did a quick test in one of our test deployments and it seems to work. We got an encrypted assertion with http://www.w3.org/2009/xmlenc11#aes128-gcm and the decryption from xmlsec was successful.

The machine I tested has the following gcm ciphers available

ubuntu@proxy-autoconf:~/satosa/proxy$ openssl ciphers -v | grep -i gcm
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(256) Mac=AEAD
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
PSK-AES256-GCM-SHA384 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(256) Mac=AEAD
RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(128) Mac=AEAD
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
PSK-AES128-GCM-SHA256 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(128) Mac=AEAD

So as @c00kiemon5ter if there's support for GCM by openssl (and therefore by xmlsec) everything will work as usual

[c00kiemon5ter]

So, this just works. That is both good and bad.

Part of this experiment shows that we do not actually check if actually want to support the incoming algo and whether we want to accept such a response. We should wrap all of this and actually be able to define which algos we support and use.

As we have discussed elsewhere that "support algo list" should actually be a blacklist; ie we should define which algos we do not support. This will allows to automatically support new algo additions in the underlying backends.

I am closing this but we should give more attention to #597 #628 #645 in the above context.