Difference between revisions of "Projects/SecurID SAM support"
(→Deployment) |
|||
Line 1: | Line 1: | ||
− | {{project- |
+ | {{project-rel | 1.9}} |
''The RSA SecurID SAM'' project proposes to add support for using [http://www.rsa.com/node.aspx?id=1156 SecurID] with [http://tools.ietf.org/id/draft-ietf-krb-wg-kerberos-sam Single Use Authentication Mechanism] Kerberos pre-authentication. |
''The RSA SecurID SAM'' project proposes to add support for using [http://www.rsa.com/node.aspx?id=1156 SecurID] with [http://tools.ietf.org/id/draft-ietf-krb-wg-kerberos-sam Single Use Authentication Mechanism] Kerberos pre-authentication. |
||
This is a backward compatibility project for sites with deployed code. |
This is a backward compatibility project for sites with deployed code. |
Latest revision as of 15:09, 18 October 2010
The RSA SecurID SAM project proposes to add support for using SecurID with Single Use Authentication Mechanism Kerberos pre-authentication. This is a backward compatibility project for sites with deployed code.
Contents
Relation to FAST and OTP Preauth
draft-ietf-krb-wg-otp-preauth describes a mechanism for using FAST with one-time password tokens such as RSA SecureID. The SAM approach is a much older solution to that problem that does not depend on FAST. The FAST/OTP approach has a number of benefits over SAM. For tokens such as SecurID, the strength of the reply key is limited to the user's long-term password. So if an attacker observes an authentication and the user has a weak long-term password, then the attacker can recover the resulting ticket. FAST addresses this weakness by using an armor key. The checksum of the SAM challenge provides the attacker with plaintext encrypted in the user's long-term password. So as originally specified, SAM is incompatible with today's recommended practice of not sending text encrypted in the long-term secret before the client has proven knowledge of that secret. It may be possible to combine SAM with encrypted timestap. Nothing stops SAM from being used in conjunction with FAST. If SAM is used with FAST, the SAM messages will not be bound to the FAST armor key. An attacker could capture messages from a non-FAST SAM exchange and include them in a FAST SAM exchange. Doing so does not appear to give the attacker any advantage. If SAM is used with FAST, then the user's long-term password is protected. However the weakness where an attacker could gain access to ciphertext encrypted in the user's password still exists.
Relation to PA-SAM-CHALLENGE
This version of the SAM mechanism defines PA-SAM-CHALLENGE-2 and PA-SAM-RESPONSE-2. The MIT Kerberos client has supported this since 2002. The KDC contains support for some tokens with PA-SAM-CHALLENGE and no support for PA-SAM-CHALLENGE-2.
Proposed Work
MIT has been using patches that implement the following functionality:
- SAM-2 for SecurID and Cryptocard
- support for draft-ietf-krb-wg-hw-auth
- Support for allowing a KDC to drop a packet if this KDC is not the right KDC to talk to an SecureID server.
- Support for the PA-RETURN-AS-REP pre-authentication item
This project will forward port the following:
- Support for PA-SAM-CHALLENGE-2 SecureID
- Support for KDCs dropping packets
The other items will not be forward ported. In addition, support for PA-SAM-CHALLENGE will be removed from the client and KDC.
Review
This section documents the review of the project according to Project policy. It is divided into multiple sections. First, approvals should be listed. To list an approval type
- #~~~~
(hash mark followed by four tilde characters) on its own line. The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with {{project-block}}.
Approvals
- Ghudson 00:07, 24 August 2010 (UTC)
Discussion
Deployment
This text should make its way into the administrator's guide.
In order to deploy this mechanism, Kerberos needs to be compiled against the SecurID SDK. The SDK needs to be placed in the library and include path such that configure will find it. Then an administrator creates principal/SECURID
principals to enable SecurID for a given principal. If this is done, then the KDC will call into the SecurID SDK and request authentication from the user.