Review of Projects/SecureID_SAM_Support ending August 31

[Sam Hartman]

This starts a brief review of
http://k5wiki.kerberos.org/wiki/Projects/SecureID_SAM_Support

   The RSA Secure ID SAM project proposes to add support for using
   [8]Secure ID with [9]Single Use Authentication Mechanism Kerberos
   pre-authentication. This is a backward compatibility project for sites
   with deployed code.

   Contents

        * [10]1 Relation to FAST and OTP Preauth
        * [11]2 Relation to PA-SAM-CHALLENGE
        * [12]3 Proposed Work
        * [13]4 Review
             + [14]4.1 Approvals
             + [15]4.2 Discussion

Relation to FAST and OTP Preauth

   [16]draft-ietf-krb-wg-otp-preauth describes a mechanism for using
   [17]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 Secure ID, 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 Secure ID and Cryptocard
     * support for [18]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.