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

Fri Mar 20 09:36:44 CDT 2009

On Fri, Mar 20, 2009 at 10:08 AM, <m.riedel at fz-juelich.de> wrote:

>
> Before I send someone an attach - I would like to know if the person has an
> email system with or w/o attachments ;-)
>
Good.  Your original statements came across as "forcing you to make an empty
attach if you didn't want to attach" because of a percieved 1-or-more
attach-requirement.

>
>
>
>
> --------------------------------------------------------------------------------
> 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: Friday, March 20, 2009 1:52 pm
> Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
>
> > 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
> > functionalitywith PCs.
> >
> > Let me illustrate with an analogy:  You are tasked to provide
> > requirementsfor 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
> > creatingunnecessary 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
> > > -----------------------------------------------------------------
> > --
> > > -----------------------------------------------------------------
> > --
> > >
> > >
> > >
> >
>
>
>
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> 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/2d1cab98/attachment-0001.html 