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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: AuthenticatorLocale Definition


Does the AuthenticatorLocale trace back to any specific requirements?
Core-0.15 says that it's optional, since the information can be spoofed;
given that, I think we need more rationale for why it's in the spec at all.

If we want a way to record the source IP address from which an
authentication originated (for example, to protect against interception of
authentication assertions), the SubjectConfirmation field seems more
appropriate. Then the logic would be: the way you confirm that the presenter
of this assertion is the subject is that the message came from the
corresponding IP address.

 - irving - 

> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Friday, August 24, 2001 10:53 AM
> To: 'security-services@lists.oasis-open.org'
> Subject: AuthenticatorLocale Definition
> 
> 
> The current core describes AuthenticatorLocale thus:
> 
> The <AuthenticationLocale> element specifies the DNS domain 
> name and IP
> address for the system entity that performed the authentication.
> 
> IMO this might reasonably be interpreted as the IP and DNS of the
> Authentication Authority, or associated server that validated the
> credentials. Is that what was wanted? My understanding was 
> that we wanted
> the IP and DNS or the client being authenticated.


-----------------------------------------------------------------------------------------------------------------
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 
unauthorized 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.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
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