[Emu] TEAP Request-Action TLV

Eliot Lear <lear@cisco.com> Thu, 30 April 2020 13:19 UTC

Return-Path: <lear@cisco.com>
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 622233A098A for <emu@ietfa.amsl.com>; Thu, 30 Apr 2020 06:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 S1H1lAL8nzIq for <emu@ietfa.amsl.com>; Thu, 30 Apr 2020 06:19:32 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCD93A0985 for <emu@ietf.org>; Thu, 30 Apr 2020 06:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4130; q=dns/txt; s=iport; t=1588252771; x=1589462371; h=from:mime-version:subject:message-id:date:to; bh=LSJ3q40M+G/KO1Bmuonz58Dz/uVdpypUdnLBbkg28tc=; b=kZzCef/RnV3cM7P7Ui/unJWckhRX7e2uMVLhIjkY1VzCkhl1084MaglM zLcSTZCeNRDfXmWg4GByhdmO/QRJtsOavUNINXPvVdd3lc8tN/cgp5sTw qHbI75Cn72UHfMwqtY1dRV0N+jRLb25LyZFmRhDqth6Fvb9CffiMsttN3 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CoBQAfz6pe/xbLJq1mHgEBCxIMgXwLAoNqASASgUSDB4kBh2aFQI40hhCBewsBAQEMAQEvBAEBDocMNAkOAgMBAQsBAQUBAQECAQUEbYViQgEQAYVHdT4CX4M5gn2kGo4QdoEyhVCFLoE4AYpsgW6CAIERJwwQg3YZAYZbM4ItBLI1gk+CbpUZHZAHjQBEqQuDQwIEBgUCFYFSOYFWMxoIGxU7KgGCPz0SGA2LF4c8jjI/A2YCBgEHAQEDCYcvizsBAQ
X-IronPort-AV: E=Sophos; i="5.73,334,1583193600"; d="scan'208,217"; a="25739481"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2020 13:19:27 +0000
Received: from [10.61.249.109] ([10.61.249.109]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 03UDJRex008640 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <emu@ietf.org>; Thu, 30 Apr 2020 13:19:27 GMT
From: Eliot Lear <lear@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3DA7A9CD-FB58-4CEA-A617-3FB282604EC7"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <7DF5C6C1-5176-417A-837F-4849262DFA35@cisco.com>
Date: Thu, 30 Apr 2020 15:19:27 +0200
To: EMU WG <emu@ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.249.109, [10.61.249.109]
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/VjZ4s6RGwX4X9Spthggi59uUOMw>
Subject: [Emu] TEAP Request-Action TLV
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, 30 Apr 2020 13:19:35 -0000

All:

Here is a circumstance one could easily imagine, and in fact we attempted to address in draft-lear-eap-teap-brski:

Client requires a new certificate for some reason or another.  Perhaps its is about to expire, or perhaps the signer has been compromised, or what have you.

We were thinking that we could use the Request-Action Frame for this purpose with a type of PKCS#10.  But that now seems wrong, as the language in the draft states that one appends a Request-Action frame with a full TLV, and not just a type,  and further that the other end process the TLV.  In looking at Jouni’s code, he is doing precisely that with the PAC TLV.

And so it seems we have three choices:

Create a new TLV that has a length of two that can be used in a REQUEST_ACTION frame.
Create a new TLV that is what we thought we meant: here is a list of two(ish)-byte types whose TLVs I want you to send to me.
Hard code the ordering of requests so everyone knows what to expect.

Each of these has its own problems. 

The first requires that we create a new EAP TYPE for TLV one end needs the other to send, but it’s pretty easy to process. The second requires extra processing but requires less standardization.  The last seems to go against the EAP model and reduces deployment flexibility.

Thoughts?

Eliot