ISSUE: 2Factor Authn method (formerly RE: [security-services] Newauthentication method for One-Time Pa ssword?)

Hal, Phill, Jeff - I did not see the
attached on the current issue list.  Is it not there because I brought it
up "too late" for consideration?  Or was it just an oversight.

 

Thanks,

 

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:

 

-----Original Message-----

From: Philpott, Robert 

Sent: Friday, April 05, 2002 2:38
PM

To: oasis sstc
()

Subject: RE: [security-services]
New authentication method for One-Time Pa ssword?

 

Actually, Phill, I feel
that although the physical hardware token may only be one of the factors, the
relevant information about the authentication method is that it was a 2-factor
authentication. Now there may be more specificity desired when evaluating the
method, but that's probably true for the other currently defined methods. 
With a password authentication, I may very well want to know characteristics of
the password (length, entropy, etc.).  For X.509 certs, I may want to know
the specific authn method a specific authentication was performed using the key
(e.g.SPKI) - and of course we already provided some of those.  For
2factor, I may want to know that it was a 2factor hardware token
authentication, etc.  But I at least need to know that it was a 2factor
authentication.

 

I don't think we want to
get into too many refinements of authentication methods at this point. 
Liberty Alliance is also doing this as part of their authentication
profiles.  MS is doing some of this in WS-License.  But I do need to
be able to distinguish the 2-factor "class" of authentication from a
password class or an X.509 class.

 

Make sense?  If so,
I'd prefer to see something like 2FACTOR.

 

Thanks.

 

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:

 

-----Original Message-----

From: Hallam-Baker, Phillip
[mailto:] 

Sent: Friday, April
 05, 2002 1:57 PM

To: Hallam-Baker, Phillip;
Philpott, Robert; oasis sstc ()

Subject: RE: [security-services]
New authentication method for One-Time Pa ssword?

 

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: