Skip to Content.
Sympa Menu

edugain-discuss - Re: [eduGAIN-discuss] Assessment of Russia/RUNNet AAI for eduGAIN membership

edugain-discuss AT lists.geant.org

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

List archive

Re: [eduGAIN-discuss] Assessment of Russia/RUNNet AAI for eduGAIN membership


Chronological Thread 
  • From: Peter Schober <peter.schober AT univie.ac.at>
  • To: edugain-discuss AT lists.geant.org
  • Subject: Re: [eduGAIN-discuss] Assessment of Russia/RUNNet AAI for eduGAIN membership
  • Date: Fri, 16 Mar 2018 11:27:14 +0100
  • Authentication-results: prod-mail.geant.net (amavisd-new); dkim=pass (1024-bit key) header.d=univie.ac.at
  • Organization: ACOnet

I'll try one last time.

* Порхачев Василий <porhachev AT runnet.ru> [2018-03-16 08:40]:
> Taking more precise view at
> http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
> p.68 we think to rewrite this in accordance of standard.

That doesn't really go into what I was talking about: Your statement
about discarding any unsigned protocol messages is simply too broad
(IMO) as that would also cover authn requests from the SP. What is the
function of an auth request? To start SSO from a specific SP with a
specific IDP, and to request from the IDP that the response to the SP
be sent to a specific endpoint (the SP might have more than one). The
common (and completely sufficient) way to verify the requested
location for the response is for the IDP to look it up in SAML
Metadata, exchanged out of band. I.e., the content of the request is
not trusted blindly, it is verified using metadata. So signing authn
requests does not add anything of value here in ordinary usage, and
therefore you don't benefit from discarding/rejecting unsigned authn
requests.

Requring your entities to always sign may not be a good idea but it's
not what will cause interop issues. (The SP then exposes itself to DoS
attacks, as said before, since now every computationally "cheap" HTTP
GET request to a protected resource or session initiator at the SP
will cause the SP to perform a computationally "expensive"
cryptographic signing operation, giving the attacker -- anyone that
can reach the SP's web server via HTTP(S) -- a clear benefit, the
exact opposite of what you'd want. And for what? Because people
blindly mandate signatures thinking they're more secure then, when in
fact they've opened up a trivial way for everyone on the internet to
easily take down their server, which arguably makes it less secure:
Information Security is commonly defined as Confidentiality, Integrity
and Availability. You'd gain a bit of the second but lose the third.)
But mandating that unsigned requests must be discard/rejected will
prevent your IDPs from accessing most SPs from other federations,
i.e., international cooperation/federation.

Don't make up your own rules unless you understand all the
consequences. Check out saml2int which states the essential things
here without going overboard, cf [SDP-IDP05] and [SDP-IDP06]:
https://kantarainitiative.github.io/SAMLprofiles/saml2int.html#_web_browser_sso_2

So why not simly reference saml2int instead? It has been written by
the people who breath that stuff, including the people who have
literally written the SAML 2.0 specification.
-peter



Archive powered by MHonArc 2.6.19.

Top of Page