[tcpm] PRFs

Eric Rescorla <ekr@networkresonance.com> Tue, 18 November 2008 20:06 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF4E28C253; Tue, 18 Nov 2008 12:06:33 -0800 (PST)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797A83A69E5 for <tcpm@core3.amsl.com>; Tue, 18 Nov 2008 12:06:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.124
X-Spam-Level:
X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, RDNS_NONE=0.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 3intzbcg2vdq for <tcpm@core3.amsl.com>; Tue, 18 Nov 2008 12:06:31 -0800 (PST)
Received: from kilo.rtfm.com (unknown [130.129.95.170]) by core3.amsl.com (Postfix) with ESMTP id 0C62E3A6ACE for <tcpm@ietf.org>; Tue, 18 Nov 2008 12:06:11 -0800 (PST)
Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id EEB0B75D184 for <tcpm@ietf.org>; Tue, 18 Nov 2008 14:06:08 -0600 (CST)
Date: Tue, 18 Nov 2008 14:06:08 -0600
From: Eric Rescorla <ekr@networkresonance.com>
To: tcpm@ietf.org
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20081118200608.EEB0B75D184@kilo.rtfm.com>
Subject: [tcpm] PRFs
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

We had a little discussion on the list about PRFs earlier, and when
I talked to Joe I said I would generate some text. Here it is:

   Given a TSAD key, the TCP socket pair, and the connection ISNs, the 
   connection key used in the MAC algorithm is computed using a 
   pseudorandom function (PRF), which is assumed to be able to
   produce an arbitrary number of random bits. The directional
   connection keys are computed as:

   Conn_Key = PRF(Key, connblock)

   Where enough bytes are generated to match the required key
   length for the algorithm.

We also discussed PRF definitions. As I mentioned, while many
MACs can double as PRFs, there's no easy transformation from
a MAC to a PRF. Luckly, I think it's clear we can rip off
PRFs from some existing registry, e.g., the IPsec registry defined in
RFC 4306 (http://www.iana.org/assignments/ikev2-parameters), which
has all the PRFs we would most likely want, including those which
rely on functions which roughly match the likely MAC transforms.

The high level question seems to me that we need to decide 
whether to tie PRFs to MACs, with the natural approach to
use the corresponding PRF (e.g., you use HMAC-SHA-256 with
PRF_HMAC_SHA2_256) or to allow mix-and-match. We can discuss
the pluses and minuses of these options (which seem kind of
obvious) at the meeting.

-Ekr



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm