> I think that the Password auth method
may be considered to cover this at the least.
Hi Phill - Unfortunately, we really
need something distinct from password since we have some applications that MUST
know whether a user authenticated with a single factor (e.g. LDAP password) or
a 2-factor (e.g. SecurID token) authn method.
As I said, if folks object to a
proprietary method (SECURID), I can live with something that at least indicates
it was a 2-factor authentication. Recommendations?
"TOKEN" - too
generic? does not necessarily indicate 2-factor strength?
"2FACTOR" - perhaps
this is the better choice
"OTP" - I don't
think we should use this one since there's an RFC by this name that's
specific to onlky one of several OTP methods
-----Original Message-----
From: Hallam-Baker, Phillip
[mailto:]
Sent: Thursday, April
04, 2002 9:27 PM
To: Philpott, Robert; oasis sstc
()
Subject: RE: [security-services] New
authentication method for One-Time Pa ssword?
I think that the Password
auth method may be considered to cover this at the least.
If more specificity is
required I would suggest that the method merely specify a hardware token rather
than any particular proprietary means of achieving that (unless we want to
spend more time with lawyers).
If an application cares
about the vendor of the token let the vendor specify the uri out of their oid
arc :-)
-----Original
Message-----
From: Philpott, Robert
[mailto:]
Sent: Thursday, April
04, 2002 6:31 PM
To: oasis sstc
()
Subject: [security-services] New
authentication method for One-Time Password?
I hesitate bringing this up so late,
but a) we did just add an authn method for SRP, and b) our SAML implementation
really needs an authn method defined for RSA SecurID time-based token
authentication. Would you please consider adding the following authn
method to the core spec?
7.1.?? RSA SecurID
URI: urn:oasis:names:tc:SAML:1.0:am:SECURID
The
authentication was performed using an RSA Security time-based SecurID token.
I
considered referring to IETF "rfc2808 - The SecurID® SASL
Mechanism", which does describe the method, but in the context of
SASL. I decided a specific SAML domain qualifier made more sense.
If you would prefer, we could live
with a generalization of the method type as "Time-Based Token" (TBT?
TOKEN?)
Since
SecurID is also a form of One-Time Password, of which there are many other
types, I also considered following the model we used for X509, where we would
have:
7.1.?? One-Time Password
URI: urn:oasis:names:tc:SAML:1.0:am:OTP
The
authentication was performed by some (unspecified) mechanism using a One-Time
Password. It may have been one of the mechanisms for which a more specific
identifier has been defined below.
7.1.?? RSA SecurID
URI: urn:oasis:names:tc:SAML:1.0:am:SECURID
The
authentication was performed using an RSA Security time-based SecurID token.
Etc.
But
then I discovered that IETF rfc2289 defines a specific OTP method based on
S/Key. So, it didn't make sense to me to have the SAML-defined OTP which
might get confused with the rfc2289 method.
If we don't add this to the core
spec, our implementation will have to define one for our own use. But
SecurID is a VERY widely used time-based token (2-factor) authentication
method, so I'd prefer having the SECURID method defined. As I said, I'd
also settle for the TBT/TOKEN method.
Comments?
Rob Philpott
RSA Security Inc.
The Most Trusted Name in e-Security
Tel:
781-515-7115
Mobile: 617-510-0893
Fax:
781-515-7020
mailto:
