IETF Logo Mail Archive

Re: [pcp] Comparison of PCP authentication

Margaret Wasserman <mrw@lilacglade.org> Tue, 07 August 2012 10:07 UTC

Return-Path: <mrw@lilacglade.org>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787B221F866C for <pcp@ietfa.amsl.com>; Tue, 7 Aug 2012 03:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.708
X-Spam-Level:
X-Spam-Status: No, score=-95.708 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ireNRqmEbcLt for <pcp@ietfa.amsl.com>; Tue, 7 Aug 2012 03:07:29 -0700 (PDT)
Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id DA90321F860D for <pcp@ietf.org>; Tue, 7 Aug 2012 03:07:29 -0700 (PDT)
Received: from lilac-too.home (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id DB1942023F; Tue, 7 Aug 2012 06:07:28 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Margaret Wasserman <mrw@lilacglade.org>
In-Reply-To: <241D4228-E4FE-454A-9C3B-CA34C16D666E@yegin.org>
Date: Tue, 07 Aug 2012 06:07:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6388F89E-C081-4C48-890C-8D99128A7B1C@lilacglade.org>
References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <D6D2DEED-C35A-45AB-8B72-96195C308DB9@yegin.org> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <241D4228-E4FE-454A-9C3B-CA34C16D666E@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
X-Mailer: Apple Mail (2.1084)
Cc: pcp@ietf.org
Subject: Re: [pcp] Comparison of PCP authentication
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 10:07:30 -0000

On Aug 7, 2012, at 3:48 AM, Alper Yegin wrote:
> That's right.
> PANA session will generate a Session-Id, Key-Id, and a PCP key. We should use the two identifiers along with the MIC generated using the PCP key in Authentication Tag Option. That's how PANA session and PCP messages get crypto-bound to each other.

We should also do something (a hash, or whatever) to bind those keys to the contents of a specific request, so that we can be sure that the contents of the request haven't been modified/replaced.  If we include a time and/or the transaction ID in the hash, I think we can guard against replay attacks that way.  I think that would do it.

Much of this is the same, whether we use a demultiplexing approach or an encapsulation approach, and much of it would apply to a PCP-specific mechanism as well.

Margaret

v2.23.0 | Report a Bug | By Email