[secdir] SECDIR review of draft-mraihi-mutual-oath-hotp-variants-13
Radia Perlman <radiaperlman@gmail.com> Sat, 26 February 2011 06:35 UTC
Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252003A68E9; Fri, 25 Feb 2011 22:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S557HsT7k4Iu; Fri, 25 Feb 2011 22:34:58 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id D2ED33A6924; Fri, 25 Feb 2011 22:34:57 -0800 (PST)
Received: by iyj8 with SMTP id 8so1674461iyj.31 for <multiple recipients>; Fri, 25 Feb 2011 22:35:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=pgUdYcaMbh9F+eH6nMmv2ErJhiGXlITietvckQBx3p0=; b=TcoRVwAUtmatYneKJMsktMZqlDkJWiKAj/pdQGXJ69AzkYJyKPoGFXUpB9R1H4ywuf Eb2NCLBJzgeVLg9hrQeDOPQsLJccoJafMwlWc1HMvNUpK2eF0G5JrRdQWIT4nQsTA7jI IUigq8/akoYry0QMfnpGWnWKqthaVn7Nj0NII=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YqRwr+gv71JJqVCkoUVcz6qJRcTS6Qdx0dRzHqkgo0Wo07zXnYCuiNDVGkJm9q/tcd 1UrWA2pNh2oYLXMtGTeK4L8UYA5u+bi2quYEawC3MICfeAgy8cxIIwqIjDasb871Gfy0 1NH/6VU0A7UfS8CFAtCczoCcLD3ClurA2Kvqc=
MIME-Version: 1.0
Received: by 10.42.218.6 with SMTP id ho6mr1869967icb.1.1298702151869; Fri, 25 Feb 2011 22:35:51 -0800 (PST)
Received: by 10.43.59.2 with HTTP; Fri, 25 Feb 2011 22:35:51 -0800 (PST)
Date: Fri, 25 Feb 2011 22:35:51 -0800
Message-ID: <AANLkTim4-jJoJ39EX16rFPCScUmb9TnkqMoxGqwTR3=P@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: draft-mraihi-mutual-oath-hotp-variants@tools.ietf.org, secdir@ietf.org, iesg@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [secdir] SECDIR review of draft-mraihi-mutual-oath-hotp-variants-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Feb 2011 06:35:00 -0000
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. I found the document quite difficult to understand, even though it was relatively short. Part of what makes it hard to read is due to terminology, like using "signature" to mean, (I think), simply a response to a challenge, rather than (how I would use the term) an integrity check on a message. This was especially confusing because in section 3, requirement R2 claims that OCRA will generate a symmetric key digital signature on a message, whereas the "signature variant" in section 7.3 seems to be just the same as challenge/response, other than omitting the input that I'd call "channel binding", (but they call "S".) Personally I don't like the term OTP to mean the general type of thing generated by one of these crypto token cards, since I think of it as the specific OTP protocol (RFC 2289), but apparently wikipedia defines OTP as based on a token display value, so it must be correct, and I'll adapt. :-) I also don't like the term "random questions" to mean a challenge. To me, "random questions" is when a verifier knows a bunch of human-rememberable questions, and asks a random subset of them to the human. It's particularly hard to understand a document when the same quantity is sometimes referred to as a "challenge" and sometimes as a "question". To their credit, code is included, which helped in some cases for me to clarify what was going on when I was having trouble understanding the prose. There also seems to be unnecessary complexity, like including a hash of the PIN rather than simply the PIN, into the inputs of the function, and the truncation function that, rather than simply taking the first n bits or the last n bits, uses the last 4 bits of the hash to determine where in the hash to take the 32 bits. With 32 bits of the hash to compute as a digital value, the algorithm supports up to 10 decimal digits. That would mean that if you use 10 digits, given that 32 bits is just 4 billion, the first digit will never be more than 4. I do understand why it would be nice to have an open standard for these sort of token devices, so that people can build interoperable tokens and verifiers. But I don't understand the need for all the variations in OCRA, especially when imagining the user having to type in a lot of values. It's hard enough to type in a PIN, but then also typing in channel bindings, challenges to the server, etc., make it hard for me to imagine a human putting up with this. Mysteriously to me, requirement R7 says that the challenge might have integrity checking, so that the device can notice and inform the user if the user mistypes the challenge. But what about the PIN and the channel bindings? Wouldn't that be just as important to catch an honest user mistake? The document does not explain how to verify a response, and I think if it did, it would be clear that the mutual authentication will not work if it included a counter and/or timestamp. These values are not necessarily synchronized at client and server, so the server would have to test several plausible inputs, and if both are used, if there are k plausible counter values, and n plausible timestamps, it would be k*n possible values to test. The spec assumes that the token card will display the (single) value that the server transmits, and the user will compare it against the display. I also find it a bit mysterious that the PIN is an input into what the client sends, but not in what the server responds. The server needs to know the PIN in order to verify what the client sends, so I can't quite see the reason for the asymmetry. What does the sentence "The server SHOULD also provide whenever possible a mean for the client (if able) to verify the validity of the signature challenge." mean? Radia
- [secdir] SECDIR review of draft-mraihi-mutual-oat… Radia Perlman