[Ace] Fwd: call for adoption for draft-marin-ace-wg-coap-eap

Dan Garcia <garciadan@uniovi.es> Mon, 25 January 2021 20:56 UTC

Return-Path: <garciadan@uniovi.es>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D293A18C8 for <ace@ietfa.amsl.com>; Mon, 25 Jan 2021 12:56:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=unioviedo.onmicrosoft.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 QrT_yBXcf4tf for <ace@ietfa.amsl.com>; Mon, 25 Jan 2021 12:56:30 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04hn0246.outbound.protection.outlook.com [52.100.18.246]) (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 8AFCD3A18CA for <ace@ietf.org>; Mon, 25 Jan 2021 12:56:29 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OT8PMEereQyBkIZUerDt5d1aRkc8aGZxzfF0IpkxORwWaJQEVmeFswklOixYcLJULQ46jKN0K0cHeUXw+UWLkVEeyc/LS3B+bzQFTmE8I/4WlpGhDzrAv0tJQLaEJ3+GQ/gUGLU08I2ErqG95eJG8sipbo88azdHKRiinrLMNR+Oey12y2gJkFC1YWj62s1UstJ54jJqR69c9ZbPHm6QA+1wnR+mQ98RGTHazZK+w5QVSW4HUlrWb7P/hhdtPsgcMVVDaz6qve5gD4gpe50ICkTL9Y3Y62lwAkNQiJ7l1hqhnycS/OFzKpc5tD5lvPIaR1arX1w8rXa9/zpf0ey+3A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mXf+gyiWSzZwVDXNfXsEbyyMsXJXXRwCwoiFAwSjxzI=; b=iavdlWRHtPFpw+C3I8cS6kKvIUjQm2tA1CFEuB2rt9CbhTBZYU5YfVlk9csSz0WUm3vu+AgEUHSoInKPhceDTvF2d+o6bI+2qwbXqHLnbddlJzhLqRG9k96jb30Dl3Pdp9e2JLmsvzpF0XTiMXq1nXCuLTcCgtxt5hnnGdAfb5wcqCpTTUq35mPO/2mJXuFtXDMKmzsY6M5DiVo1e2fw2oqehb69NILDpPIUhRsN08RVH/R2u0jYTmdWFwdIBJF9fis7qIl7MARa8wyz7r3q0BXp6wI9/fQjRJrysDcsuLBoD/ajKz6A9yuWKfYzE9gG5sESQw2g8dEwMNjXNbIjcQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uniovi.es; dmarc=pass action=none header.from=uniovi.es; dkim=pass header.d=uniovi.es; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unioviedo.onmicrosoft.com; s=selector2-unioviedo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mXf+gyiWSzZwVDXNfXsEbyyMsXJXXRwCwoiFAwSjxzI=; b=ojno/nUUQBFBHMDDeudAo7Z1SSmKRN/keFzTCx/aVf9Z55LaoLMJI3waREtDvvXIXGCT5+cgHpkIz/nEHpTxo3cj3BmCWg5SeFrW/uIdR/Wb/7Q+cCIek772wmtPDYtCcur/yFVyTPpbVQe7QbpoT9kQ+w4WfZDdmBtTXQfNCU8=
Authentication-Results: uniovi.es; dkim=none (message not signed) header.d=none;uniovi.es; dmarc=none action=none header.from=uniovi.es;
Received: from DBBPR08MB6202.eurprd08.prod.outlook.com (2603:10a6:10:209::9) by DB6PR08MB2776.eurprd08.prod.outlook.com (2603:10a6:6:1d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.12; Mon, 25 Jan 2021 20:56:18 +0000
Received: from DBBPR08MB6202.eurprd08.prod.outlook.com ([fe80::38e0:69e7:135f:ad22]) by DBBPR08MB6202.eurprd08.prod.outlook.com ([fe80::38e0:69e7:135f:ad22%5]) with mapi id 15.20.3784.017; Mon, 25 Jan 2021 20:56:18 +0000
Cc: garciadan@uniovi.es
References: <09cb6606-f833-25ad-2f72-ed05c5883808@uniovi.es>
From: Dan Garcia <garciadan@uniovi.es>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "ace@ietf.org" <ace@ietf.org>
X-Forwarded-Message-Id: <09cb6606-f833-25ad-2f72-ed05c5883808@uniovi.es>
Message-ID: <ff6c2964-e99a-c7d3-1c96-2f55e3a3f871@uniovi.es>
Date: Mon, 25 Jan 2021 21:56:15 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
In-Reply-To: <09cb6606-f833-25ad-2f72-ed05c5883808@uniovi.es>
Content-Type: multipart/alternative; boundary="------------848848544C4BFC37614521AE"
Content-Language: en-US
X-Originating-IP: [94.73.46.103]
X-ClientProxiedBy: MR2P264CA0105.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:33::21) To DBBPR08MB6202.eurprd08.prod.outlook.com (2603:10a6:10:209::9)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from DansMacBookPro.local (94.73.46.103) by MR2P264CA0105.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:33::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.16 via Frontend Transport; Mon, 25 Jan 2021 20:56:17 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: c536c04f-7bb2-41c1-d674-08d8c173a942
X-MS-TrafficTypeDiagnostic: DB6PR08MB2776:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <DB6PR08MB277661DFBC8D7AF241298FC3B4BD0@DB6PR08MB2776.eurprd08.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: cLDu5Y++nFzgFiZ0ILwMPGTVlQ9HSGEdSUY4EFwAOPnSj+hjYIFRszsk0y7KzwpYRLb2gsqCT4X9e9myP7rXddSupDCaemfMevrgEk/qJmwDG17tzepj/tN5IglujR7KPUp3M6U0OsCdqrmV58Ld+ECx0hUE8+obvPhRRXeXpHLW5WHT6w/YqtolmbCtspUnNt//8sjVAKc2hxoz+UcKMmBXPlgosrN/5rpZyv4fNfRFRtrxh5CnyorgVeXfj1RWmGL5Az4HUfs8u5VEylxYHlod0lh+5D/ORlgNg/hGjM1iHCfNiKc9PRqV3mE1I3QJzatMCK91WYx9XQvTcT1EndgYUw5QiKKEPEnagpMmPBeyoyRsjGhL5bareO/t6eIYfIs3TbtqW2Ngpj9AbxG5dsuUNUH04nYmvaKDEbdeyaCUPsT06mFGAYV1g8wae9YV9LZR4x95d2nyJWelfkBDq4Ntogdey2RyUcLN9brKiH5Py5SdmoTygxh17E7NnGyw7NpHNCO/Jp70XsUhI3LG3aa2DZrVw9Xths1rek+Ea/DzDHmnREs5e4KJGe5sGKFIy7Vu7eIJ4O332743BQZBwMf96pAfdECKKFJEd+nSs49ymm34ifitD9SdbDJQiC30Yb45mGd4yNLqIp14IHf46PSrs6p8rVZdVrZbFt3Jy0pQEhSZO9h/eIzQmP4dK7jsI4VP9SmfYpw85sJr9a4Jk5QplGiGNoBR3KjS80RAacl1uRaUHmPZB6k7jrCWB7Vj
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:5; SRV:; IPV:NLI; SFV:SPM; H:DBBPR08MB6202.eurprd08.prod.outlook.com; PTR:; CAT:OSPM; SFS:(39850400004)(346002)(376002)(396003)(366004)(136003)(316002)(8676002)(6486002)(66556008)(33964004)(786003)(8936002)(66574015)(478600001)(4326008)(66476007)(186003)(6506007)(2616005)(31686004)(110136005)(2906002)(83380400001)(31696002)(107886003)(52116002)(16526019)(26005)(66946007)(36756003)(86362001)(956004)(5660300002)(6512007)(4090200001); DIR:OUT; SFP:1501;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?eEJIVjhoWnA0UVJJRHlNU3RRYUoreVlRblU0aERSVDExWDRqNnVzSlR0SUxP?= =?utf-8?B?T1QrYmpVQXRTcUthUEpWNWc1Vis5WmhDNlU0cXV6M0dFWXozVUkzMjM2RnFX?= =?utf-8?B?Z2dWVmxpVDZqZWZRZUpLSGRNMThZSWo5N3AxaTUxSzFyVkdEaW1yUGdqbHNK?= =?utf-8?B?alpqdFZPMlBvVXZGZ0RFTEVqZmVrYWVIVC9Pay9rVldFWnVyRkQxNFMvdHMv?= =?utf-8?B?aUh4T2p0M3hKYU9obkd1Z0k2bW9CSEJLb2lJL0NMbzVPWGJTNDJaaEdwWjNp?= =?utf-8?B?Smw5NTNLV0JMaEppVE5ITFpGR2JMRmJ5M0wrUXg2Z3kvY3JraUViRGQ3VWl6?= =?utf-8?B?TXEzQTZlbkIyY0N4SHE5UFl6UUZ6MnpiNTd3T1pieGtiUmFibHBaQWlwTzlD?= =?utf-8?B?VUhrcER0N1VzSHVScmpSZDhNdjhPb0YzblFKc09hRm9zSXB1TjNUK2VRMWx6?= =?utf-8?B?bDBrU1E1RkJrS3BMdkJ0RXBreDc3QzRHU1ZxWTBPanV1VC9PZTBtSFM2TWtH?= =?utf-8?B?aHZTYlZLcFZUQjVPVk15aVhlc3VLaTlZYmlFRzVuU0k4czNaOVRlMDRMM3dE?= =?utf-8?B?MTlORlpac2tXVk8xVHp2bFl3VGViS3labzlHWmpUZXBUalEzbHg1ekg3UUI3?= =?utf-8?B?ckM1aUVzTUlibDFBemxYQTJxeUNCUzhVdVY3cm41MnIrRHVvZDZnckpQd1VX?= =?utf-8?B?dXZSalEyVURGWjdkU2cvRkFpV1ZHd2FENVQ0TE5kQjJiaXJ3ZTBvMlh2Vm9j?= =?utf-8?B?dGtHMk5WRWYxeVp1V1NOaTNPczlSblhsRnZ0WG92UUFqL0d6R3prRkNvMm9k?= =?utf-8?B?clpjUzAxL21Td1psNnBkc28vTS91ZDNnRjcvbTN2amFneTlMUlBjYVhNTmw5?= =?utf-8?B?UG81L085TGNQcDQvaFRzalhLOUtZdDFUSm9MVVVjOUppSW9pWGNTeEtwSUkx?= =?utf-8?B?U3F6ZHNsY2JjWG16b3MwdTZuajJqUW5hbkJUSzJaWDhONVZONlpsZDdibW9S?= =?utf-8?B?UUR1aVozcmhpTWcrQ1FHejYxYWJyKytDcmVwbXFuWWRYSHJNTTdVSUcrYWtH?= =?utf-8?B?TlJ6cmdIZmlZR2VGV2dSNko2cEkvZ3l4b21LVGdSekRrRC9JeGNvWUo2dGxI?= =?utf-8?B?YlZKUVV4TW5CL25HcnZ5aHJxdUUwaGg5aTNYcnNyVE9lYjRtOXBVaDAvTVlQ?= =?utf-8?B?dXA3eWJSNW9kMTJPS0grL0dGWWxSdStXNlk5NzZWeDFWUFNyTkQyYkM3WEpU?= =?utf-8?B?ak5WWXZPcGs1V01hRW9LNFlCNm51VEtBaVNtZXBVN0hNcUJsNzdmZlJWMU1a?= =?utf-8?B?ZlJST2FZTXg2ajhneDNPbkMvWnkrbWQwTmY1UVVPY2U3ZVZIR1NQdjFybDI2?= =?utf-8?B?bW84bDA1WWdIbld4UmRGSkcrNWkzV3BaSHRXY1gveE5pTkpqN21rSzBicjVj?= =?utf-8?Q?8Q+cACN6?=
X-OriginatorOrg: uniovi.es
X-MS-Exchange-CrossTenant-Network-Message-Id: c536c04f-7bb2-41c1-d674-08d8c173a942
X-MS-Exchange-CrossTenant-AuthSource: DBBPR08MB6202.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2021 20:56:17.9299 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 05ea74a3-92c5-4c31-978a-925c3c799cd0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: yeajzdmbXv7xsrPAJP+jtvt/L666Qvlx56Vbf0Elu5wEuqZA4trlgri4/QtZuPmkES9qc+IiGTHJwBFMqcufXA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2776
X-MS-Exchange-CrossPremises-AuthSource: DBBPR08MB6202.eurprd08.prod.outlook.com
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 06
X-MS-Exchange-CrossPremises-Mapi-Admin-Submission:
X-MS-Exchange-CrossPremises-MessageSource: StoreDriver
X-MS-Exchange-CrossPremises-BCC:
X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 94.73.46.103
X-MS-Exchange-CrossPremises-TransportTrafficType: Email
X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:SPM; SKIP:0;
X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent
X-OrganizationHeadersPreserved: DB6PR08MB2776.eurprd08.prod.outlook.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/68hm3tkqhF23lX1swrZHREDLl0w>
Subject: [Ace] Fwd: call for adoption for draft-marin-ace-wg-coap-eap
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2021 20:56:33 -0000

Hi Michael,

El 23/01/2021 a las 1:29, Michael Richardson escribió:
> Dan Garcia Carrillo<garciadan@uniovi.es>  wrote:
>      > I hope the last email answered your questions.
>
> Are you talking about this answer:
>
>> - Well known protocol thas provides flexible authentication with diffrent methods and counting.
>> - It integrates well with AAA.
>> - It has a standard and very well known Key Management Framework.
> because it continues to not be answer.
>
> These are all features of EAP.

Sure. But as proponents of an EAP-based solution in IoT, it is important 
to show its benefits, which is what we do first in the I-D.

> How does EAP-over-CoAP benefit?
>
> EAP can be used inside (D)TLS (and maybe even cTLS) without CoAP having to carry EAP.
> I guess you want to be able to key OSCORE.
> So, I would guess that this must involve not using EAP-TLS* (or TEAP, or
> TTLS, etc.), so I think that reduces to some kind of EAP-PAKE situation,
> or EAP-SIM/AKA.

Regarding this question, in our I-D, we design an EAP lower-layer (see 
RFC 3748) based on CoAP. We assume that CoAP is a lightweight protocol 
that is adapted for constrained devices. Therefore a CoAP-based EAP 
lower layer will inherit these features, unless CoAP is not lightweight 
enough or it its not suited for IoT, which is not the case. Another 
assumption is that constrained devices will ship with a CoAP 
implementation too.

So, if you transport EAP, you need to design an EAP lower-layer. It is 
not just transport EAP over anything. RFC3748 defines this in Section 3. 
Moreover, regarding your suggestion, the EAP specification specifies the 
requirements for an EAP lower layer:

Section 3.1 Lower Layer requirements

"Lower layer security.  EAP does not require lower layers to
provide security services such as per-packet confidentiality,
authentication, integrity, and replay protection.  However, where
these security services are available, EAP methods supporting Key
Derivation (see Section 7.2.1) can be used to provide dynamic
keying material.  This makes it possible to bind the EAP authentication
to subsequent data and protect against data
modification, spoofing, or replay.  See
Section 7.1 for details."

You need define an EAP lower-layer following the requirements in section 
3.1 RFC3748.

This is precisely how CoAP-EAP is designed.

In fact, I was wondering how it can be lighter to establish a DTLS 
connection and then transport EAP in order to key OSCORE (that sounds 
too heavy in my opinion), for example, than using CoAP.

> Do both peer talk to the same AAA server?
>
> In that case, then they must have already established a secure relationship
> with the AAA server. (Because, radius demands it).

Actually, the Controller (where the EAP authenticator is placed) will 
have a secure relationship with a next hop AAA server but it does not 
have to be the AAA server where the EAP server is located.

If you check Fig 1. in RFC 5247 the AAA part is just refering to a AAA 
infraesturcture, which may be formed by several AAA “hops” until 
connecting with AAA server that has the EAP server. But that is 
something already working nowdays, as you may know.

> If you have that, then you can just use the ACE framework to get OSCORE keys,
> treating the AAA server as the AS or RS.

I do not understand what does “treating the AAA server as the AS or RS” 
mean? Are you going to use AAA protocols with them? which entity is 
acting AAA client? where is the EAP server placed?

Nevertheless, that is not our target. In our mind, CoAP-EAP happens 
before the ACE framework but it is complementary to ACE. The reason 
is that CoAP-EAP can be used as “client registration” but using EAP. As 
you know, ACE-OAuth leaves open the client registration:

"Client registration and provisioning of client credentials to the
    client is out of scope for this specification."

For the ACE case, with CoAP-EAP, we can establish some key material 
between the client (constrained device) and AS.
> If they don't talk to the same AAA server, then how are the AAA servers related?
This is also part of the basics of AAA: they belong to a federation. We 
use this everyday in eduroam, for example.

Based on EAP peer identity (represented as a Network Access Identifier) 
helps to “route” the EAP packets to the AAA/EAP server. However, that is 
something that AAA infraestructures already support, so nothing new 
there. We do not see any problem either.

Best Regards.

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