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: RE: [saml-dev] SubjectLocality errata?

If you look at the schema, you can see that Subject Locality can be an IP address or DNS name (or both). These are intended to be the values associated with the user at the time of authentication. There was some sentiment to omit this information because of the potential for spoofing, but the consensus was that organizations today (and therefore products) use this information as a part of Authorization policy decisions. Therefore the fields were retained as optional attributes. I did lobby for more explicit definition of what the fields mean, especially DNS name, but the current wording was retained.
My personal interpretation is that is the IP address in the messages that were received in the Authentication exchange. The DNS name should be the result of a reverse lookup on the IP at the time the Authentication was done, but I suppose a reverse lookup at the time the assertion was generated is also a reasonable interpretation. Of course, the typical client system using DHCP will probably not have a DNS name assigned, in which case the attribute should be omitted.
Since these fields are optional, you do not have to generate them. If your policy model does not use them you can ignore them if you receive them.
-----Original Message-----
From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]
Sent: Wednesday, May 15, 2002 12:11 PM
To: security-services@lists.oasis-open.org
Cc: saml-dev@lists.oasis-open.org
Subject: [saml-dev] SubjectLocality errata?

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

RSA Security Inc.

The Most Trusted Name in e-Security

Tel: 781-515-7115

Mobile: 617-510-0893

Fax: 781-515-7020



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

Powered by eList eXpress LLC