OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [security-services] Resource text


Ack, where did al of section 6 go in the RFC!

Actually since the RFC turns out to omit the cannonical form discussion
entirely and instead of the text you propose cut 'n paste from section 6 of
RFC 2936 which says the same things but in a less chatty fashion.

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> Sent: Thursday, February 14, 2002 6:02 AM
> To: Hallam-Baker, Phillip
> Cc: Security-Services (E-mail)
> Subject: Re: [security-services] Resource text
> 
> 
> 
> Phill,
> 
> The proposed text is fine for me with just one addition and a nit 
> (embedded below). I hope the addition is just a clarification and 
> not going to stir up another hornet's nest:-). 
> 
> The clarification needed is to say what's meant by "canonical form". 
> Now, unfortunately rfc2396 doesn't define this explicitly and I don't 
> know of an explicit definition (not even in the canonical XML 
> rec [1]!).
> 
> Would the following do for now? I'm quite happy that we tweak/tighten
> the definition now or later.
> 
>    By the "canonical form" of a URI we mean an absolute URI (i.e. no
>    relative URIs) which is the shortest of all the equivalent URI 
>    strings, where URI equivalence is defined according to [RFC2396]. 
>    For example, the URI "http://foo.com:80/go/../go/to/" is not in 
>    canonical form, but "http://foo.com/go/to" is in canonical form. 
>    Note that if a URI is partly or entirely case-insensitive, then 
>    there will be more than one "canonical form" for that URI such 
>    that a case sensitive matching rule would consider that the 
>    strings differ (e.g. "HTTP://Foo.cOm/go/to" is "another" canonical 
>    form of the URL above).
> 
> Btw: nice one - getting around the coformance muddle by imposing 
> security conditions - I like that!
> 
> Stephen.
> 
> 
> [1] http://www.w3.org/TR/xml-c14n
> [RFC2396] ftp://ftp.isi.edu/in-notes/rfc2396.txt
> 
> "Hallam-Baker, Phillip" wrote:
> > [...]
> > 2.4.4. Element <AuthorizationDecisionStatement>
> > 
> > The <AuthorizationDecisionStatement> element supplies a 
> statement by the
> > issuer that the request for access by the specified subject 
> to the specified
> > resource has resulted in the specified decision on the basis of some
> > optionally specified evidence.
> > 
> > The resource is identified by means of a URI. In order for 
> the assertion to
> > be interpreted correctly and securely the issuer and 
> relying party MUST
> > interpret each URI in a consistent manner. Failure to 
> achieve a consistent
> > URI interpretation can result in different authorization 
> decisions depending
> > on the encoding of the resource URI. To avoid ambiguity 
> resulting from
> > variations in URI encoding SAML applications SHOULD employ the URI
> > cannonical form wherever possible as follows:
> > 
> >     * The assertion issuer SHOULD encode all resource URIs 
> in canonical
> > form.
> >     * Relying parties SHOULD convert resource URIs to 
> cannonical form prior
> > to processing.
> > 
> > Inconsistent URI interpretation can also result from 
> differences between the
> > URI syntax and the semantics of an underlying file system. 
> Particular care
> > is required if URIs are employed to specify an access control policy
> > language. The following security conditions should be 
> satisfied by the
> > system which employs SAML assertions:
> > 
> >     * The URI syntax is case sensitive. If the underlying 
> file system is
> 
> s/The URI syntax is/Parts (see [RFC2396]) of the URI syntax are/
> 
> > case insenstive a requestor SHOULD NOT be able to gain 
> access to a denied
> > resource by changing the case of a part of the resource URI.
> > 
> >     * Many file systems support mechanisms such as logical paths and
> > symbolic links which allow users to  establish logical 
> equivalences between
> > file system entries. A requestor SHOULD NOT be able to gain 
> access to a
> > denied resource by creating such an equivalence.
> > 
> > The <AuthorizationDecisionStatement> element is of type
> > AuthorizationDecisionStatementType, which extends
> > SubjectStatementAbstractType with the addition of the 
> following elements (in
> > order) and attributes:
> > 
> > Resource [Optional]
> >     A URI identifying the resource to which access 
> authorization is sought.
> > 
> > [Also fix section 3.3.5 to reference]
> > 
> > Phillip Hallam-Baker FBCS C.Eng.
> > Principal Scientist
> > VeriSign Inc.
> > pbaker@verisign.com
> > 781 245 6996 x227
> 
> -- 
> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:stephen.farrell@baltimore.ie
> Ireland                             http://www.baltimore.com
> 

Phillip Hallam-Baker (E-mail).vcf



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC