IETF Logo Mail Archive

Re: [Emu] EAP onboarding at ANIMA WG

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 11 July 2022 21:03 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 5DF4EC16ECC0; Mon, 11 Jul 2022 14:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.706
X-Spam-Level:
X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BKDmYtWYE6F; Mon, 11 Jul 2022 14:02:58 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4585FC16ECB6; Mon, 11 Jul 2022 14:02:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7A5D839F0A; Mon, 11 Jul 2022 17:20:18 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IH1KL2_Z8DiH; Mon, 11 Jul 2022 17:20:14 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BBF5939F0B; Mon, 11 Jul 2022 17:20:13 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1657574413; bh=2fDyEoiqmo8rjQ+nCTeqDRTIi8WEsGX3rzH5KyL5L1Y=; h=From:To:Subject:In-Reply-To:References:Date:From; b=ZGlV3FH5K9HbLesi4n5Vh446m54VJtc55lVpb3Hovlrm7b52ttstDbnF2VOT9A/hE xFHMhBGv5EP3V07H8BZXZS2DQ8mKuc5NZw5P9wfeIhxjO+NXquS0GWlhfht3UJsb4I 6hH8slgdkOVNCk1ielFwyvKjMM6UcxwtiODRk4a57UlxKhaLUz6nihvyEkxSPkWs9o BjPWHVUglNqup8G/Hy5KCxZJ3i5rZ3n0Z3ZzVG6AQDadx0XvbqO1PLn9xj/XZrtCVu OIgaJ+HbONKbmEidwITfEAm0k9hDc+NFmjmJKpveADkPzdA5f7EeSG+hKcBJ771KT5 bmdrUfvaf8gZA==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 55355373; Mon, 11 Jul 2022 17:02:51 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Alan DeKok <adekok@gmail.com>, anima@ietf.org, EMU WG <emu@ietf.org>
In-Reply-To: <FD19D671-2786-42D1-B553-96F29375E259@gmail.com>
References: <CAL6Yo0LYGGrNv7bue2np4Px=8Pe5+M=bXQ_YEKtwONoCe5PUww@mail.gmail.com> <1972.1657561945@localhost> <FD19D671-2786-42D1-B553-96F29375E259@gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 11 Jul 2022 17:02:51 -0400
Message-ID: <19811.1657573371@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/y8JlcLCOWde9rzSnmVLgtFvz1nM>
Subject: Re: [Emu] EAP onboarding at ANIMA WG
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.39
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, 11 Jul 2022 21:03:02 -0000

Alan DeKok <adekok@gmail.com> wrote:
    > The current draft is missing some points:

    > * SNI for the supplicant to indicate which domain it would like to access
    > * supplicant examination of the server certificate to see which domain it accessed

This is actually a bit of a complex question, I think.

If the realm announced is eap.arpa, wouldn't the SNI have to have that?
Given that, and given that it's a domain that you can't get a certificate
for, it seems that the supplicant will have to accept whatever certificate is
returned on faith, until the device is online enough to do more.

This is not surprising in RFC8995(BRSKI), as it typically creates a
provisional TLS connection to the Registrar, which is *later* authorized by
an RFC8366 voucher.

Can we do this with supplicants?
I imagine so, but the write-up in the document could be challenging.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email