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



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


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


Powered by eList eXpress LLC