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:
