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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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


Subject: [saml-dev] RE: [security-services] SubjectLocality errata?


> From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]

> Can someone explain the following statement in core-00
> (lines 674-675)?

> This element is entirely advisory, since both these fields
> are quite easily "spoofed" but current practice appears to
> require its inclusion.

> Specifically, what "current practice" appears to require it?
>  This sounds pretty ambiguous and if so, should be cleared
> up in the spec.

> SubjectLocality is defined as the name/address FOR the
> system entity THAT WAS authenticated.

> If the system entity is a computer system, then I can
> understand why the info might be useful, although I'm not
> sure how "current practice" applies.  

> But for authenticated users, it doesn't make much sense
> since users don't typically have IP/DNS addresses.  It isn't
> supposed to identify WHERE the system entity WAS authenticated.
> Or is this how others interpreted its use?

> Rob Philpott

My recollection of this field is that it was intended to hold the IP address
where the user contact came from, for example the address of the machine
running the browser they used to log in. Some security products use this as
an additional defense against cookie theft.

By issuing security credentials tied to the browser IP address, if somebody
sniffs the connection and steals the authn assertion or cookie or whatever,
they would need to impersonate the IP address of the real user in order to
take advantage of the stolen credentials. This is substantially more
difficult than just sniffing, though far from impossible.

I think the wording in the spec was an attempt to balance between the people
who want to use this sort of defense because it does make credential theft a
little more difficult, and the people who don't think this sort of defense
is worth the effort because it doesn't provide enough of an improvement in
return for the possible problems it introduces (for example, some
implementations don't play well with Network Address Translation (NAT)
firewalls).

 - irving -


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being 
passed on.
 
This footnote confirms that this email message has been swept for Content Security threats, including
computer viruses.

http://www.baltimore.com

 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.


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


Powered by eList eXpress LLC