[secdir] Review of OTP Pre-authentication, draft-ietf-krb-wg-otp-preauth-18

"Hilarie Orman" <hilarie@purplestreak.com> Mon, 29 August 2011 06:47 UTC

Date: Mon, 29 Aug 2011 00:48:10 -0600
Message-Id: <201108290648.p7T6mAkG005855@sylvester.rhmr.com>
From: Hilarie Orman <hilarie@purplestreak.com>
To: secdir@ietf.org, iesg@ietf.org
Cc: gareth.richards@rsa.com
Subject: [secdir] Review of OTP Pre-authentication, draft-ietf-krb-wg-otp-preauth-18
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>

Security review of OTP Pre-authentication, draft-ietf-krb-wg-otp-preauth-18

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

The document defines how to use "one-time passwords" with Kerberos
pre-authentication, over a secure tunnel between the client and the
key distribution center (the KDC).  A secure tunnel mechanism called
"FAST", the subject a Crypto eprint paper and another Kerberos RFC,
defines the use of cryptography.  The OTP system uses its FAST key as
part of generating its own one-time keys, and this combination is
meant to protect against man-in-the-middle attacks.

Although this document seems is in almost all respects well-written,
it is difficult to review because of nesting depths of RFCs on which
it relies, and because of the "ifs".  The narrative description of the
protocol has so many "ifs" that it is difficult to keep track of
them.  There are approximately 100 conditionals.

Diagrams might be helpful.

The protocol security relies directly on the ability to decrypt a
nonce.  A nonce sent by the challenging part must be encrypted by the
responder using a one-time key that both parties can computer from
their shared state.  The challenger decrypts and compares to the
nonce.  This is something that Needham's "prudent principles" warns
against, and in this case I cannot discount the advice.  This is
because the document does not supply exact definitions of cipher
functions.  Instead, it relies on generic elements of the cipher
suite.

The key derivation function ultimately depends on the "random-to-key"
function of the cipher suite, but even finding this information
involves looking at other RFCs and doing Google searches.  So, it is
difficult to review the security in general, and I cannot dissuade
myself from thinking, even after reading the well-done security
considerations section, that the authentication method might have
flaws.  The devil is in the details and the details are generic.

In "2.3. PIN Change", we read "Most OTP tokens involve the use of a
PIN in the generation of the OTP value."  Is there a reference for a
common OTP system that uses PINs?

An editorial comment about the security consideration re "remaining
entropy" ... this is really an issue about secrecy, not information
theory, and I would call it "secret information".

Reference to "Cryptology ePrint Archive" should include a URL for
the archive, which is a service of the IACR (www.iacr.org).

Hilarie

[secdir] Review of OTP Pre-authentication, draft-… Hilarie Orman