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

Sorry, 
I was treating it like a minor editorial issue. I did not track the request for 
an SRP code either, so I am not discriminating.

 

Since 
the issue is now being debated, I will state my position.

 

1. I 
think SAML should list codes associated with methods endorsed by major standards 
bodies/consortia, such as IETF, W3C and so forth.

 

2. I 
think SAML should make it easy for vendors to define codes for proprietary 
mechanisms and should give them out freely.

 

3. 
This policy could lead to confusion in policy about what is the same, what is 
different. I proposed a solution to this a long time ago (which we use in our 
product) See Issue DS-7-03. Every policy domain is allowed to associate a 
Strength number with each method. That allows you to decide for yourself what is 
stronger or weaker. This proposal did not gather any support and the issue was 
closed.

 

Hal

  
-----Original Message-----
From: Philpott, Robert 
  [mailto:]
Sent: Tuesday, April 09, 2002 
  11:08 AM
To: 
  
Subject: ISSUE: 2Factor Authn 
  method (formerly RE: [security-services] New authentication 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: