Re: [security-services] Changes for Core 26

[Stephen Farrell <stephen.farrell@baltimore.ie>]

Phill,

I just quickly went through the new pdf & have the following comments,
all with specific changes (see I'm being a good boy before I go to the
pub:-).

Regards,
Stephen.

1) the rare-old-times:-)
------------------------

> b) Modify text in the following sections to state "The time value MUST be
> expressed in UTC time as specified in section 1.3.4"
> 2.3.3, 2.3.3., 3.2.1, 3.4.1

The above I like. The pdf however also says: "MUST NOT generate time
instants that specify leap seconds." I guess this is trying to constrain
dateTime even more, (an approach with which I symphatize), but I think
this is just a little bit too much. I'd suggest s/MUST NOT/SHOULD NOT/,
on the basis that "MUST NOT" means that everyone has to write a line
of code that only gets executed once every couple of years - it might 
be something like "if (seconds==60) sleep(1)". Now that I'd rather not
have that MUST since sleeping that second could be important for some
application or other and code that's run that rarely *always* causes
problems (at least it did when I wrote code:-).

2. NameIdentifier.Name
----------------------

Eve suggested putting the name value in as element value, not as an
attribute which I thought had been agreed but the NameIdentifier still
has two attributes here. Suggest implementing Eve's change.

3. Resource matching
--------------------

> 706: Wildcard issue.

Given that we're not allowing wildcards (though we should:-), we need
to include some text so PEPs can tell if a resource from a statement
matches a URI (esp http URL).

RFC2396 has loads to say about this, esp a bit (section 6) where they
point out e.g. that "http://foo.com/" is the same as "HTTP://fOo.CoM:80/".
It does, of course, get worse, given escaping%20etc. So - is it sufficient
that we point at 2396 for resource matching? If so, then how about adding
this to "section 1.2.2 comparing SAML values:

   All URIs contained in SAML elements (whether as element or attribute
   values) MUST be compared as specified in [RFC2396]. In particular this
   means that "http://foo.com/go/to/the/pub/" represents the same resource
   as "HTTP://FoO.CoM:80/go/../go/to/the/pub". Implementations MUST ensure
   that all URI comparisons take account of all the relevant mappings as,
   for example, strings of the form  of "go/../go" have in the past been 
   successfully used in attacks on systems. This would apply most especially 
   to a PEP that cached SAML decision assertions for example. SAML 
   implementations however, SHOULD NOT, (unless running in an entirely
   "trusted" environment) assume that DNS names and IP addresses can 
   be taken to represent the same resource, that is, "http://foo.com" 
   SHOULD never be take to be the same as "http://10.0.0.1/" regardless
   of the fact that foo.com maps to 10.0.0.1 according to the local DNS.

That does still leave the following problems, (I've run out of time to 
suggest text, feel free to make improvements):

- Some filesystems are case insensitive, some aren't. [One way to handle
  this is for the pEp to include a flag in the decision query telling the
  PdP whether it (the PEP) is case-sensitive for URI local parts. Is it
  too late to add in something like that?]
- "/" being the same as "/index.html" [Have the PEP tell the PDP as 
  above? Sounds too hard to me in general.]
- Probably more I've forgotten ;-(

4. IPv6
-------

> 664: IPv6 issue, I need someone to write text.

Just live with dot sep string form of IPv4 for now and include a comment
that IPv6 text will be in the next release. Reason I'd suggest punting on 
this is that I'm not sure whether we need to consider address matching
(e.g. whether "/24" is something to wory about - harder in the v6 world
of course). Suggested text:

   IPv4 addresses MUST be represented using "dot-separated" notation, 
   e.g. "10.0.0.1". The next revision of this specification will 
   define how to handle IPv6 addresses.

'Course if you've time to do better, then ignore this.




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