[Pgi-wg] Sec: Agreement on SOAP and authentication

Fri Mar 20 07:52:20 CDT 2009

I strongly disagree.

Proxy certs require *additional* path validation.  You *still* have to do
the same PKC path validation on the EEC that the proxies chain to.  This
work has to be done regardless of whether there are proxy certificates in
the chain.  This is a clear "is-a" relationship, a superset of functionality
with PCs.

Let me illustrate with an analogy:  You are tasked to provide requirements
for an email system.  What you are suggesting is analagous to a requirement
that

"The email system must EITHER support email-without-attachments OR
email-with-attachments."

My point is that if you build an email system to support
email-with-attachments you have implicitly already built a system to support
email-without-attachments.

If you make it a requirement to reject PKCs explicitly, you are creating
unnecessary additional complexity in both your services (by explicitly
rejecting certs that do not have the proxy extension) and in your clients
(by mandating that callers with statically-assigned credentials create a
proxy to delegate to themselves just so they can use your service).

-Duane

On Thu, Mar 19, 2009 at 1:20 PM, <m.riedel at fz-juelich.de> wrote:

> Hi Duane,
>
>  have you read the slides about the IIRM and the plumbings concept was
> basically refers to that concept of "either-or".
>
> Although both are X.509 certificates - It's a fundamental difference if you
> have full X.509 end-entity certificates only signes by a CA you trust or
> X.509 certificates signed by users with a chain.
>
> Implementations have to now the difference in order to 'climb the whole
> chain' while doing authentication - that was breaking interoperability in
> the past between numerous implementatio.
>
> In short: my suggestion is to remove too much flexibility by just using
> "either or" for these models that are quite established. Furthermore, I
> would like to decouple the attrauthZ from TLS.
>
> I hope it gets a bit clearer now - but I feel the need for a picture, I
> start to develop a small supportive figure here.
>
> 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: Duane Merrill <dgm4d at virginia.edu>
> Date: Thursday, March 19, 2009 2:40 pm
> Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
>
> > I don't understand the strict "either-or" wording below with
> > regards to PCs
> > versus PKCs in a *proxy-plus-embedded-AC* conformance target.  You
> > make it
> > sound like their use would be unilaterally mutually exclusive.
> > Both types
> > of certificates can embed attribute certificates, and there is an
> > "is-a"/polymorphic relationship here: a PKC is a PC of delegation
> > depth zero
> > (and therefore does not have the extension OID set).
> >
> > A *proxy-plus-embedded-AC* conformance target should describe
> > implementations that allow both.  In the strawman document, the
> > goal of
> > layering the *pgi-tls-proxy* conformance target on top of the
> > *pgi-https*target was to add functionality (not take it away):
> > *pgi-tls-proxy* describes SOAP implementations that perform mutual
> > SSL/TLSauthentication with certificates, and these certificates
> > MAY have proxy
> > extensions (making them PCs) and MAY have AC extensions (embedding
> > attributecertificates).
> >
> > Perhaps I am just misinterpreting your language.
> >
> > -Duane
> >
>  > 2009/3/19 Morris Riedel <m.riedel at fz-juelich.de>
> >
> > > Hi security folks,
> > >
> > >
> > >  reading certain elements of the IIRM, strawman, and following
> > discussions> on the list - I see there is still no common
> > agreement on SOAP / HTTP(S) in
> > > some areas.
> > >
> > > ### Goal:
> > >
> > > (a)
> > > We are discussing if SOAP / HTTPS can be used in PGI to contact a
> > > functional
> > > interface (like BES)...
> > >
> > > (b)
> > > ...because we want to find out if there is any important service
> > in the PGI
> > > context that is not capable of using SOAP (over SSL layer)...
> > >
> > >
> > > (c)
> > > ... in order to find out if we can agree on SOAP/HTTPS or to
> > understand> requirements from other non WS-based interfaces in PGI.
> > >
> > >
> > > Therefore the aim of this thread is to get to an agreement in
> > this context,
> > > while considering Attribute authorities like VOMS as a
> > supportive service
> > > and not an functional interface (also separate thread).
> > >
> > > ### Contacting functional implementations with SOAP
> > >
> > > If we consider the case that we communicate with an functional
> > interface> like OGSA-BES - we agree on SOAP.
> > >
> > > ### TLS/SSL Layer:
> > >
> > > # <strawman>
> > > Foundational: Conveying identity for authentication.
> > > SOAP over HTTPS (PGI_HTTPS).  SOAP-over-HTTP communication using
> > a SSL/TLS
> > > transport protocol in which endpoints are mutually authenticated
> > by X.509
> > > end-entity public key certificates (PKCs).
> > > # </strawman>
> > >
> > >
> > > # <simple plumbings: authentication>
> > > We use authentication either based on identities inside X.509
> > end-entity
> > > public key certificates or X.509 proxies (including
> > restrictions, encoding
> > > handled separately in another thread).
> > >
> > > This refers of using either one or the other of these
> > certificate types on
> > > the SSL/TLS level.
> > >
> > > For simplification of the profile - there should be no direct
> > dependencies> with attribute-transport used for authorization.
> > > # </plumbings>
> > >
> > >
> > > ### Possible scenarios:
> > >
> > > # A. TLS with end-entity certificate, SOAP in message -> authN
> > check with
> > > CA
> > >
> > > # B. TLS with (restricted) proxy certificates, SOAP in message -
> > > authN
> > > check with proxy signer chain
> > >
> > > ### Possible Conclusion:
> > >
> > > # We use SOAP inside a message to contact functional interfaces.
> > >
> > > # We use either full X.509 end-entity certificates OR X.509
> > proxies (with
> > > restrictions)
> > >
> > > ### Open Questions:
> > >
> > >
> > > Q: There are WS interfaces for functional specifications that
> > matter to PGI
> > > (BES, WS-DAIS and SRM) - so in the context of PGI - can we agree
> > on SOAP
> > > based on HTTPS as mentioned above?
> > >
> > > Q: If not - are there any important functional interfaces
> > (except support
> > > interfaces from AAs like classic VOMS) that do not support SOAP
> > in the PGI
> > > ecosystem?
> > >
> > >
> > > Please feel free to comment but let the question of
> > attributes+restrictions> outside -  I propose to deal with it in
> > separate threads because of their
> > > complexity.
> > >
> > >
> > > Take care,
> > > Morris
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------
> > > Morris Riedel
> > > SW - Engineer
> > > Distributed Systems and Grid Computing Division
> > > Jülich Supercomputing Centre (JSC)
> > > Forschungszentrum Juelich
> > > Wilhelm-Johnen-Str. 1
> > > D - 52425 Juelich
> > > Germany
> > >
> > > Email: m.riedel at fz-juelich.de
> > > Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel
> > > Phone: +49 2461 61 - 3651
> > > Fax: +49 2461 61 - 6656
> > >
> > > Skype: MorrisRiedel
> > >
> > > "We work to better ourselves, and the rest of humanity"
> > >
> > > Sitz der Gesellschaft: Jülich
> > > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
> > > Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
> > > Vorstand: Prof. Dr. Achim Bachem (Vorsitzender),
> > > Dr. Ulrich Krafft (stellv. Vorsitzender)
> > >
> > >
> > >
> > > _______________________________________________
> > > Pgi-wg mailing list
> > > Pgi-wg at ogf.org
> > > http://www.ogf.org/mailman/listinfo/pgi-wg
> > >
> > >
> >
>
>
>
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> Forschungszentrum Jülich GmbH
> 52425 Jülich
>
> Sitz der Gesellschaft: Jülich
> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
> Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe
> Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
> Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
> Dr. Sebastian M. Schmidt
> -------------------------------------------------------------------
> -------------------------------------------------------------------
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090320/c64623c8/attachment.html 