[OGSA-AUTHZ] Implementations

[Tom Scavo]

Hi David,

Sorry for the delay.  Please find some remarks inline.

On Sun, Mar 23, 2008 at 4:27 PM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>
>  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?

OASIS specifications have "Errata" associated with them.  Errata are
non-normative changes to an OASIS Standard, usually wording changes or
other clarifications.

>  b) does the OASIS group agree that this enhancement is worthy of adding
>  in the first place.

I haven't asked and I don't think it matters.  If I make a normative
change to the document (which is what we're talking about here), we go
back to square one.  (See other thread on OASIS process.)

>  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.

Yes, the spec is brittle insofar as this single change will have a
ripple effect throughout the entire document.

Just to let you know, regardless of what the AuthZ-WG decides to do, I
intend to rewrite the OASIS document.  I'm not sure how quickly I can
get this done, but in any event, since another 60-day Public Review
would be required, the time lag would be 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.

You're right, it doesn't.

>  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.

Exactly how the IdP accesses the subject's X.509 certificate is out of scope.

>  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?

Good question.

>  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.

You are absolutely correct.  (I wish you had pointed this out during
the 60-day Public Review, but oh well :)

Tom

>  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
>
>  *****************************************************************
>