An open discussion list for topics related to the eduGAIN interfederation service.

[Peter Schober <peter.schober AT univie.ac.at>]

Alan,

* Alan Lewis <alan.lewis AT geant.org> [2019-03-26 17:08]:
> One of the things I would like to understand is what requirements
> there might be for use of such an HSM in the R&E community and
> outside of those services which are currently being offered by
> GEANT.

Since you sent this to the eduGAIN-discuss mailing list I'll be
answering this as far as Identity Federation topics are concerned.

> So I would be interested to know for any services you are aware of that 
> might benefit:
> 
> 1.    The use cases for secure storage;

Protecting cryptographic (secret/private) key material.
Mostly for the federation's signed metadata feeds (SAML 2.0) or
software statements (OIDC+fed). Possibly some TLS servers' keys.

> 2.    The current situation – what is being done today;

A few federations have deployed NetHSMs (I know about ~3), others may
be using smartcard-based HSMs (maybe 3-6?), the large majority
(eduGAIN currently has 60 member federations) probably still signing
with software-based keys?
I'm not aware we've asked federations to disclose this information yet.

> 3.    The data that is being stored and the quantity;

Mostly RSA keys in the 2-4k range, I think.
As for quantity I doubt it's more than an handful, for most of us.

(If dozens or hundreds of partitions were available in the HSM some
services -- e.g. GEANT's own FaaS offering -- would actually make use
of dozens, not quite hundreds, of keys. Since that's not the case with
the current NetHSM as used by GEANT the FaaS infrastructure currently
uses a single key pair for all signed aggregates.)

> 4.    The value of the information that is being protected;

Were a federation participating in eduGAIN unable to provide a trusted
feed that would lead to their exclusion from the global trust fabric,
i.e., institutions and servics within that federation would vanish
from other federations' view and the affected federation would lose
access to services offered by others via eduGAIN.

That trust does not derive purely from (and therefore cannot be
reduced to) the technical properties of the method chosen to protect
key material, of course.

And the existing real-world trust that allowed federations to get
established in the first place (and that enables their members to
trust the federation's keys) would likely allow to re-bootstrap a
federation's trust anchors from scratch as long as that doesn't happen
regularly (say, more than once/very few times).

> 5.    Specific HSM requirements for
> 
> a.    Cryptographic performance;

With MDQ (siging several thousand[1] of small text files individually,
instead of signing one ~50MB file) on the horizon that's increasingly
going to be a factor. You'd want those thousands of signature ops to
be performed at least daily, possibly more often.

Personally I think resigning everything in eduGAIN would probably work
up to 3 or 4 times the number of entities of the current eduGAIN
aggregate (with 15-20k signing ops taking a few hours) even when using
smartcard-based HSMs (that typically have a signing performance around
1-2 signature operation per second) but views will widely differ here
across federations.

> b.    Cryptographic algorithm support;

Today pretty much only RSA with SHA2 based hashes is being used, AFAIK.
I'll leave that to others.

> c.    Management, connectivity and access mechanisms;

Obviously PKCS#11 for access but if we snuck in some newer
(non-standard) method such as TLS-protected pyeleven-style HTTP (and
maybe standardised that while we're at it) that would probably make a
few people's lives quite a bit easier.

> d.    FIPS level or CC compliance;

Don't know/care.

> e.    Other stuff I haven’t thought of yet.

I'll leave that to others as well.

Best regards,
-peter

[1] The current edUGAIN aggregate contains 5445 entities as per today
and has been growing by 50-100 entities per month in recent times.