The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Matthew Slowe <Matthew.Slowe AT jisc.ac.uk>]

Hi Dubravko,

It's been a few weeks and I wondered if you'd been able to make any progress 
with this?

I've been advised by someone from the eduGAIN support team that to 
interoperate with new Shibboleth IdPs you must add another element to the 
SP's metadata:

> <EncryptionMethod xmlns="urn:oasis:names:tc:SAML:2.0:metadata" 
> Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>

Thanks,
-- 
Matthew Slowe
Technical Specialist - Trust & Identity, Jisc

Direct: 07442 097185
Team: 0300 300 2212, option 2
Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG


> On 7 Aug 2020, at 12:22, Matthew Slowe <Matthew.Slowe AT jisc.ac.uk> wrote:
> 
> Hi Dubravko,
> 
> I'm aware of some delays in the in-and-out-of-edugain processes but, in the 
> UK Federation publication that went out last night, it's a single element 
> as you say.
> 
> This seems to have fixed it for non-ShibIdPv4 instances (those that don't 
> default to GCM) and we're back to "mostly working". However it's still not 
> working when the IdP's default configuration is set to GCM.
> 
> I've had a chat with the Shibboleth project development team to check what 
> I should be suggesting for you. The long answer is:
> 
>> * They want at least the aes128-cbc value.
>> 
>> * If they want the rsa-oaep-mgf1p explicitly specified as well, they can 
>> have that too but I don't think leaving it out will make a difference as 
>> it's kind of a mandatory default.
>> 
>> * Adding the other AESxxx-CBC in the order given won't affect anything 
>> today, but might cause them to be selected one day if AES128-CBC ever 
>> becomes nonviable. They're slower, and not reckoned to have much 
>> additional strength, which is why the Shib SP orders them that way. 
>> Obviously they should only include things they actually support, and I 
>> accept that actually finding out what you support can be a PITA, so 
>> leaving them out is fine too.
> 
> The short answer is:
> 
> "Add the aes128-cbc, leave the existing one if you want."
> 
> That way "old" IdPs would still use the CBC algorithm and "new" IdPs will 
> know that they need to use the CBC (rather than GCM) algorithm. Would you 
> be able to do that?
> 
> Thanks!
> -- 
> Matthew Slowe
> Technical Specialist - Trust & Identity, Jisc
> 
> Direct: 07442 097185
> Team: 0300 300 2212, option 2
> Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG
> 
> 
>> On 6 Aug 2020, at 20:07, Dubravko Penezic <dpenezic AT srce.hr> wrote:
>> 
>> Hi Matthew.
>> 
>> metadata was change on 05.08., to single one , when you last time collect 
>> metadata ?
>> 
>> Regards,
>> 
>> Dubravko Penezic
>> 
>> On 8/6/20 11:46 AM, Matthew Slowe wrote:
>>>> On 6 Aug 2020, at 10:08, Alan Cox - UKRI <Alan.Cox AT ukri.org> wrote:
>>>> 
>>>> I've just experienced what seems to be the same error, though with a 
>>>> Shibboleth 3.4.6 IdP - https://nerckwshibba.nerc.ac.uk/idp/shibboleth.
>>> Our 3.4.6 IdP is also now seeing the same thing - as is the new v4 IdP.
>>> 
>>> Comparing the assertion for CAT with a "known good" assertion (against an 
>>> SP which doesn't assert any algorithm requirements), I note these 
>>> differences:
>>> 
>>> --- ref.xml 2020-08-06 10:38:45.000000000 +0100
>>> +++ cat.xml 2020-08-06 10:38:56.000000000 +0100
>>> @@ -4,8 +4,9 @@
>>>     <xenc:EncryptionMethod xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"; 
>>> Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
>>>     <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
>>>       <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"; 
>>> Id="id" Recipient="sp-entityid">
>>> -        <xenc:EncryptionMethod 
>>> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"; 
>>> Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p";>
>>> +        <xenc:EncryptionMethod 
>>> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"; 
>>> Algorithm="http://www.w3.org/2009/xmlenc11#rsa-oaep";>
>>>           <ds:DigestMethod xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; 
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>> +          <xenc11:MGF xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"; 
>>> Algorithm="http://www.w3.org/2009/xmlenc11#mgf1sha1"/>
>>>         </xenc:EncryptionMethod>
>>>       </xenc:EncryptedKey>
>>>     </ds:KeyInfo>
>>> 
>>> 
>>> I don't know a huge amount about the inner workings of the different 
>>> algorithms, but I do wonder if SimpleSAMLphp doesn't support "rsa-oaep" 
>>> but does support "rsa-oaep-mgf1p" but, because the first one is listed 
>>> first it's using that?
>>> 
>> To unsubscribe, send this message: 
>> mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
>> Or use the following link: 
>> https://lists.geant.org/sympa/sigrequest/cat-users
> 
> To unsubscribe, send this message: 
> mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
> Or use the following link: 
> https://lists.geant.org/sympa/sigrequest/cat-users