- pgi-wg - lists.ogf.org

Slides from MWSG Meeting Zurich
by m.riedel＠fz-juelich.de 31 Mar '09

31 Mar '09

Hi PGI team, just4info: the slides we agreed upon/discussed are online at: http://indico.cern.ch/getFile.py/access?contribId=9&sessionId=3&resId=0&mat… I'm gonna present them and ask for comments in a few minutes... 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(a)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.' ------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- -------------------------------------------------------------------

2 1

Re: [Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?
by Duane Merrill 31 Mar '09

31 Mar '09

> > Unless I'm missing something, this spec misses the important use case > where a holder-of-key SAML token is carried in a proxy certificate > (completely analogous to the typical VOMS AC case). > SAML tokens embedded within proxy certificates isn't one of the "common denominators" identified by the pgi-wg as an "authz plumbing" (to borrow Morris' phrasing). And if the point of the PGI-WG is to move forward in a unified direction with SAML instead of documenting the mish-mash myriad of ways for expressing the same thing that exist now, then 2.0 would be the place to hang your hat. -Duane

1 0

Re: [Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?
by weizhong qiang 30 Mar '09

30 Mar '09

hi, On Tue, Mar 31, 2009 at 12:15 AM, Tom Scavo <trscavo(a)gmail.com> wrote: > On Mon, Mar 30, 2009 at 1:16 PM, weizhong qiang <weizhongqiang(a)gmail.com> > wrote: > > > > On Mon, Mar 30, 2009 at 6:46 PM, Tom Scavo <trscavo(a)gmail.com> wrote: > >> > >> On Mon, Mar 30, 2009 at 12:06 PM, weizhong qiang > >> <weizhongqiang(a)gmail.com> wrote: > >> > > >> > 3. <saml:SubjectConfirmation> element contains a <ds:X509Certificate> > >> > element, but it probably be better to just contain a <ds:KeyValue>, > >> > since > >> > the certificates chain of the "subject" is already supposed to be > >> > verified > >> > by the third-party authority (in this case, it is voms saml service), > >> > and > >> > then this public key is used to sign the soap message afterwards. > >> > >> I don't see what the certificate chain has to do with the use of the > >> <ds:X509Certificate> element in this case. The latter requires the > >> presenter to prove possession of the private key corresponding to the > >> public key bound to the certificate. What does that have to do with > >> the presented certificate chain? > > > > two types of verification here: > > 1. verify that "possession of the private key corresponding to the public > > key bound to the certificate" > > Which is required for holder-of-key subject confirmation, yes. > > > 2. verify that "possession of the private key corresponding to the public > > key bound to the certificate" + verify that the certificate is signed by > > trusted authority (in this case verification of certificates chain is > > needed.) > > > > What I meant is for SAML Token profile, step 2 is not needed. > > Okay. > > >> > <ds:KeyValue> is also convinient for proxy certificate, in my opinion. > >> > >> I don't see what <ds:KeyValue> gains you in this case, but I may be > >> missing something. Unless you can provide a good reason for using > >> <ds:KeyValue>, I recommend <ds:X509SubjectName> or <ds:X509SKI>, in > >> that order. The <ds:X509SubjectName> element is simplest for proxy > >> certificates, I think. It is equivalent to the subject confirmation > >> implied in VOMS proxies, in fact. > > > > Probably <ds:KeyValue> can not gain more than <ds:X509Certificate> > (formerly > > I supposed the <ds:KeyValue> should be standarlized) . But by using > > <ds:X509SubjectName>, what is the way to get the public key, which is > > required when verifying the signature to SOAP message. > > Suppose that the presenter authenticates to the relying party Here in my understanding the presenter (requester) does not need to authenticate to relying-party (resource) by using its credential, because the presenter has already authenticated to IdP (STS, secure token service, or whatever other names), and the authentication result (a SAML Token with <saml:SubjectConfirmation> inside) is supposed to be trusted by relying party (if there is trust relationship between IdP and resource). So the preseter is not supposed to use it credential to authenticate against Resource once more (here I am talking in the contex if SOAP message is protected by SAML Token, by using the presenter's private key to make signature for SOAP message). Weizhong Qiang > using a > proxy credential signed by the same X.509 end-entity credential used > to request the assertion from the IdP in the first place. > (Authentication can be by transport-level or message-level as you > mentioned earlier.) By proving possession of the private key > associated with the proxy, the presenter has proven that it is the > subject given by the subject DN in the end-entity certificate of the > presented proxy certificate chain. Thus any holder-of-key SAML > assertion containing that DN is automatically confirmed. > > >> In any event, I should point out that the SAML V2.0 Holder-of-Key > >> Assertion Profile is now in its formal Public Review period, and it > >> does not profile <ds:KeyValue>, so if you think that's an error of > >> omission, it would be good if you could submit a public comment to > >> that effect. > >> > >> > http://lists.oasis-open.org/archives/security-services/200903/msg00062.html > > > > Is any of the draft you mentioned in this link supposed to update/replace > > the WS-Security SAML Token 1.1 profile? > > No, the WSS Technical Committee is closed so I don't anticipate any > changes to be made to the WSS token profiles. > > Tom >

1 0

Re: [Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?
by Duane Merrill 30 Mar '09

30 Mar '09

https://forge.gridforum.org/sf/go/doc15575?nav=1 -Duane On Mon, Mar 30, 2009 at 5:41 PM, Tom Scavo <trscavo(a)gmail.com> wrote: > Duane, can you post a pointer please? Thanks. > > On Mon, Mar 30, 2009 at 5:37 PM, Duane Merrill <dgm4d(a)virginia.edu> wrote: > > BTW, the original PGI Strawman contains some considerations for what > exactly > > what you are discussing, regarding a SOAP-SAML-attribute profile. > > > > -Duane > > > > > > > > 2009/3/30 weizhong qiang <weizhongqiang(a)gmail.com> > >> > >> hi, > >> > >> On Mon, Mar 30, 2009 at 6:46 PM, Tom Scavo <trscavo(a)gmail.com> wrote: > >>> > >>> On Mon, Mar 30, 2009 at 12:06 PM, weizhong qiang > >>> <weizhongqiang(a)gmail.com> wrote: > >>> > > >>> > For a SAML Token which is compliant to SAML V1.1... > >>> > > >>> > For a SAML Token which is compliant to SAML V2.0... > >>> > >>> It should be noted that these examples from the WSS SAML Token Profile > >>> are not normative. Indeed, the SAML V2.0 token is not even > >>> schema-valid. > >> > >> Thanks. I did not know that. But I also thought this part of > specification > >> in WS-Security is not so clearly defined. > >> > >>> > >>> > 1. The signature for <saml:Reponse> could also be necessary, even > >>> > though the > >>> > integrity is guaranteed by TLS. > >>> > >>> That's unlikely, I think. The Response is consumed by the requester > >>> (it does not appear in the SOAP header) so there's really no need > >>> (that I can see) to sign the Response if the request is made over > >>> mutually authenticated TLS. > >>> > >>> > 2. xml attribute xsi:type="saml2:KeyInfoConfirmationDataType" could > be > >>> > necessary for <saml2:SubjectConfirmationData/> > >>> > >>> As I recall, that type declaration is optional, but yes, its use is > >>> recommended. > >>> > >>> > 3. <saml:SubjectConfirmation> element contains a <ds:X509Certificate> > >>> > element, but it probably be better to just contain a <ds:KeyValue>, > >>> > since > >>> > the certificates chain of the "subject" is already supposed to be > >>> > verified > >>> > by the third-party authority (in this case, it is voms saml service), > >>> > and > >>> > then this public key is used to sign the soap message afterwards. > >>> > >>> I don't see what the certificate chain has to do with the use of the > >>> <ds:X509Certificate> element in this case. The latter requires the > >>> presenter to prove possession of the private key corresponding to the > >>> public key bound to the certificate. What does that have to do with > >>> the presented certificate chain? > >> > >> two types of verification here: > >> 1. verify that "possession of the private key corresponding to the > public > >> key bound to the certificate" > >> 2. verify that "possession of the private key corresponding to the > public > >> key bound to the certificate" + verify that the certificate is signed by > >> trusted authority (in this case verification of certificates chain is > >> needed.) > >> > >> What I meant is for SAML Token profile, step 2 is not needed. > >> > >>> > >>> > For SOAP > >>> > message verification on the rely-party side, the rely-party do not > need > >>> > to > >>> > verify the certificates chain of "subject". > >>> > >>> I'm not sure I follow you. How does the presenter of the SOAP request > >>> (with SAML token in the SOAP header) authenticate to the SOAP > >>> responder? > >> > >> "authentication" here could not be accurate. > >> SOAP presentor authenticates (via TLS, or SOAP message authentication by > >> using X.509 token) to 3-party authority (trusted by rely-party), and > gets > >> back SAML Token (with the presentor's public key, or certificate inside > as > >> part of <saml:SubjectConfirmation>); Then uses its' own private key to > sign > >> soap message; Afterwards rely-party can verify the signature to SOAP > message > >> (simple verification is needed, just verify that the private key which > >> signes the SOAP message corresponds to the public key in the > >> <saml:SubjectConfirmation>), as well as verify the signature to > >> <saml:Assertion> (simple verification + verifying the certificate in > >> <ds:Signature> is trusted). > >> > >> > >>> > >>> > <ds:KeyValue> is also convinient for proxy certificate, in my > opinion. > >>> > >>> I don't see what <ds:KeyValue> gains you in this case, but I may be > >>> missing something. Unless you can provide a good reason for using > >>> <ds:KeyValue>, I recommend <ds:X509SubjectName> or <ds:X509SKI>, in > >>> that order. The <ds:X509SubjectName> element is simplest for proxy > >>> certificates, I think. It is equivalent to the subject confirmation > >>> implied in VOMS proxies, in fact. > >> > >> Probably <ds:KeyValue> can not gain more than <ds:X509Certificate> > >> (formerly I supposed the <ds:KeyValue> should be standarlized) . But by > >> using <ds:X509SubjectName>, what is the way to get the public key, > which is > >> required when verifying the signature to SOAP message. > >> > >>> > >>> In any event, I should point out that the SAML V2.0 Holder-of-Key > >>> Assertion Profile is now in its formal Public Review period, and it > >>> does not profile <ds:KeyValue>, so if you think that's an error of > >>> omission, it would be good if you could submit a public comment to > >>> that effect. > >>> > >>> > >>> > http://lists.oasis-open.org/archives/security-services/200903/msg00062.html > >> > >> Is any of the draft you mentioned in this link supposed to > update/replace > >> the WS-Security SAML Token 1.1 profile? > >> > >> > >> Weizhong Qiang > >> > >> > >>> > >>> > >>> > 4. Use <saml:Statement> instead of <saml:AttributeStatement>. > >>> > >>> Why? The <saml:Statement> element is abstract so that would require a > >>> type. What type do you recommend (if not > >>> saml:AttributeStatementType)? > >>> > >>> Tom > >>> > >>> > On Mon, Mar 30, 2009 at 5:00 PM, Tom Scavo <trscavo(a)gmail.com> > wrote: > >>> >> > >>> >> Hi Weizhong, > >>> >> > >>> >> Can you outline why you think the VOMS SAML assertion is not > >>> >> compatible with the WSS SAML Token Profile? > >>> >> > >>> >> Thanks, > >>> >> Tom > >>> >> > >>> >> PS. The comments quoted below mostly refer to a VOMS SAML assertion > >>> >> bound to an X.509 proxy certificate (but the requirements are not > the > >>> >> same as a VOMS SAML assertion bound to SOAP header). > >>> >> > >>> >> On Mon, Mar 30, 2009 at 10:25 AM, weizhong qiang > >>> >> <weizhongqiang(a)gmail.com> wrote: > >>> >> > hi voms folks, all, > >>> >> > The current voms SAML assertion is not compatible with WS-Security > >>> >> > SAML > >>> >> > Token profile. I would ask is there any plan to change it to make > it > >>> >> > be > >>> >> > compatible? I ask this because I think if so, the SAML assertion > can > >>> >> > be > >>> >> > used > >>> >> > for SOAP message layer authentication, other than just including > >>> >> > SAML > >>> >> > attribute assertion. > >>> >> > > >>> >> > > >>> >> > Thanks > >>> >> > Weizhong Qiang > >>> >> > > >>> >> > > >>> >> > On Tue, Feb 10, 2009 at 5:21 AM, Tom Scavo <trscavo(a)gmail.com> > >>> >> > wrote: > >>> >> >> > >>> >> >> Thanks to Benjamin for posting this VOMS-SAML response to > gt-user. > >>> >> >> A > >>> >> >> critique (of the SAML, not Benjamin :) follows. > >>> >> >> > >>> >> >> - Note that the output is a <samlp:Response> element, not a > >>> >> >> <saml:Assertion> element. This is wrong. The requester must > >>> >> >> consume > >>> >> >> the response. Not sure why this isn't happening. > >>> >> >> > >>> >> >> - The value of the <saml:Issuer> element in the response is a DN > >>> >> >> but > >>> >> >> the Format XML attribute is missing. This is a bug. The default > >>> >> >> Format is "unspecified" but clearly this is not. > >>> >> >> > >>> >> >> - Second-level status codes are desirable so they can be echoed > on > >>> >> >> the > >>> >> >> command line (if any). > >>> >> >> > >>> >> >> - Same comment about the <saml:Issuer> element in the assertion. > >>> >> >> > >>> >> >> - The use of SAML metadata requires that the Format on the > >>> >> >> <saml:Issuer> element be "entity" but clearly it is not. Thus > the > >>> >> >> use > >>> >> >> of SAML metadata by the relying party is precluded. > >>> >> >> > >>> >> >> - Don't know if Shibboleth/OpenSAML can verify the signature > (which > >>> >> >> is > >>> >> >> tricky business). This is a future experiment that needs to be > >>> >> >> done. > >>> >> >> > >>> >> >> - The <saml:SubjectConfirmation> element contains a > >>> >> >> <ds:X509Certificate> element, which precludes the binding of this > >>> >> >> holder-of-key assertion to a proxy certificate. This is a bug. > >>> >> >> Use a > >>> >> >> <ds:X509SubjectName> element instead (which causes the NameID > >>> >> >> itself > >>> >> >> to be redundant). > >>> >> >> > >>> >> >> - If the assertion is bound to a proxy certificate, the NotBefore > >>> >> >> and > >>> >> >> NotOnOrAfter attributes are redundant and superfluous. In fact, > >>> >> >> they > >>> >> >> may be wrong since they must agree with the NotBefore and > >>> >> >> NotOnOrAfter > >>> >> >> fields of the proxy. > >>> >> >> > >>> >> >> - Since the client authenticated directly to the server, a > >>> >> >> <saml:AuthnStatement> is desirable (not required, but potentially > >>> >> >> useful at the relying party). > >>> >> >> > >>> >> >> - The NameFormat XML attribute on the <saml:Attribute> element > >>> >> >> should > >>> >> >> be "uri" not "unspecified". > >>> >> >> > >>> >> >> - The "xsi:" prefix on the <saml:AttributeValue> element is > >>> >> >> undefined. > >>> >> >> This is a bug. > >>> >> >> > >>> >> >> - The <saml:AttributeValue> elements do not conform to the XACML > >>> >> >> Attribute Profile (actually, I don't think the attributes conform > >>> >> >> to > >>> >> >> *any* SAML V2.0 attribute profile). > >>> >> >> > >>> >> >> Hope this helps, > >>> >> >> Tom > >>> >> >> > >>> >> >> ---------- Forwarded message ---------- > >>> >> >> From: Benjamin Henne <henne(a)rvs.uni-hannover.de> > >>> >> >> Date: Wed, Feb 4, 2009 at 1:59 AM > >>> >> >> Subject: Re: [gt-user] SAML based VOMS Server > >>> >> >> To: Tom Scavo <trscavo(a)gmail.com> > >>> >> >> Cc: GT User <gt-user(a)globus.org> > >>> >> >> > >>> >> >> > >>> >> >> <Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" > >>> >> >> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > >>> >> >> ID="_d01d46b7-d16a-4ae8-b9bb-beb8844838b6" > >>> >> >> InResponseTo="_qwertyuiopasdfghjklzxcvbn" > >>> >> >> IssueInstant="2008-10-16T19:03:57.922Z" Version="2.0"> > >>> >> >> <saml:Issuer > >>> >> >> > >>> >> >> > >>> >> >> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">CN= > voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > >>> >> >> <Status> > >>> >> >> <StatusCode > Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> > >>> >> >> </Status> > >>> >> >> <saml:Assertion > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > >>> >> >> ID="_81b685e5-4650-4ba9-b1c6-0ed957cc33ac" > >>> >> >> IssueInstant="2008-10-16T19:03:57.920Z" Version="2.0"> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> <saml:Issuer>CN=voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > >>> >> >> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > >>> >> >> <ds:SignedInfo> > >>> >> >> <ds:CanonicalizationMethod > >>> >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >>> >> >> <ds:SignatureMethod > >>> >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> > >>> >> >> <ds:Reference URI="#_81b685e5-4650-4ba9-b1c6-0ed957cc33ac"> > >>> >> >> <ds:Transforms> > >>> >> >> <ds:Transform > >>> >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature > "/> > >>> >> >> <ds:Transform > >>> >> >> > >>> >> >> > >>> >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n# > "><ec:InclusiveNamespaces > >>> >> >> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" > PrefixList="ds > >>> >> >> saml > >>> >> >> xs"/></ds:Transform> > >>> >> >> </ds:Transforms> > >>> >> >> <ds:DigestMethod > >>> >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> > >>> >> >> <ds:DigestValue>j55K/cn8GQNuTQ52Kr3r0NGRJ0w=</ds:DigestValue> > >>> >> >> </ds:Reference> > >>> >> >> </ds:SignedInfo> > >>> >> >> <ds:SignatureValue> > >>> >> >> ... > >>> >> >> </ds:SignatureValue> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > <ds:KeyInfo><ds:X509Data><ds:X509Certificate>...</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature> > >>> >> >> <saml:Subject> > >>> >> >> <saml:NameID > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=Benjamin > >>> >> >> Henne,OU=UniHannover,O=GermanGrid,C=DE</saml:NameID> > >>> >> >> <saml:SubjectConfirmation > >>> >> >> Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"> > >>> >> >> <saml:SubjectConfirmationData> > >>> >> >> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig# > "> > >>> >> >> <ds:X509Data> > >>> >> >> <ds:X509Certificate>...</ds:X509Certificate> > >>> >> >> </ds:X509Data> > >>> >> >> </ds:KeyInfo> > >>> >> >> </saml:SubjectConfirmationData> > >>> >> >> </saml:SubjectConfirmation> > >>> >> >> </saml:Subject> > >>> >> >> <saml:Conditions NotBefore="2008-10-16T19:03:57.920Z" > >>> >> >> NotOnOrAfter="2008-10-17T06:03:57.920Z"/> > >>> >> >> <saml:AttributeStatement> > >>> >> >> <saml:Attribute Name="http://voms.forge.cnaf.infn.it/roles" > >>> >> >> > >>> >> >> > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">VO-Admin@/RVS</saml:AttributeValue> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">resass@/RVS/education</saml:AttributeValue> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">staff@ > /RVS/research/SAML</saml:AttributeValue> > >>> >> >> </saml:Attribute> > >>> >> >> <saml:Attribute Name="nationality" > >>> >> >> > >>> >> >> > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">German</saml:AttributeValue> > >>> >> >> </saml:Attribute> > >>> >> >> <saml:Attribute Name="http://voms.forge.cnaf.infn.it/group" > >>> >> >> > >>> >> >> > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">/RVS/education</saml:AttributeValue> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">/RVS</saml:AttributeValue> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">/RVS/research</saml:AttributeValue> > >>> >> >> </saml:Attribute> > >>> >> >> </saml:AttributeStatement> > >>> >> >> </saml:Assertion> > >>> >> >> </Response> > >>> >> > > >>> >> > > >>> > > >>> > > >> > >> > >> _______________________________________________ > >> Pgi-wg mailing list > >> Pgi-wg(a)ogf.org > >> http://www.ogf.org/mailman/listinfo/pgi-wg > >> > > > > >

1 0

Re: [Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?
by weizhong qiang 30 Mar '09

30 Mar '09

hi, On Mon, Mar 30, 2009 at 6:46 PM, Tom Scavo <trscavo(a)gmail.com> wrote: > On Mon, Mar 30, 2009 at 12:06 PM, weizhong qiang > <weizhongqiang(a)gmail.com> wrote: > > > > For a SAML Token which is compliant to SAML V1.1... > > > > For a SAML Token which is compliant to SAML V2.0... > > It should be noted that these examples from the WSS SAML Token Profile > are not normative. Indeed, the SAML V2.0 token is not even > schema-valid. Thanks. I did not know that. But I also thought this part of specification in WS-Security is not so clearly defined. > > > > 1. The signature for <saml:Reponse> could also be necessary, even though > the > > integrity is guaranteed by TLS. > > That's unlikely, I think. The Response is consumed by the requester > (it does not appear in the SOAP header) so there's really no need > (that I can see) to sign the Response if the request is made over > mutually authenticated TLS. > > > 2. xml attribute xsi:type="saml2:KeyInfoConfirmationDataType" could be > > necessary for <saml2:SubjectConfirmationData/> > > As I recall, that type declaration is optional, but yes, its use is > recommended. > > > 3. <saml:SubjectConfirmation> element contains a <ds:X509Certificate> > > element, but it probably be better to just contain a <ds:KeyValue>, since > > the certificates chain of the "subject" is already supposed to be > verified > > by the third-party authority (in this case, it is voms saml service), and > > then this public key is used to sign the soap message afterwards. > > I don't see what the certificate chain has to do with the use of the > <ds:X509Certificate> element in this case. The latter requires the > presenter to prove possession of the private key corresponding to the > public key bound to the certificate. What does that have to do with > the presented certificate chain? two types of verification here: 1. verify that "possession of the private key corresponding to the public key bound to the certificate" 2. verify that "possession of the private key corresponding to the public key bound to the certificate" + verify that the certificate is signed by trusted authority (in this case verification of certificates chain is needed.) What I meant is for SAML Token profile, step 2 is not needed. > > > > For SOAP > > message verification on the rely-party side, the rely-party do not need > to > > verify the certificates chain of "subject". > > I'm not sure I follow you. How does the presenter of the SOAP request > (with SAML token in the SOAP header) authenticate to the SOAP > responder? "authentication" here could not be accurate. SOAP presentor authenticates (via TLS, or SOAP message authentication by using X.509 token) to 3-party authority (trusted by rely-party), and gets back SAML Token (with the presentor's public key, or certificate inside as part of <saml:SubjectConfirmation>); Then uses its' own private key to sign soap message; Afterwards rely-party can verify the signature to SOAP message (simple verification is needed, just verify that the private key which signes the SOAP message corresponds to the public key in the <saml:SubjectConfirmation>), as well as verify the signature to <saml:Assertion> (simple verification + verifying the certificate in <ds:Signature> is trusted). > > > > <ds:KeyValue> is also convinient for proxy certificate, in my opinion. > > I don't see what <ds:KeyValue> gains you in this case, but I may be > missing something. Unless you can provide a good reason for using > <ds:KeyValue>, I recommend <ds:X509SubjectName> or <ds:X509SKI>, in > that order. The <ds:X509SubjectName> element is simplest for proxy > certificates, I think. It is equivalent to the subject confirmation > implied in VOMS proxies, in fact. Probably <ds:KeyValue> can not gain more than <ds:X509Certificate> (formerly I supposed the <ds:KeyValue> should be standarlized) . But by using <ds:X509SubjectName>, what is the way to get the public key, which is required when verifying the signature to SOAP message. > > > In any event, I should point out that the SAML V2.0 Holder-of-Key > Assertion Profile is now in its formal Public Review period, and it > does not profile <ds:KeyValue>, so if you think that's an error of > omission, it would be good if you could submit a public comment to > that effect. > > http://lists.oasis-open.org/archives/security-services/200903/msg00062.html Is any of the draft you mentioned in this link supposed to update/replace the WS-Security SAML Token 1.1 profile? Weizhong Qiang > > > > 4. Use <saml:Statement> instead of <saml:AttributeStatement>. > > Why? The <saml:Statement> element is abstract so that would require a > type. What type do you recommend (if not > saml:AttributeStatementType)? > > Tom > > > On Mon, Mar 30, 2009 at 5:00 PM, Tom Scavo <trscavo(a)gmail.com> wrote: > >> > >> Hi Weizhong, > >> > >> Can you outline why you think the VOMS SAML assertion is not > >> compatible with the WSS SAML Token Profile? > >> > >> Thanks, > >> Tom > >> > >> PS. The comments quoted below mostly refer to a VOMS SAML assertion > >> bound to an X.509 proxy certificate (but the requirements are not the > >> same as a VOMS SAML assertion bound to SOAP header). > >> > >> On Mon, Mar 30, 2009 at 10:25 AM, weizhong qiang > >> <weizhongqiang(a)gmail.com> wrote: > >> > hi voms folks, all, > >> > The current voms SAML assertion is not compatible with WS-Security > SAML > >> > Token profile. I would ask is there any plan to change it to make it > be > >> > compatible? I ask this because I think if so, the SAML assertion can > be > >> > used > >> > for SOAP message layer authentication, other than just including SAML > >> > attribute assertion. > >> > > >> > > >> > Thanks > >> > Weizhong Qiang > >> > > >> > > >> > On Tue, Feb 10, 2009 at 5:21 AM, Tom Scavo <trscavo(a)gmail.com> wrote: > >> >> > >> >> Thanks to Benjamin for posting this VOMS-SAML response to gt-user. A > >> >> critique (of the SAML, not Benjamin :) follows. > >> >> > >> >> - Note that the output is a <samlp:Response> element, not a > >> >> <saml:Assertion> element. This is wrong. The requester must consume > >> >> the response. Not sure why this isn't happening. > >> >> > >> >> - The value of the <saml:Issuer> element in the response is a DN but > >> >> the Format XML attribute is missing. This is a bug. The default > >> >> Format is "unspecified" but clearly this is not. > >> >> > >> >> - Second-level status codes are desirable so they can be echoed on > the > >> >> command line (if any). > >> >> > >> >> - Same comment about the <saml:Issuer> element in the assertion. > >> >> > >> >> - The use of SAML metadata requires that the Format on the > >> >> <saml:Issuer> element be "entity" but clearly it is not. Thus the > use > >> >> of SAML metadata by the relying party is precluded. > >> >> > >> >> - Don't know if Shibboleth/OpenSAML can verify the signature (which > is > >> >> tricky business). This is a future experiment that needs to be done. > >> >> > >> >> - The <saml:SubjectConfirmation> element contains a > >> >> <ds:X509Certificate> element, which precludes the binding of this > >> >> holder-of-key assertion to a proxy certificate. This is a bug. Use > a > >> >> <ds:X509SubjectName> element instead (which causes the NameID itself > >> >> to be redundant). > >> >> > >> >> - If the assertion is bound to a proxy certificate, the NotBefore and > >> >> NotOnOrAfter attributes are redundant and superfluous. In fact, they > >> >> may be wrong since they must agree with the NotBefore and > NotOnOrAfter > >> >> fields of the proxy. > >> >> > >> >> - Since the client authenticated directly to the server, a > >> >> <saml:AuthnStatement> is desirable (not required, but potentially > >> >> useful at the relying party). > >> >> > >> >> - The NameFormat XML attribute on the <saml:Attribute> element should > >> >> be "uri" not "unspecified". > >> >> > >> >> - The "xsi:" prefix on the <saml:AttributeValue> element is > undefined. > >> >> This is a bug. > >> >> > >> >> - The <saml:AttributeValue> elements do not conform to the XACML > >> >> Attribute Profile (actually, I don't think the attributes conform to > >> >> *any* SAML V2.0 attribute profile). > >> >> > >> >> Hope this helps, > >> >> Tom > >> >> > >> >> ---------- Forwarded message ---------- > >> >> From: Benjamin Henne <henne(a)rvs.uni-hannover.de> > >> >> Date: Wed, Feb 4, 2009 at 1:59 AM > >> >> Subject: Re: [gt-user] SAML based VOMS Server > >> >> To: Tom Scavo <trscavo(a)gmail.com> > >> >> Cc: GT User <gt-user(a)globus.org> > >> >> > >> >> > >> >> <Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" > >> >> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > >> >> ID="_d01d46b7-d16a-4ae8-b9bb-beb8844838b6" > >> >> InResponseTo="_qwertyuiopasdfghjklzxcvbn" > >> >> IssueInstant="2008-10-16T19:03:57.922Z" Version="2.0"> > >> >> <saml:Issuer > >> >> > >> >> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">CN= > voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > >> >> <Status> > >> >> <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> > >> >> </Status> > >> >> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > >> >> ID="_81b685e5-4650-4ba9-b1c6-0ed957cc33ac" > >> >> IssueInstant="2008-10-16T19:03:57.920Z" Version="2.0"> > >> >> > >> >> > >> >> <saml:Issuer>CN=voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > >> >> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > >> >> <ds:SignedInfo> > >> >> <ds:CanonicalizationMethod > >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >> >> <ds:SignatureMethod > >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> > >> >> <ds:Reference URI="#_81b685e5-4650-4ba9-b1c6-0ed957cc33ac"> > >> >> <ds:Transforms> > >> >> <ds:Transform > >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> > >> >> <ds:Transform > >> >> > >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n# > "><ec:InclusiveNamespaces > >> >> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds > saml > >> >> xs"/></ds:Transform> > >> >> </ds:Transforms> > >> >> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1 > "/> > >> >> <ds:DigestValue>j55K/cn8GQNuTQ52Kr3r0NGRJ0w=</ds:DigestValue> > >> >> </ds:Reference> > >> >> </ds:SignedInfo> > >> >> <ds:SignatureValue> > >> >> ... > >> >> </ds:SignatureValue> > >> >> > >> >> > >> >> > <ds:KeyInfo><ds:X509Data><ds:X509Certificate>...</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature> > >> >> <saml:Subject> > >> >> <saml:NameID > >> >> > >> >> > >> >> > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=Benjamin > >> >> Henne,OU=UniHannover,O=GermanGrid,C=DE</saml:NameID> > >> >> <saml:SubjectConfirmation > >> >> Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"> > >> >> <saml:SubjectConfirmationData> > >> >> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > >> >> <ds:X509Data> > >> >> <ds:X509Certificate>...</ds:X509Certificate> > >> >> </ds:X509Data> > >> >> </ds:KeyInfo> > >> >> </saml:SubjectConfirmationData> > >> >> </saml:SubjectConfirmation> > >> >> </saml:Subject> > >> >> <saml:Conditions NotBefore="2008-10-16T19:03:57.920Z" > >> >> NotOnOrAfter="2008-10-17T06:03:57.920Z"/> > >> >> <saml:AttributeStatement> > >> >> <saml:Attribute Name="http://voms.forge.cnaf.infn.it/roles" > >> >> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">VO-Admin@/RVS</saml:AttributeValue> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">resass@/RVS/education</saml:AttributeValue> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">staff@/RVS/research/SAML</saml:AttributeValue> > >> >> </saml:Attribute> > >> >> <saml:Attribute Name="nationality" > >> >> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">German</saml:AttributeValue> > >> >> </saml:Attribute> > >> >> <saml:Attribute Name="http://voms.forge.cnaf.infn.it/group" > >> >> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">/RVS/education</saml:AttributeValue> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">/RVS</saml:AttributeValue> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">/RVS/research</saml:AttributeValue> > >> >> </saml:Attribute> > >> >> </saml:AttributeStatement> > >> >> </saml:Assertion> > >> >> </Response> > >> > > >> > > > > > >

2 1

Re: [Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?
by weizhong qiang 30 Mar '09

30 Mar '09

hi voms folks, all, The current voms SAML assertion is not compatible with WS-Security SAML Token profile. I would ask is there any plan to change it to make it be compatible? I ask this because I think if so, the SAML assertion can be used for SOAP message layer authentication, other than just including SAML attribute assertion. Thanks Weizhong Qiang On Tue, Feb 10, 2009 at 5:21 AM, Tom Scavo <trscavo(a)gmail.com> wrote: > Thanks to Benjamin for posting this VOMS-SAML response to gt-user. A > critique (of the SAML, not Benjamin :) follows. > > - Note that the output is a <samlp:Response> element, not a > <saml:Assertion> element. This is wrong. The requester must consume > the response. Not sure why this isn't happening. > > - The value of the <saml:Issuer> element in the response is a DN but > the Format XML attribute is missing. This is a bug. The default > Format is "unspecified" but clearly this is not. > > - Second-level status codes are desirable so they can be echoed on the > command line (if any). > > - Same comment about the <saml:Issuer> element in the assertion. > > - The use of SAML metadata requires that the Format on the > <saml:Issuer> element be "entity" but clearly it is not. Thus the use > of SAML metadata by the relying party is precluded. > > - Don't know if Shibboleth/OpenSAML can verify the signature (which is > tricky business). This is a future experiment that needs to be done. > > - The <saml:SubjectConfirmation> element contains a > <ds:X509Certificate> element, which precludes the binding of this > holder-of-key assertion to a proxy certificate. This is a bug. Use a > <ds:X509SubjectName> element instead (which causes the NameID itself > to be redundant). > > - If the assertion is bound to a proxy certificate, the NotBefore and > NotOnOrAfter attributes are redundant and superfluous. In fact, they > may be wrong since they must agree with the NotBefore and NotOnOrAfter > fields of the proxy. > > - Since the client authenticated directly to the server, a > <saml:AuthnStatement> is desirable (not required, but potentially > useful at the relying party). > > - The NameFormat XML attribute on the <saml:Attribute> element should > be "uri" not "unspecified". > > - The "xsi:" prefix on the <saml:AttributeValue> element is undefined. > This is a bug. > > - The <saml:AttributeValue> elements do not conform to the XACML > Attribute Profile (actually, I don't think the attributes conform to > *any* SAML V2.0 attribute profile). > > Hope this helps, > Tom > > ---------- Forwarded message ---------- > From: Benjamin Henne <henne(a)rvs.uni-hannover.de> > Date: Wed, Feb 4, 2009 at 1:59 AM > Subject: Re: [gt-user] SAML based VOMS Server > To: Tom Scavo <trscavo(a)gmail.com> > Cc: GT User <gt-user(a)globus.org> > > > <Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > ID="_d01d46b7-d16a-4ae8-b9bb-beb8844838b6" > InResponseTo="_qwertyuiopasdfghjklzxcvbn" > IssueInstant="2008-10-16T19:03:57.922Z" Version="2.0"> > <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">CN= > voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > <Status> > <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> > </Status> > <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > ID="_81b685e5-4650-4ba9-b1c6-0ed957cc33ac" > IssueInstant="2008-10-16T19:03:57.920Z" Version="2.0"> > <saml:Issuer>CN=voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > <ds:SignedInfo> > <ds:CanonicalizationMethod Algorithm=" > http://www.w3.org/2001/10/xml-exc-c14n#"/> > <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1 > "/> > <ds:Reference URI="#_81b685e5-4650-4ba9-b1c6-0ed957cc33ac"> > <ds:Transforms> > <ds:Transform Algorithm=" > http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> > <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n# > "><ec:InclusiveNamespaces > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds saml > xs"/></ds:Transform> > </ds:Transforms> > <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> > <ds:DigestValue>j55K/cn8GQNuTQ52Kr3r0NGRJ0w=</ds:DigestValue> > </ds:Reference> > </ds:SignedInfo> > <ds:SignatureValue> > ... > </ds:SignatureValue> > > <ds:KeyInfo><ds:X509Data><ds:X509Certificate>...</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature> > <saml:Subject> > <saml:NameID > > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=Benjamin > Henne,OU=UniHannover,O=GermanGrid,C=DE</saml:NameID> > <saml:SubjectConfirmation > Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"> > <saml:SubjectConfirmationData> > <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > <ds:X509Data> > <ds:X509Certificate>...</ds:X509Certificate> > </ds:X509Data> > </ds:KeyInfo> > </saml:SubjectConfirmationData> > </saml:SubjectConfirmation> > </saml:Subject> > <saml:Conditions NotBefore="2008-10-16T19:03:57.920Z" > NotOnOrAfter="2008-10-17T06:03:57.920Z"/> > <saml:AttributeStatement> > <saml:Attribute Name="http://voms.forge.cnaf.infn.it/roles" > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">VO-Admin@/RVS</saml:AttributeValue> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">resass@/RVS/education</saml:AttributeValue> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">staff@/RVS/research/SAML</saml:AttributeValue> > </saml:Attribute> > <saml:Attribute Name="nationality" > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">German</saml:AttributeValue> > </saml:Attribute> > <saml:Attribute Name="http://voms.forge.cnaf.infn.it/group" > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">/RVS/education</saml:AttributeValue> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">/RVS</saml:AttributeValue> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">/RVS/research</saml:AttributeValue> > </saml:Attribute> > </saml:AttributeStatement> > </saml:Assertion> > </Response> >

2 2

Re: [Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?
by weizhong qiang 30 Mar '09

30 Mar '09

hi, According to the specification of SAML Token profile 1.1 ( http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SA…) I listed the difference as follows, some of the points are trivial . For a SAML Token which is compliant to SAML V1.1: <saml:Assertion xmlns:saml="..." AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant="2005-05-27T16:53:33.173Z" Issuer=”www.opensaml.org” MajorVersion="1" MinorVersion="1"> <saml:Conditions NotBefore="2005-05-27T16:53:33.173Z" NotOnOrAfter="2005-05-27T16:58:33.17302Z"/> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier NameQualifier="www.example.com" Format=“urn:oasis:names:tc:SAML:1.1:nameid- format:X509SubjectName”> uid=joe,ou=people,ou=saml-demo,o=baltimore.com </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:holder-of-key </saml:ConfirmationMethod> <ds:KeyInfo> <ds:KeyValue>...</ds:KeyValue> </ds:KeyInfo> </saml:SubjectConfirmation> </saml:Subject> <saml:Attribute AttributeName="MemberLevel" AttributeNamespace="http://www.oasis- open.org/Catalyst2002/attributes"> <saml:AttributeValue>gold</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeName="E-mail" AttributeNamespace=" http://www.oasis-open.org/Catalyst2002/attributes"> <saml:AttributeValue>joe(a)yahoo.com</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> <ds:Signature>...</ds:Signature> </saml:Assertion> For a SAML Token which is compliant to SAML V2.0: <saml2:Assertion xmlns:saml2="..." xmlns:xsi="..." ID=”_a75adf55-01d7-40cc-929f-dbd8372ebdfc”> <saml2:Subject> <saml2:NameID> ... </saml2:NameID> <saml2:SubjectConfirmation Method=”urn:oasis:names:tc:SAML:2.0:cm:holder-of-key”> <saml2:SubjectConfirmationData xsi:type="saml2:KeyInfoConfirmationDataType"> <ds:KeyInfo> <ds:KeyValue>...</ds:KeyValue> </ds:KeyInfo> </saml2:SubjectConfirmationData> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:Statement> ... </saml2:Statement> <ds:Signature>...</ds:Signature> </saml2:Assertion> Suppose voms saml assertion uses SAML V2.0 Some comments: 1. The signature for <saml:Reponse> could also be necessary, even though the integrity is guaranteed by TLS. 2. xml attribute xsi:type="saml2:KeyInfoConfirmationDataType" could be necessary for <saml2:SubjectConfirmationData/> 3. <saml:SubjectConfirmation> element contains a <ds:X509Certificate> element, but it probably be better to just contain a <ds:KeyValue>, since the certificates chain of the "subject" is already supposed to be verified by the third-party authority (in this case, it is voms saml service), and then this public key is used to sign the soap message afterwards. For SOAP message verification on the rely-party side, the rely-party do not need to verify the certificates chain of "subject". <ds:KeyValue> is also convinient for proxy certificate, in my opinion. 4. Use <saml:Statement> instead of <saml:AttributeStatement>. Cheers, Weizhong On Mon, Mar 30, 2009 at 5:00 PM, Tom Scavo <trscavo(a)gmail.com> wrote: > Hi Weizhong, > > Can you outline why you think the VOMS SAML assertion is not > compatible with the WSS SAML Token Profile? > > Thanks, > Tom > > PS. The comments quoted below mostly refer to a VOMS SAML assertion > bound to an X.509 proxy certificate (but the requirements are not the > same as a VOMS SAML assertion bound to SOAP header). > > On Mon, Mar 30, 2009 at 10:25 AM, weizhong qiang > <weizhongqiang(a)gmail.com> wrote: > > hi voms folks, all, > > The current voms SAML assertion is not compatible with WS-Security SAML > > Token profile. I would ask is there any plan to change it to make it be > > compatible? I ask this because I think if so, the SAML assertion can be > used > > for SOAP message layer authentication, other than just including SAML > > attribute assertion. > > > > > > Thanks > > Weizhong Qiang > > > > > > On Tue, Feb 10, 2009 at 5:21 AM, Tom Scavo <trscavo(a)gmail.com> wrote: > >> > >> Thanks to Benjamin for posting this VOMS-SAML response to gt-user. A > >> critique (of the SAML, not Benjamin :) follows. > >> > >> - Note that the output is a <samlp:Response> element, not a > >> <saml:Assertion> element. This is wrong. The requester must consume > >> the response. Not sure why this isn't happening. > >> > >> - The value of the <saml:Issuer> element in the response is a DN but > >> the Format XML attribute is missing. This is a bug. The default > >> Format is "unspecified" but clearly this is not. > >> > >> - Second-level status codes are desirable so they can be echoed on the > >> command line (if any). > >> > >> - Same comment about the <saml:Issuer> element in the assertion. > >> > >> - The use of SAML metadata requires that the Format on the > >> <saml:Issuer> element be "entity" but clearly it is not. Thus the use > >> of SAML metadata by the relying party is precluded. > >> > >> - Don't know if Shibboleth/OpenSAML can verify the signature (which is > >> tricky business). This is a future experiment that needs to be done. > >> > >> - The <saml:SubjectConfirmation> element contains a > >> <ds:X509Certificate> element, which precludes the binding of this > >> holder-of-key assertion to a proxy certificate. This is a bug. Use a > >> <ds:X509SubjectName> element instead (which causes the NameID itself > >> to be redundant). > >> > >> - If the assertion is bound to a proxy certificate, the NotBefore and > >> NotOnOrAfter attributes are redundant and superfluous. In fact, they > >> may be wrong since they must agree with the NotBefore and NotOnOrAfter > >> fields of the proxy. > >> > >> - Since the client authenticated directly to the server, a > >> <saml:AuthnStatement> is desirable (not required, but potentially > >> useful at the relying party). > >> > >> - The NameFormat XML attribute on the <saml:Attribute> element should > >> be "uri" not "unspecified". > >> > >> - The "xsi:" prefix on the <saml:AttributeValue> element is undefined. > >> This is a bug. > >> > >> - The <saml:AttributeValue> elements do not conform to the XACML > >> Attribute Profile (actually, I don't think the attributes conform to > >> *any* SAML V2.0 attribute profile). > >> > >> Hope this helps, > >> Tom > >> > >> ---------- Forwarded message ---------- > >> From: Benjamin Henne <henne(a)rvs.uni-hannover.de> > >> Date: Wed, Feb 4, 2009 at 1:59 AM > >> Subject: Re: [gt-user] SAML based VOMS Server > >> To: Tom Scavo <trscavo(a)gmail.com> > >> Cc: GT User <gt-user(a)globus.org> > >> > >> > >> <Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" > >> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > >> ID="_d01d46b7-d16a-4ae8-b9bb-beb8844838b6" > >> InResponseTo="_qwertyuiopasdfghjklzxcvbn" > >> IssueInstant="2008-10-16T19:03:57.922Z" Version="2.0"> > >> <saml:Issuer > >> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">CN= > voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > >> <Status> > >> <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> > >> </Status> > >> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > >> ID="_81b685e5-4650-4ba9-b1c6-0ed957cc33ac" > >> IssueInstant="2008-10-16T19:03:57.920Z" Version="2.0"> > >> > >> <saml:Issuer>CN=voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > >> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > >> <ds:SignedInfo> > >> <ds:CanonicalizationMethod > >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >> <ds:SignatureMethod > >> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> > >> <ds:Reference URI="#_81b685e5-4650-4ba9-b1c6-0ed957cc33ac"> > >> <ds:Transforms> > >> <ds:Transform > >> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> > >> <ds:Transform > >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n# > "><ec:InclusiveNamespaces > >> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds saml > >> xs"/></ds:Transform> > >> </ds:Transforms> > >> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> > >> <ds:DigestValue>j55K/cn8GQNuTQ52Kr3r0NGRJ0w=</ds:DigestValue> > >> </ds:Reference> > >> </ds:SignedInfo> > >> <ds:SignatureValue> > >> ... > >> </ds:SignatureValue> > >> > >> > <ds:KeyInfo><ds:X509Data><ds:X509Certificate>...</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature> > >> <saml:Subject> > >> <saml:NameID > >> > >> > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=Benjamin > >> Henne,OU=UniHannover,O=GermanGrid,C=DE</saml:NameID> > >> <saml:SubjectConfirmation > >> Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"> > >> <saml:SubjectConfirmationData> > >> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > >> <ds:X509Data> > >> <ds:X509Certificate>...</ds:X509Certificate> > >> </ds:X509Data> > >> </ds:KeyInfo> > >> </saml:SubjectConfirmationData> > >> </saml:SubjectConfirmation> > >> </saml:Subject> > >> <saml:Conditions NotBefore="2008-10-16T19:03:57.920Z" > >> NotOnOrAfter="2008-10-17T06:03:57.920Z"/> > >> <saml:AttributeStatement> > >> <saml:Attribute Name="http://voms.forge.cnaf.infn.it/roles" > >> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">VO-Admin@/RVS</saml:AttributeValue> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">resass@/RVS/education</saml:AttributeValue> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">staff@/RVS/research/SAML</saml:AttributeValue> > >> </saml:Attribute> > >> <saml:Attribute Name="nationality" > >> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">German</saml:AttributeValue> > >> </saml:Attribute> > >> <saml:Attribute Name="http://voms.forge.cnaf.infn.it/group" > >> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">/RVS/education</saml:AttributeValue> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">/RVS</saml:AttributeValue> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">/RVS/research</saml:AttributeValue> > >> </saml:Attribute> > >> </saml:AttributeStatement> > >> </saml:Assertion> > >> </Response> > > > > >

1 0

Re: [Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?
by Valerio Venturi 30 Mar '09

30 Mar '09

On Mon, 2009-03-30 at 11:00 -0400, Tom Scavo wrote: > Hi Weizhong, > > Can you outline why you think the VOMS SAML assertion is not > compatible with the WSS SAML Token Profile? > > Thanks, > Tom > > PS. The comments quoted below mostly refer to a VOMS SAML assertion > bound to an X.509 proxy certificate (but the requirements are not the > same as a VOMS SAML assertion bound to SOAP header). Correct, and please note that the Strawman profiles the use of SAML assertions in the SOAP Header, not bound with a proxy. Anyway we got that as a use case and are willing to work in a direction that can accomodate both uses. Valerio > On Mon, Mar 30, 2009 at 10:25 AM, weizhong qiang > <weizhongqiang(a)gmail.com> wrote: > > hi voms folks, all, > > The current voms SAML assertion is not compatible with WS-Security SAML > > Token profile. I would ask is there any plan to change it to make it be > > compatible? I ask this because I think if so, the SAML assertion can be used > > for SOAP message layer authentication, other than just including SAML > > attribute assertion. > > > > > > Thanks > > Weizhong Qiang > > > > > > On Tue, Feb 10, 2009 at 5:21 AM, Tom Scavo <trscavo(a)gmail.com> wrote: > >> > >> Thanks to Benjamin for posting this VOMS-SAML response to gt-user. A > >> critique (of the SAML, not Benjamin :) follows. > >> > >> - Note that the output is a <samlp:Response> element, not a > >> <saml:Assertion> element. This is wrong. The requester must consume > >> the response. Not sure why this isn't happening. > >> > >> - The value of the <saml:Issuer> element in the response is a DN but > >> the Format XML attribute is missing. This is a bug. The default > >> Format is "unspecified" but clearly this is not. > >> > >> - Second-level status codes are desirable so they can be echoed on the > >> command line (if any). > >> > >> - Same comment about the <saml:Issuer> element in the assertion. > >> > >> - The use of SAML metadata requires that the Format on the > >> <saml:Issuer> element be "entity" but clearly it is not. Thus the use > >> of SAML metadata by the relying party is precluded. > >> > >> - Don't know if Shibboleth/OpenSAML can verify the signature (which is > >> tricky business). This is a future experiment that needs to be done. > >> > >> - The <saml:SubjectConfirmation> element contains a > >> <ds:X509Certificate> element, which precludes the binding of this > >> holder-of-key assertion to a proxy certificate. This is a bug. Use a > >> <ds:X509SubjectName> element instead (which causes the NameID itself > >> to be redundant). > >> > >> - If the assertion is bound to a proxy certificate, the NotBefore and > >> NotOnOrAfter attributes are redundant and superfluous. In fact, they > >> may be wrong since they must agree with the NotBefore and NotOnOrAfter > >> fields of the proxy. > >> > >> - Since the client authenticated directly to the server, a > >> <saml:AuthnStatement> is desirable (not required, but potentially > >> useful at the relying party). > >> > >> - The NameFormat XML attribute on the <saml:Attribute> element should > >> be "uri" not "unspecified". > >> > >> - The "xsi:" prefix on the <saml:AttributeValue> element is undefined. > >> This is a bug. > >> > >> - The <saml:AttributeValue> elements do not conform to the XACML > >> Attribute Profile (actually, I don't think the attributes conform to > >> *any* SAML V2.0 attribute profile). > >> > >> Hope this helps, > >> Tom > >> > >> ---------- Forwarded message ---------- > >> From: Benjamin Henne <henne(a)rvs.uni-hannover.de> > >> Date: Wed, Feb 4, 2009 at 1:59 AM > >> Subject: Re: [gt-user] SAML based VOMS Server > >> To: Tom Scavo <trscavo(a)gmail.com> > >> Cc: GT User <gt-user(a)globus.org> > >> > >> > >> <Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" > >> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > >> ID="_d01d46b7-d16a-4ae8-b9bb-beb8844838b6" > >> InResponseTo="_qwertyuiopasdfghjklzxcvbn" > >> IssueInstant="2008-10-16T19:03:57.922Z" Version="2.0"> > >> <saml:Issuer > >> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">CN=voms3.gridlab.uni-hannover.de,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > >> <Status> > >> <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> > >> </Status> > >> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > >> ID="_81b685e5-4650-4ba9-b1c6-0ed957cc33ac" > >> IssueInstant="2008-10-16T19:03:57.920Z" Version="2.0"> > >> > >> <saml:Issuer>CN=voms3.gridlab.uni-hannover.de,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > >> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > >> <ds:SignedInfo> > >> <ds:CanonicalizationMethod > >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >> <ds:SignatureMethod > >> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> > >> <ds:Reference URI="#_81b685e5-4650-4ba9-b1c6-0ed957cc33ac"> > >> <ds:Transforms> > >> <ds:Transform > >> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> > >> <ds:Transform > >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces > >> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds saml > >> xs"/></ds:Transform> > >> </ds:Transforms> > >> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> > >> <ds:DigestValue>j55K/cn8GQNuTQ52Kr3r0NGRJ0w=</ds:DigestValue> > >> </ds:Reference> > >> </ds:SignedInfo> > >> <ds:SignatureValue> > >> ... > >> </ds:SignatureValue> > >> > >> <ds:KeyInfo><ds:X509Data><ds:X509Certificate>...</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature> > >> <saml:Subject> > >> <saml:NameID > >> > >> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=Benjamin > >> Henne,OU=UniHannover,O=GermanGrid,C=DE</saml:NameID> > >> <saml:SubjectConfirmation > >> Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"> > >> <saml:SubjectConfirmationData> > >> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > >> <ds:X509Data> > >> <ds:X509Certificate>...</ds:X509Certificate> > >> </ds:X509Data> > >> </ds:KeyInfo> > >> </saml:SubjectConfirmationData> > >> </saml:SubjectConfirmation> > >> </saml:Subject> > >> <saml:Conditions NotBefore="2008-10-16T19:03:57.920Z" > >> NotOnOrAfter="2008-10-17T06:03:57.920Z"/> > >> <saml:AttributeStatement> > >> <saml:Attribute Name="http://voms.forge.cnaf.infn.it/roles" > >> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">VO-Admin@/RVS</saml:AttributeValue> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">resass@/RVS/education</saml:AttributeValue> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">staff@/RVS/research/SAML</saml:AttributeValue> > >> </saml:Attribute> > >> <saml:Attribute Name="nationality" > >> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">German</saml:AttributeValue> > >> </saml:Attribute> > >> <saml:Attribute Name="http://voms.forge.cnaf.infn.it/group" > >> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">/RVS/education</saml:AttributeValue> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">/RVS</saml:AttributeValue> > >> <saml:AttributeValue > >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> xsi:type="xs:string">/RVS/research</saml:AttributeValue> > >> </saml:Attribute> > >> </saml:AttributeStatement> > >> </saml:Assertion> > >> </Response> > > > >

1 0

Re: [Pgi-wg] MWSG Meeting Slides (Drafts) - OpenSSL and GSI areincompatible but use identical X509 proxies
by m.riedel＠fz-juelich.de 30 Mar '09

30 Mar '09

Hi Etienne, thanks for the research. >- 1) OpenSSL and GSI are really incompatible as transport layers. Confirmed, mainly because the do GSI/HTTP making it HTTPG basically... >- 2) But they now accept exactly the same RFC compliant X509 proxies. Good news - and helpful for GridFTP probably - so you may use openssl proxies with GridFTP, so GSI is not required anymore for GridFTP then... >- 3) Old-style GSI X509 proxies are obsolete, and their usage should be forbidden That's clear. >- I suggest that you provide information 2 and 3 at the beginning of the first slide 'TLS with GSI Proxies'. I will do it. Thanks, 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(a)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.' ------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- ------------------------------------------------------------------- Morris, Concerning the MWSG Meeting Slides : About X509 proxies, I just got confirmation from Vincenzo CIASCHINI that : 1) OpenSSL and GSI are really incompatible as transport layers. 2) But they now accept exactly the same RFC compliant X509 proxies. 3) Old-style GSI X509 proxies are obsolete, and their usage should be forbidden I suggest that you provide information 2 and 3 at the beginning of the first slide 'TLS with GSI Proxies'. Best regards. ---------------------------------- Etienne URBAH IN2P3 - LAL Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Mob: +33 6 22 30 53 27 Skype: etienne.urbah mailto:urbah@lal.in2p3.fr ---------------------------------- On Mon, 30 Mar 2009, m.riedel(a)fz-juelich.de wrote: > Hi PGI team, > > I received some contributions already and setup a first draft for the slides I will present tomorrow! > > They are in GridForge - so please comment the whole day today: > > http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/do… > > > The discussions about attributes and constraints I will start just after the coffee break here. ;-) > > Best regards from Zuerich, > Morris > > > > > > ------------------------------------------------------------------- > ------------------------------------------------------------------- > 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 > ------------------------------------------------------------------- > -------------------------------------------------------------------

1 0

MWSG Meeting
by Steven Newhouse 30 Mar '09

30 Mar '09

All, For those interested in dialing in for the PGI presentation and discussion at the Middleware Security Group meeting on Tuesday at 2pm (local) - here are the details. Note Europe has entered daylight saving time so the USA is now back in sync! Steven Event name: MWSG PGI Presentation Coordinator: Name: Christoph Witzig Institution: SWITCH Start date/time: Tue, 2009-03-31 13:50 (Swiss local time) Tue, 2009-03-31 11:50 (UTC) Duration: 01:30 h Number of participants: 10 H.323 (IP) conference dialin: 0041 44 250 96 85 H.320 (ISDN) conference dialin: +41 44 250 96 85 SIP (IP) conference dialin: 85(a)mcu.switch.ch Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse

1 0