RE: [security-services] Suggest adding IssueInstant attribute toRequest and Response

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

OK how about this for consensus?

1) we add in the attributes as OPTIONAL
2) we note that you should only use them if you believe you actually
	know the time.
3) we add error sub codes for 'TooEarly' and 'TooLate'


		Phill

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


> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Tuesday, January 15, 2002 2:02 PM
> To: 'Hal Lockhart'; 'SAML'
> Subject: RE: [security-services] Suggest adding IssueInstant attribute
> toR equest and Response
> 
> 
> >Sure you can intercept and keep the message, but if the channel
> requires
> >authentication, you can't SEND it unless you can authenticate.
> 
> I don't think it's the case that all future useful bindings 
> of SAML will
> require an authenticated channel apart from the messages themselves.
> Maybe I'm wrong (well, I definitely am currently, since I can't build
> one without being vulnerable to replay, so I wouldn't).
> 
> >Well the section of the document in question clearly says that denial
> of
> >service is the threat. If that is wrong, we should fix the document.
> 
> The section on Replay (5.3.1.2) is in the section on the SOAP binding,
> which is a specific binding that as currently written, is not 
> vulnerable
> to replay because message integrity MUST happen using SSL. Chris notes
> that other schemes for integrity would be vulnerable. Where 
> you put that
> is an editorial issue, I guess.
> 
> >In my opinion, this is only a threat when using certain types of
> >SubjectConfirmation. I don't think this is an issue in the context of
> the
> >SOAP binding, however I have not analized it carefully.
> 
> The requirements for the SOAP binding do not mandate use of SSL, but
> they do mandate using SSL if you want message integrity 
> (which obviously
> is required if you're going to fix anything with a timestamp).
> 
> I'm not claiming SAML as written is broken, I'm just saying by leaving
> out a minor, ignorable attribute, it's constraining on future 
> bindings,
> overly so IMHO. Sorry if I was giving the wrong impression.
> 
> -- Scott
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>

Phillip Hallam-Baker (E-mail).vcf