[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
- [tcpm] PRFs Eric Rescorla