[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