[Emu] teap-brski
Dan Harkins <dharkins@lounge.org> Thu, 06 June 2019 14:13 UTC
Return-Path: <dharkins@lounge.org>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3874812004F; Thu, 6 Jun 2019 07:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFtSrxV0AKU3; Thu, 6 Jun 2019 07:13:13 -0700 (PDT)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5D112006D; Thu, 6 Jun 2019 07:13:13 -0700 (PDT)
Received: from trixy.bergandi.net (cpe-76-93-146-89.san.res.rr.com [76.93.146.89]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0PSO004EEKU09W@wwwlocal.goatley.com>; Thu, 06 Jun 2019 09:13:12 -0500 (CDT)
Received: from thinny.local ([65.222.135.102]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PSO00P2WKTG79@trixy.bergandi.net>; Thu, 06 Jun 2019 07:13:03 -0700 (PDT)
Received: from unknown ([65.222.135.102] EXTERNAL) (EHLO thinny.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Thu, 06 Jun 2019 07:13:03 -0700
Date: Thu, 06 Jun 2019 07:13:01 -0700
From: Dan Harkins <dharkins@lounge.org>
To: anima@ietf.org, emu@ietf.org
Message-id: <50c726dd-011d-9c52-6d79-caeb2ee0ef3b@lounge.org>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"; format="flowed"
Content-language: en-US
Content-transfer-encoding: 8bit
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=65.222.135.102)
X-PMAS-External-Auth: unknown [65.222.135.102] (EHLO thinny.local)
X-PMAS-Software: PreciseMail V3.3 [190605] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/Gga3cMW4FnX0UUiZWO1A3DcV5ss>
Subject: [Emu] teap-brski
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2019 14:13:15 -0000
Hello, In a private thread on teap-brski the topic of co-location of the TEAP server and the BRSKI registrar was brought up. It was suggested that the discussion move to these lists to get more input from the experts. In draft-lear-eap-teap-brski-02 the architecture shows a the TEAP server and the BRSKI registrar as separate while mentioning that they can be co-located. The following assumes they are not co-located. The BRSKI pledge in this draft is called a "device" and the device establishes a provisional TLS connection (through TEAP) to the TEAP server over 802.1X or something similar. The device does not connect to the registrar. The device then creates a voucher request and sends it to the TEAP server using a newly defined TEAP TLV. The registrar signs the request, forwards it onto a MASA, and sends the voucher it gets back from the MASA to the device using another newly defined TEAP TLV. So the question is, will this even work? If the TEAP server and BRSKI registrar are separate entities then the voucher will include the TEAP server's EE certificate but it will be signed by the registrar's EE certificate. From my admittedly limited understanding of BRSKI I think the MASA will reject this voucher request because it fails the "proximity" check (if I understand the proximity check correctly). The MASA will treat the registrar as a man-in-the-middle. BRSKI folks: is this correct? Will a voucher request be rejected from a deployment like this? EMU folks: if the answer from the BRSKI folks is that this doesn't work then is there any sort of weird tunneling or "phase 2" trickery that can be added to TEAP to get this to work or should we just explicitly state that the TEAP server and the registrar are the same entity (they authenticate with the same certificate)? Thanks, Dan.
- [Emu] teap-brski Dan Harkins
- Re: [Emu] teap-brski Owen Friel (ofriel)