[Go-essp-tech] GO-ESSP-Tech 4/19/2011 - Release Coordination - Metrics

Wed Apr 20 09:15:05 MDT 2011

Hi,

my 2c to this. I'm no security expert, but I think we are discussing 
peanuts here... two reasons for this:

1) If we loose the safety of SSL, pretty much everything is lost. Just 
wait for the myproxy endpoint and catch the user password... that's it. 
(oversimplified, but, if I understood it right, this is exactly what's 
happening there)
2) The OPenID hash is no use. Suppose I get the hash, I could get the 
IDP pretty easily, just by registering on the site, or looking arround, 
it's out there and it was never meant to be secured. So, let's take the 
10 most common hash algorithms and the 10 most common Gateways IDP 
(that's a factor 100 for what comes)... how long will it take to "guess" 
the user id? ascii lowercase to 10 and you have 99% chances to get it 
right (a couple of milliseconds here?). Add some Uppercases and a point, 
dash etc and you'll pretty much replicate the hash in no time (ok a 
couple of minutes top). Of course I still don't know what you can use 
the OpenID for, but that's another question.

But maybe I'm wrong. I just don't like building shields of paper. It's 
good to the user sure, because it improves their quality of life (the 
feeling of being secure is quite important) but for system 
administrators it will be a nightmare (A Security hole in SSL? Well, I 
get to it next year it's just too complex and we still have many other 
security mechanisms in place...)

I might be exaggerating, but I'm not that sure...

Cheers,
Estani

Am 20.04.2011 16:57, schrieb Nathan Wilhelmi:
> Hi,
>
> philip.kershaw at stfc.ac.uk wrote:
>> Hi all,
>>
>> My understanding from the call was that we would go with an SSL based 
>> solution securing the metrics endpoint.   This was because the 
>> alternative would mean a lot of re-engineering in the Gateway code base.
>>
>> Gavin, I think what you're proposing now is to include the domain 
>> name of the user's OpenID in its un-hashed form.  The question then 
>> would be, does this still involve a lot of re-working of code on the 
>> Gateway side?
> The bottom line on the gateway side is we will need to resolve the 
> user. We have use cases, and they have cropped up recently, where data 
> managers want to figure out exactly who it was who downloaded the 
> data. So added the IDP really doesn't help much for us.
>> I found this post on setting up SSL with mutual authentication and 
>> filtering by certificate subject name:
>>
>> http://twoguysarguing.wordpress.com/2009/11/03/mutual-authentication-with-client-cert-tomcat-6-and-httpclient/ 
>>
>>
>> Yes, note the jaded opening remarks :) but if it's a recipe that can 
>> be followed by someone who's been there and done it already it should 
>> be OK.  Doing this with Apache is much more straightforward via the 
>> SSLRequire directive.
>>
>> Regardless of what happens with the metrics service it would be good 
>> to know how to do this for rolling out whitelisting of Attribute and 
>> Authorisation Services.   The sooner the better especially for the 
>> former service because without it we expose user's e-mail addresses 
>> to anyone curious enough to find out how to get them.
> Support for requiring authenticated SSL for these services is already 
> in the gateway 1.3 release.  By default it ships disabled, obviously 
> to make this work the gateways and datanodes need to have client 
> certificates in place which isn't the case right now. Once the client 
> certificates are in place we can simply switch the configuration and 
> the services will be protected. As you note the email resolution 
> service will in fact pass both the openid and e-mail address across 
> the wire. The whitelisting is driven by the registry, so no manual 
> configuration should be required once this is all up and running.
>
> As mentioned in the call we leveraged Spring to do this. So we now 
> have a layer in that will make protecting these and future services 
> simply a matter of configuration. I would be happy to outline what we 
> did, but I suspect in this case using tomcat valves/realms would be an 
> easier path forward on the datanode side.
>
>
> Thanks!
> -Nate
>> Cheers,
>> Phil
>>
>> From: "Gavin M. Bell" <gavin at llnl.gov<mailto:gavin at llnl.gov>>
>> Reply-To: "Gavin M. Bell" <gavin at llnl.gov<mailto:gavin at llnl.gov>>
>> Date: Tue, 19 Apr 2011 15:10:09 -0700
>> To: Eric Nienhouse <ejn at ucar.edu<mailto:ejn at ucar.edu>>
>> Cc: "go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>" 
>> <go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>>, 
>> <esgf-mechanic at lists.llnl.gov<mailto:esgf-mechanic at lists.llnl.gov>>
>> Subject: Re: [Go-essp-tech] GO-ESSP-Tech 4/19/2011 - Release 
>> Coordination - Metrics
>>
>> Hi Eric
>>
>> (comments below)
>>
>> On 4/19/11 1:46 PM, Eric Nienhouse wrote:
>>
>> Hi All,
>>
>> We discussed the Data Node metrics access logging service in our GO-ESSP
>> call today.  This is a key integration point between Gateways and Data
>> Nodes and is a high priority feature for the 1.3.0 release.
>>
>> Following is a summary of our conclusions.  Please note anything that
>> may be incorrect or unclear.
>>
>> 1)  The Data Node metrics access logging service should be secured 
>> via SSL.2)  Gateway access to the metrics service should require (GW 
>> client)
>> authentication.
>> 3)  Email address should not be included in the metrics records 
>> exchanged.
>>
>>
>> nod
>>
>> 4)  There are a number of use cases which imply tracking user OpenID's
>> at the GW and DN.
>>
>>
>>
>> I sill think that the openid's should be obfuscated.  The one bit of 
>> information in the openid that will be in a different field will be 
>> the hostname value of the user's openid i.e. their IDP.  With that 
>> bit of information there will be everything that one would need in a 
>> metrics context.  Thus you would be able to answer the metrics 
>> question: How many people accessing Y data have accounts on X? X 
>> being the IDP of an organization.
>>
>> I share Bob's and Philip's concern about data exposure.  In the 
>> scenario above, the  openid of person Z can still be positively 
>> gotten by asking idp X, 'hey who is Z?', but this is not the general 
>> case.  This also follows the basic pattern that we employ for email 
>> addresses which we all agree should not be passed around on the wire, 
>> regardless of transfer mechanism.  The pattern for email is that we 
>> have to run a special resolution service in order to perform the 
>> lookup, because that information is not made directly available.
>>
>> So, the returned metrics would not have the openid but have two bits 
>> of information:
>> 1 - the openid / userid hash
>> 2 - the hostname of the IDP for whom the openid is in custody.
>>
>> I think this should be sufficient to provide reasonable privacy 
>> regardless of using secured ssl or not.
>> I cannot see a use case in the context of metrics that require any 
>> additional information.
>> Do you concur?
>>
>> We discussed providing examples or best practices for securing the
>> metrics service.  (Ideally for a Non-Spring  Tomcat environment.)
>> (Phil, Luca, Nate?)
>>
>> We noted the Gateway 1.3.0 RC1 release is waiting on finalizing the
>> metrics service interface and security configuration.  We need to
>> identify the time-line for accomplishing securing the metrics service.
>> (Gavin?)
>>
>> For further background, the ESG Metrics Use Cases can be found below.
>> These Use Cases support our conclusions above.
>>
>>   https://wiki.ucar.edu/display/esgcet/Metrics
>>
>> I appreciate all the input today.
>>
>> Thanks,
>>
>> -Eric
>>
>>
>> _______________________________________________
>> GO-ESSP-TECH mailing list
>> GO-ESSP-TECH at ucar.edu<mailto:GO-ESSP-TECH at ucar.edu>http://mailman.ucar.edu/mailman/listinfo/go-essp-tech 
>>
>>
>>
>> -- 
>> Gavin M. Bell
>> Lawrence Livermore National Labs
>> -- 
>>
>>  "Never mistake a clear view for a short distance."
>>                -Paul Saffo
>>
>> (GPG Key - http://rainbow.llnl.gov/dist/keys/gavin.asc)
>>
>>  A796 CE39 9C31 68A4 52A7  1F6B 66B7 B250 21D5 6D3E
>>
>

-- 
Estanislao Gonzalez

Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany

Phone:   +49 (40) 46 00 94-126
E-Mail:  estanislao.gonzalez at zmaw.de