[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