[Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ

[m.riedel at fz-juelich.de]

Howdy, 

>- I do code for doing authentication with and without proxies. And I never 
noticed significant difference.

We do to - difference, for example, would be to climb the proxy chain using the "specific path validation algorithm" which is not needed by using typical X.509 certs.

>- So why not to use last option? Or am I missing something?

As I said before - probably not all services understand normal TLS and require proxies where pure PGI_TLS is not correct - e.g. CREAM-BES I know from my own experience so far.

>- If (a) covers (b) then "either (a) or (b)" is not achievable.

my fault - (a) should be rather in the questions section, but an answer from gLite may help to understand.

Take care,
Morris







--------------------------------------------------------------------------------
Morris Riedel
SW - Engineer
Distributed Systems and Grid Computing Division
Central Institute of Applied Mathematics
Research Centre Juelich
Wilhelm-Johnen-Str. 1
D - 52425 Juelich
Germany

Email:  m.riedel at fz-juelich.de
Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel

Phone: +49 2461 61 - 3651
Fax: +49 2461 61 - 6656

Skype: MorrisRiedel

'We work to improve ourselves and the rest of mankind.'

----- Original Message -----
From: Aleksandr Konstantinov <aleksandr.konstantinov at fys.uio.no>
Date: Friday, March 20, 2009 12:26 pm
Subject: Re: [Pgi-wg]Sec: Agreement on attribute transport mechanisms	forAttrAuthZ

> On Friday 20 March 2009 12:08, Morris Riedel wrote:
> > Good morning Aleksandr,
> > 
> > 
> >   >-I see no reason for "either". Also it would be nice to 
> define used
> > terms.
> > >-AFAIK there are no restrictions for using X.509 proxies (aka 
> PC) in TLS.
> > As long as
> > >-we are talking about
> > >-standardaized PCs (RFC 3820) of course.
> > >-For infrastructures relying on full or partial/restricted 
> X.509 identity
> > delegation PC
> > >-(proxy certificate) is
> > >-a must. But I see no reason why that should exclude usage of 
> ordinary> X.509
> > >-certificates/keys as
> > >-mean for identifying (direct or through attributes) 
> communicating parties.
> > 
> > 
> > The reason is basically to precisely define what an endpoint 
> supports, if do
> > not define this precisely interoperability will break since 
> there is a big
> > difference using TLS with or without proxies for the authN 
> check. The either
> 
> I do code for doing authentication with and without proxies. And I 
> never 
> noticed significant difference.
> 
> > is a reason to make it more simpler although there is a polymorphic
> > dependency, but this is not always helpful for the implementations.
> > 
> > Example:
> > 
> > (a)
> > For instance, if we would only claim that the UNICORE Gateway 
> (AuthN check
> > for end-users) supports the PGI_TLS w/o knowing if it uses 
> proxies or not:
> > 
> > If you then use your ARC-Client with proxies and access the 
> Gateway you
> > fail, because the AuthN check only checks for full end-entity 
> certificates.> 
> > (b)
> > For instance, if we would claim that UNICORE Gateway supports 
> PGI_GSI (so
> > proxies including some newly defined PGI revocation mechanism 
> since this is
> > a general GSI problem, or proxy problem although they have 
> limited lifetime)
> > :
> > 
> > If you then use your ARC client with proxies and access the 
> Gateway you win,
> > because the AuthN check climbs up the whole proxy-hierarchy.
> > 
> > If we use our own UNICORE Client with full end-entity 
> certificates it works
> > as well since PGI_GSI MAY include PGI_TLS (your polymorphic item).
> 
> So why not to use last option? Or am I missing something?
> 
> > 
> > ### Conclusions and motivation for either:
> > 
> > (a)
> > So clearly every service that do supports PGI_GSI is able to 
> accept client
> > request based on PGI_TLS only
> > 
> > (b)
> > But every service that purely supports PGI_TLS is not able to 
> accept client
> > requests based on PGI_GSI
> > 
> > Bottom line: the either is needed for differentiation including 
> inherently> your statement of polymorphism that only indicated 
> 'one direction' or 'is-a'
> > and not the other direction!
> 
> If (a) covers (b) then "either (a) or (b)" is not achievable.
> 
> 
> A.K.
> _______________________________________________
> Pgi-wg mailing list
> Pgi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg
> 



-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich

Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------