When I
spoke to Jeff I agreed to post the relevant document node to the list when I
have drafted it. The main problem is working out the name for the #%#$^
thing.
I am
currently favoring PersonalHardwareToken which may be used to apply to any of
the time based tokens or challenge response tokens in use. The term Token
appears to me to be far to ambiguous (I find the GSSAPI specification impossible
to tread because it witters on about tokens at inordinate length), the essential
issue here appears to be that the token is something carried, i.e. we are
talking about a human authentication mechanism here.
Phill
-----Original Message-----
From: Hallam-Baker, Phillip
[mailto:]
Sent: Friday, April 05, 2002 12:25
AM
To: Philpott, Robert; oasis sstc
()
Subject: RE:
[security-services] New authentication method for One-Time Pa
ssword?
OK
how about
SomethingCarried
and
we can also add in for completeness
SomethingYouAre :-)
I
dislike 2 factor since it might only be one of the
factors.
-----Original Message-----
From: Philpott, Robert
[mailto:]
Sent: Thursday, April 04, 2002
10:37 PM
To: 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.
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:
