Re: [Emu] Issue 47 Certificate identity checks

Eliot Lear <lear@cisco.com> Mon, 12 April 2021 07:54 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 3E5BB3A1071 for <emu@ietfa.amsl.com>; Mon, 12 Apr 2021 00:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 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, SPF_NONE=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 ytijzBkQy6gc for <emu@ietfa.amsl.com>; Mon, 12 Apr 2021 00:54:22 -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 6276D3A1070 for <emu@ietf.org>; Mon, 12 Apr 2021 00:54:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2503; q=dns/txt; s=iport; t=1618214062; x=1619423662; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=dPxYokIM3cmhXUd55YBpXmDeOjv1ld9QilJL8iqy5zQ=; b=RFD+OxV36jn0ysFuWIkhqHfXXbj6p3yx+HXUwg34S6Moi0aoWCk5+RmV SSAe3M1F/D3z/2mjThvAtRe458tnqbTS0Vj9D9wQRKsF3qJ1fRmxeFoqO RC0fYuvUKcwWjyzZfkSnch2AL7sj8Yt6kXuvgo8cKZAn+nJ+LKOPTUqHD w=;
X-Files: signature.asc : 488
X-IPAS-Result: A0D8AAC7+3NglxbLJq1RCRwBAQEBAQEHAQESAQEEBAEBghKDeAEnEoRziQSIMSUDnGUEBwEBAQoDAQE0BAEBhFACgXgmOBMCAwEBAQMCAwEBAQEBBQEBAQIBBgQUAQEBAQEBAQFohV2GRQECAgEjVgULCw40AgJXBoMEAYJmIasEd4EygQGEWIRkEIE5gVOLekOCC4ETJwwQgjAvPoQWFIMvNYIrBIIRNIFcgSKee50CgxWDPoFFl3kEH4NNkF6QRpclnRcBhAECBAYFAhaBayGBWzMaCBsVZQGCPz0SGQ6OOI4yPwNnAgYBCQEBAwmKTi2CFgEB
IronPort-HdrOrdr: A9a23:pXZBeK8pUB5LDrmjm21uk+BaI+orLtY04lQ7vn1ZYxY9SL36q+ mFmvMH2RjozAsAQX1Io7y9EYSJXH+0z/9IyKYLO7PKZmPbkUuuaLpv9I7zhwDnchefysd42b 17e6ZzTP38ZGIWse/f4A21V+kt28OG9qfAv4jj5kxgRw1rdK1shj0RYm2mO3Z7SwVcCZ0yGI D03LsjmxObZX8VYs6nb0NqY8H/obTw5fDbSC9DIxYm7QWU5AnYjILSIly/wgoUVS9JzPME92 XI+jaJgJmLgrWc1gLW0XPV4tBtvObZjvFHBMCKl6EuW1LRtjo=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,214,1613433600"; d="asc'?scan'208";a="34904824"
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; 12 Apr 2021 07:54:20 +0000
Received: from [10.61.144.80] ([10.61.144.80]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 13C7sIIV032748 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Apr 2021 07:54:19 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <98456329-CE85-4BB2-B93F-74776FEBA299@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_DC4B97F3-6C62-4AD3-93DD-138EC408BDE2"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Mon, 12 Apr 2021 09:54:17 +0200
In-Reply-To: <CAOgPGoArm2RdEN4V-L9XEUvOeG0Vs+58Zj_p3Y2yRY0aYsVV_A@mail.gmail.com>
Cc: EMU WG <emu@ietf.org>
To: Joseph Salowey <joe@salowey.net>
References: <CAOgPGoArm2RdEN4V-L9XEUvOeG0Vs+58Zj_p3Y2yRY0aYsVV_A@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-Outbound-SMTP-Client: 10.61.144.80, [10.61.144.80]
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/yYDLRz8forPRYphZdTapV5zj5Zk>
Subject: Re: [Emu] Issue 47 Certificate identity checks
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: Mon, 12 Apr 2021 07:54:27 -0000

Hi Joe,

I’m okay with most of this text except for as follows:

> 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU specified in RFC 3770.

The above sentence is unnecessary.  Of COURSE CAs can issue certs with that EKU or any other.  What I think you mean is this:

CAs issuing certificates intended for use by EAP servers SHOULD specify the id-kp-eapOverLAN EKU specified in RFC 3770.

[I am even tempted to say MUST, but I don’t think we ca go that far.]

[…]


>  3. If the above options are not available then separate trust roots need to be used to issue certificates for EAP-TLS server and for TLS servers.

I don’t think this is sufficient.  Rather, I would discuss the logic behind it.  In particular, I would state quite clearly something along the following lines:

“EAP peers need to have some basis to decide which networks are authorized.  A key signal for this purpose is the validation of the server certificate.  To prevent use of the wrong server, the peer SHOULD have some means to select and update appropriate trust anchors.  How this happens is beyond the scope of this memo."


> EAP TLS peer implementations MUST allow for configuration of a unique trust root to validate the server's certificate.

This statement seems independent of the previous one, and may be overly broad.  Let me give you an example: a device may be designed only to operate as part of a federation.

Eliot