[OGSA-AUTHZ] Implementations
David Chadwick
d.w.chadwick at kent.ac.uk
Sun Mar 23 15:27:01 CDT 2008
Hi Tom
Defects can be of three types (at least). Bug/Broken, meaning that the
standard does not work; Off specification, meaning that the standard
works but does not conform to what is really required; and Enhancement,
meaning that an additional feature is required to be added to the
standard. I was originally suggesting that the defect we are discussing
is of the later type, meaning that the current standard works and is
what is required for many use cases, but does not cover all use cases
(however see my last point below).
So the issues are
a) how does OASIS handle enhancements? Can they be rapidly applied or not?
b) does the OASIS group agree that this enhancement is worthy of adding
in the first place.
ISO/ITU-T and IETF can handle minor enhancements to their (draft)
standards without causing any delay to the publishing cycle. I dont know
if OASIS can do this or not, but if they can this would be my preferred
route given that b) is accepted by the OASIS group.
On the issue of whether the enhancement should be applied to the OASIS
spec or the OGSA spec, this hinges on issue b) above. If the OASIS group
accept it as a valid and needed enhancement then I would suggest adding
it to the OASIS specification. If the OASIS group do not accept it as a
needed enhancement, or it is decided that the enhancement will impact
too much on the publishing cycle of the OASIS standard, then it would be
better to fix it in the OGSA standard since this change should not
significantly impact on the publishing cycle of the OGF document. You
seem to imply that the latter is the case since the number of changes
are quite significant.
Concerning the specific syntax of the change see my comments inline below.
I have read your spec again and have the following queries to make.
i)Section 3.9.3 says "an identity
provider SHOULD check the lifetime of the referenced certificate before
issuing an assertion regarding an
X.509 Subject. If the certificate has expired, an error should be returned.
As a further privacy measure, the principal may use a short-lived X.509
identity certificate. For example,
an X.509 proxy certificate [RFC3820]) may be used."
Questions:
1. How is the subject's current X.509 certificate identified by the SP
to the IDP? The protocol does not seem to carry this as currently specified.
2. Is the IDP supposed to pull the subject's X.509 PKC from somewhere
before replying to the SP's request? I think section 3.10.2 is a very
weak response to this problem and merely punts the issue onto the IDP.
3. How does the IDP know that the subject has used a proxy certificate
to contact the SP, and if so, how does the IDP get hold of this to
verify its validity time?
It seems to me that your current spec might actually be broken in
respects of the proxy certificate and therefore need fixing before it is
published. The enhancement we are discussing can actually be a fix for
this bug.
Tom Scavo wrote:
> I appreciate your suggestions and opinions, David, but I'm still
> confused. If we accept there is a defect and agree that passing a
> certificate mitigates the defect, there are two questions remaining:
>
> 1. Do we apply the patch to the OASIS profile or the OGSA profile?
>
> 2. What normative language should be used when discussing requirements
> regarding the SAML subject?
>
> On the one hand, you suggest patching the OASIS profile, but on the
> other hand, you classify the defect as merely a "nice feature," which
> implies to me we could apply the patch to the OGSA profile without
> much problem. Do you still recommend patching the OASIS profile?
>
> FYI, currently in the OASIS profile we say that X509SubjectName MUST
> be used, and moreover, the DN MUST conform to RFC 2253. The latter is
> somewhat problematic since SAML Core does not go so far as to mandate
> RFC 2253. (I put that in to assist with DN string comparisons.)
this is a good idea. However it is the matching rule that is really
important. Does your statement go far enough to cover matching rules or not?
Thus
> the OASIS profile essentially extends SAML Core with respect to
> X509SubjectName identifiers. (That never felt quite right, but nobody
> questioned it so I let it slide.)
>
> If we decide to add this new extension of saml2:BaseIDAbstractType to
> the OASIS profile, then I suggest we remove the RFC 2253 requirement
> on the standard X509SubjectName identifier and add an RFC 2253
> requirement to <ds:KeyInfo>.
this is not actually needed since it is already in section 4.4.4 of RFC 3275
That is, if the SP uses <ds:KeyInfo> to
> pass a DN, that DN MUST conform to RFC 2253.
>
> Now this has a ripple effect on the OASIS profile. In particular, the
> metadata schema change proposed in section 3.8.1 can be removed
> because the need for it no longer exists (as stated, anyway). So
> altogether this is not a trivial modification of the profile.
agreed, because keyInfo has lots of optional elements and you will need
to say which can be used and which cannot. Also, and more importantly,
keyInfo says NOTHING about using proxy certificates or attribute
certificates, and something like this is needed for delegation from the
user to the SP. So it quite a bit of work to add this.
>
> More importantly, it's not clear to me what normative language should
> be used when describing the SAML subject. I think a conforming IdP
> MUST support both X509SubjectName and the extension of
> saml2:BaseIDAbstractType, but the SP is free to use whatever it wants.
> I dare say this suggests that all of section 2 can be eliminated.
I agree.
>
> So, no, this is not a cosmetic change. It will require a complete
> rewrite and we are back to square one. I guess I don't mind doing it,
> but I'll wait and see what others think.
Yes, but I suggest that the current spec might be broken anyway, in
which case an update is needed anyway
regards
David
>
> Tom
>
> On Sat, Mar 22, 2008 at 12:49 PM, David Chadwick
> <d.w.chadwick at kent.ac.uk> wrote:
>> Hi Tom
>>
>> thanks for taking the painful but necessary step of raising a defect.
>>
>> Actually I dont think it is as bad as you say. The current draft is not
>> erroneous, it is simply lacking in a non-essential though useful
>> feature. The DN is not erroneous. It is perfectly OK and I would not
>> suggest removing it. The reasons have already been given in my earlier
>> discussions on Trust i.e. if the AA trusts the Grid SP then the DN of
>> the Grid SP in the caller field (sorry may not have used the correct
>> term here) and the DN of the user in the subject field (again may not be
>> correct term) is sufficient to provide a perfectly good proxy service.
>> It is also as scalable as Shibboleth is today (cf the metadata). So what
>> you are proposing to add is a feature that will allow greater
>> scalability and less configuring of trust meta data, since the user can
>> dynamically delegate to a proxy to request attributes on his behalf.
>> This is a nice additional feature to the current draft, but is not a
>> show stopper in my opinion
>>
>> Regards
>>
>> David
>>
>>
>>
>>
>> Tom Scavo wrote:
>> > On Sat, Mar 22, 2008 at 11:32 AM, David Chadwick
>> > <d.w.chadwick at kent.ac.uk> wrote:
>> >> we do a dis-service to people by specifying a standard which we know to
>> >> be deficient beforehand. This will cause even more delays in trying to
>> >> rectify it (consider for example the OGSA Authz SAML spec, GFD 66, which
>> >> was only found to be deficient after practical trials, and how long it
>> >> has taken to produce replacements).
>> >
>> > I suppose that is why the OASIS process requires three attestations
>> > (i.e., claims of successful implementation) before OASIS Standard
>> > status can be put to the vote.
>> >
>> >> My suggestion would be to raise a ballot comment now on the current
>> >> OASIS draft, along with a proposed solution, so that this can be taken
>> >> into account in the revision.
>> >
>> > I tend to agree (reluctantly). What do others think?
>> >
>> > Should the proposed solution require a <ds:KeyInfo> element and
>> > disallow an X509SubjectName identifier, or should it be more lax?
>> > That's really a tough call, I think.
>> >
>> >> If the process is anything like IETF or
>> >> ISO it should not cause too much of a delay.
>> >
>> > Such a change requires that we start from scratch, including another
>> > 60-day public review. The delay will be substantial.
>> >
>> >> Tom Scavo wrote:
>> >>
>> >>
>> >>> On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>> >> >> ...the inclusion of a "certificate" needs more elaboration. The
>> >> >> inclusion for example of a user's public key certificate proves nothing
>> >> >> more than the presence of a DN does, since it is publicly available and
>> >> >> an untrustworth grid SP could send any PKC it wished, just as it can
>> >> >> send any DN it wished. Therefore one needs to specify the properties of
>> >> >> the certificate that are being transferred, which is, that the user is
>> >> >> delegating to the grid SP to act on its behalf. A proxy certificate
>> >> >> would do this, as would an attribute certificate.
>> >> >
>> >> > I totally agree. Of course this requires a new attribute request
>> >> > handler at the Shib AA but then a new handler is required for a bare
>> >> > DN as well, so there's no additional penalty. I don't know that much
>> >> > about the VOMS AA, but I'd be surprised if handling a full certificate
>> >> > turned out to be much of a problem for VOMS.
>> >> >
>> >> > We have a dilemma, however. A formal ballot is currently underway to
>> >> > promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to
>> >> > Committee Specification status. I fully expect this ballot to
>> >> > succeed. The next step after Committee Specification is OASIS
>> >> > Standard (but this last step requires three attestations, which is
>> >> > unlikely).
>> >> >
>> >> > If we introduce a normative change to the profile such as we've been
>> >> > discussing, we essentially start over. Presumably the profile could
>> >> > travel faster through committee this time around since the bulk of it
>> >> > has already been vetted, but a significant delay is inevitable.
>> >> >
>> >> > The other alternative is to specify this new extension of
>> >> > saml2:BaseIDAbstractType in our Attribute Exchange profile and leave
>> >> > the OASIS profile alone, flawed as it is. A third alternative is to
>> >> > do nothing.
>> >> >
>> >> > I'm not sure what to recommend. I'll let others comment on the
>> >> > appropriate course of action.
>> >> >
>> >> > Tom
>> >> >
>> >> >> Tom Scavo wrote:
>> >> >> >
>> >> >> > Instead of *requiring* a DN, the name identifier in the query should
>> >> >> > be generalized to accommodate the entire certificate (without
>> >> >> > excluding the possibility of a naked DN in those situations where it
>> >> >> > is warranted). This can be done using <ds:KeyInfo>, something like
>> >> >> > this:
>> >> >> >
>> >> >> > <saml:Subject>
>> >> >> > <saml:BaseID xsi:type="KeyIdentifierType">
>> >> >> > <ds:KeyInfo>...</ds:KeyInfo>
>> >> >> > </saml:BaseID>
>> >> >> > </saml:Subject>
>> >> >> >
>> >> >> > where KeyIdentifierType is defined as follows:
>> >> >> >
>> >> >> > <complexType name="KeyIdentifierType">
>> >> >> > <complexContent>
>> >> >> > <extension base="saml:BaseIDAbstractType">
>> >> >> > <sequence>
>> >> >> > <element ref="ds:KeyInfo"/>
>> >> >> > </sequence>
>> >> >> > </extension>
>> >> >> > </complexContent>
>> >> >> > </complexType>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> *****************************************************************
>> >> David W. Chadwick, BSc PhD
>> >> Professor of Information Systems Security
>> >> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
>> >> Skype Name: davidwchadwick
>> >> Tel: +44 1227 82 3221
>> >> Fax +44 1227 762 811
>> >> Mobile: +44 77 96 44 7184
>> >> Email: D.W.Chadwick at kent.ac.uk
>> >> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
>> >> Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
>> >> Entrust key validation string: MLJ9-DU5T-HV8J
>> >> PGP Key ID is 0xBC238DE5
>> >>
>> >> *****************************************************************
>> >>
>> >
>
--
*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick at kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************
More information about the ogsa-authz-wg
mailing list