Return-Path: 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 4C248C14F5FD; Sat, 18 May 2024 11:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.847 X-Spam-Level: X-Spam-Status: No, score=-6.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 I-37tOkv2fz5; Sat, 18 May 2024 11:40:37 -0700 (PDT) Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 72B29C14F5FB; Sat, 18 May 2024 11:40:37 -0700 (PDT) Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-2451da9b4feso661598fac.0; Sat, 18 May 2024 11:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716057636; x=1716662436; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wzSNPSILQo6uxl66J4qYFF27oLgFVr4iEnSq5k4xzDQ=; b=EZuqR03Q1PqBTA5/hfUYfED7xbvcoCbiu7t6f9unYM1RvgUYDCqSFPmAIv1mW0MYKA rFG1NzhIp9TGLJ6RonBRSgbTvJ2F9SsWhTgKTcyllbuJikfyPsseTfvmA6ahwv5OPBJU 9KdXB+zmWkh2XlO0olNoijYw6eb7KT2uVQJPIPnE7X6tS+rjL/tApfYAnRDDFzA1XH28 Wa6yIqHi7ZaJwZV/ZoA/whjULfrV/5pCKc68GhOrojHgRJoehmNRV9vYFaM/VMKqyk6N MXiHcAN6/kq4P7qxhCwy2ZYN40mQOeS9qd15Vsp2OehA3UsRQba+QIjndjCRcSmiPKK2 WUhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716057636; x=1716662436; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wzSNPSILQo6uxl66J4qYFF27oLgFVr4iEnSq5k4xzDQ=; b=W38dmRt0OKxMXC/XkPe1CUBVYFrh7Sz5KxyWI5CgFSTIx/zyquetFNxyVlMafqMv0s 0vUNYzItl6TIG1Xvntx+pTDUqlEgAoIvyaygoG4CegGU5Upf3dWAkp7pVazpbyAaT4ev XWhLnh8snUoWTI56CVbmnuW51nYgNHhiN2H27bevUrD8uZ+rIauWO0WiwVmtLkow0PjU kIpHwrc/RbTpYxhUwzaDHSyNwkPE870+/ZomhyvYYRdEol5KYKVli6/V7gRE1jqbrl4E eqe66H2zDGLgnq+6mBGjj5pTpzkbjtJpZlbdn2kZkQ8qdBdLCqLcS+RR20Eo7H1NpIGq 2rJA== X-Forwarded-Encrypted: i=1; AJvYcCVGsEXq3l8dSRnjPxPpys+5BwCh4pnyk+JobY2LwsK4pzBzDKsqc1QUSB90LHgWflRO10u0mKZ7bPStoSc= X-Gm-Message-State: AOJu0YzAiZouWpr9FmYEOqz8MtI/fMlArgAaMMN8ZCC0UXvqZagmO8lV ocIzdqB6LvQA85iSCmBpmAuZoiTPzMt20sZBpo8HBM8SVbo0OV+mCb1xiORu6xBBTSnx2RU1V5C xGlayCdg4j0pdNYTBdEO16fH4PnFhQYIyUOc= X-Google-Smtp-Source: AGHT+IEEtPvTXOrjZxtbTDBTMp9+OUp7Uu2mK2xdzC0closiC1DEdG68XSVDjLOoZvNU+SGgy+yTUvBR2oElnczFccE= X-Received: by 2002:a05:6870:1583:b0:22e:9b70:7942 with SMTP id 586e51a60fabf-24172a4d5f6mr34459716fac.4.1716057636562; Sat, 18 May 2024 11:40:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: sree lakshmi Date: Sat, 18 May 2024 20:40:00 +0200 Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Content-Type: multipart/alternative; boundary="000000000000d770970618becdc9" Message-ID-Hash: C67BW7IAUNNZCGCYQENYRDQHYL667SVB X-Message-ID-Hash: C67BW7IAUNNZCGCYQENYRDQHYL667SVB X-MailFrom: vssreelakshmi24@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ace.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: draft-vattaparambil-ace-wg-poa-device-reg@ietf.org, ace@ietf.org X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BAce=5D_Re=3A_PoA_based_Device_Registration_=28draft-vattaparamb?= =?utf-8?q?il-ace-wg-poa-device-reg=29=3A_Support=2C_suggestions?= List-Id: "Authentication and Authorization for Constrained Environments (ace)" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000d770970618becdc9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christian, The assumption I've been working on is that DO is enrolled to the AS as > a C. Either the authorizations the AS associates with the DO have a > "this may be delegated" flag on them, or the AS simply treats itself as > an RS, where some C (such as the DO) are authorized to utilize the > "register more clients and transfer some authorizations" interface. Okay, this is an interesting delegation approach. So here the AS provides an option to delegate (the delegation flag) to DO, which later makes DO to delegate the Client. We had a similar discussion on these multi-level delegations. As I understand, in this way the authorizations the AS associates with the DO can be delegated to the Client. As I understand the interfaces we lack, the OAuth dynamic client > registration covers both the creation of a client and giving it the > right scope; for ACE I hope we can do something much slimmer. Sure, we can avoid the client sending the client registration request to the AS as it is in OAuth dynamic client registration. This is essential for the constrained nature of the client in ACE. I think the only parameter or step similar here would be the client id or key id that the AS must provide the DO upon successful client registration. > > The alternative flow can certainly be a good simplification in some > It would be a *great* simplification if by the mere request from the DO > it could already issue the token and install it on the RS, and refresh > it on expiry (for this would free the C from the need to ever actually > perform the C-AS protocol). Some prior chats indicate that this would > contradict the ACE architecture where the AS needs to prove that C > actually has that key, but let's discuss that more. (Personally I don't > see anything wrong with the AS issuing a token to C blindly -- the token > will be bound to the key included, and success of EDHOC proves > possession of that key to the RS). > If that larger simplification is possible, the data the C receives from > the DO would not even include AS details any more, but instead would > contain details of the token response (eg. rs_cnf). cases. > Yeah, I agree, when the client submits the access token req with the credentials from the req_rs claims pointing to the public key of DO, the AS can identify the registered client in the previous step. What about the client id that is obtained from the AS in the previous step (client registration step)? Shall we have to include it as well? Or is there a way the AS can recognize the C without this identifier (Client ID or Keyid)? I have more questions regarding this we can discuss next week. The credentials are not sent in plain text in EDHOC: the initiator's > credentials (ie. the token) would only be revealed to the RS after C has > verified that the RS just presented the right rs_cnf. Okay. Multiple entities definitely make this more complex. If the RSes can be > expresed as a group audience, tools like rs_cnf2 (also from > ace-workflow-and-params) could help. I understand, now the last section in the draft talks about the use of PoA with multiple entities. This might be the right section to elaborate on the issues and possible solutions with n number of RSs and clients. /Sree On Fri, May 17, 2024 at 3:57=E2=80=AFPM Christian Ams=C3=BCss wrote: > Hello Sree, > > On Fri, May 17, 2024 at 02:57:24PM +0200, sree lakshmi wrote: > > In this draft, we have assumed a pre-established mutual authentication > > step between the DO and the AS. We haven=E2=80=99t explained it in deta= il > > because it is an assumption. > > The assumption I've been working on is that DO is enrolled to the AS as > a C. Either the authorizations the AS associates with the DO have a > "this may be delegated" flag on them, or the AS simply treats itself as > an RS, where some C (such as the DO) are authorized to utilize the > "register more clients and transfer some authorizations" interface. > > As I understand the interfaces we lack, the OAuth dynamic client > registration covers both the creation of a client and giving it the > right scope; for ACE I hope we can do something much slimmer. > > > I read a new alternative protocol flow of ACE (L1), this will even > > decrease the load on the client side. We can discuss. I will look into > the > > CoRE dynlink you mentioned. Will see how we can use it. > > The alternative flow can certainly be a good simplification in some > cases. > > It would be a *great* simplification if by the mere request from the DO > it could already issue the token and install it on the RS, and refresh > it on expiry (for this would free the C from the need to ever actually > perform the C-AS protocol). Some prior chats indicate that this would > contradict the ACE architecture where the AS needs to prove that C > actually has that key, but let's discuss that more. (Personally I don't > see anything wrong with the AS issuing a token to C blindly -- the token > will be bound to the key included, and success of EDHOC proves > possession of that key to the RS). > > If that larger simplification is possible, the data the C receives from > the DO would not even include AS details any more, but instead would > contain details of the token response (eg. rs_cnf). > > > We also do not like to send the credentials in plaintext, we can go wit= h > > EDHOC with key identifiers, but I am not well aware of how this works a= nd > > how to show this in the protocol flow diagram. We can have a discussion > on > > this. > > The credentials are not sent in plain text in EDHOC: the initiator's > credentials (ie. the token) would only be revealed to the RS after C has > verified that the RS just presented the right rs_cnf. > > > The problem with bundling of the AS URI, AS credentials, audience, scop= e; > > we haven=E2=80=99t thought about it in this way. We had a small thought= on > multiple > > entities and the scalability of the solution. > > Multiple entities definitely make this more complex. If the RSes can be > expresed as a group audience, tools like rs_cnf2 (also from > ace-workflow-and-params) could help. > > > We can meet in Paris, me and Olov will participate in person:) > > Looking forward to that! > > BR > c > > -- > To use raw power is to make yourself infinitely vulnerable to greater > powers. > -- Bene Gesserit axiom > --000000000000d770970618becdc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= Hi Christian,

The assumption I've been working on is that DO is enrolled= to the AS as
a C. Either the authorizations the AS associates with the DO have a
= "this ma= y be delegated" flag on them, or the AS simply treats itself as
an RS, where som= e C (such as the DO) are authorized to utilize the
"register more clients and tr= ansfer some authorizations" interface.

Okay, this is an interesting delegation approach. So here the AS provide= s an option to delegate (the delegation flag) to DO, which later makes DO t= o delegate the Client. We had a similar discussion on these multi-level del= egations. As I understand, in this way the authorizations the AS associates= with the DO can be delegated to the Client.=C2=A0=C2=A0

As I un= derstand the interfaces we lack, the OAuth dynamic client
registration covers both th= e creation of a client and giving it the
right scope; for ACE I hope we can do someth= ing much slimmer.
=C2=A0
Sure, we can avo= id the client sending the client registration request to the AS as it is in= OAuth dynamic client registration. This is essential for the constrained n= ature of the client in ACE. I think the only parameter or step similar here= would be the client id or key id that the AS must provide the DO upon succ= essful client registration.=C2=A0

Th= e alternative flow can certainly be a good simplification in someIt would be a *grea= t* simplification if by the mere request from the DO
it could already issue the toke= n and install it on the RS, and refresh
it on expiry (for this would free the C from = the need to ever actually
perform the C-AS protocol). Some prior chats indicate that = this would
contradict the ACE architecture where the AS needs to prove that C<= br>actually has that= key, but let's discuss that more. (Personally I don't
see anything wrong wit= h the AS issuing a token to C blindly -- the token
will be bound to the key included,= and success of EDHOC proves
possession of that key to the RS).
If that larger simplification is possible, the data the C= receives from
the DO would not even include AS details any more, but instead would
contain det= ails of the token response (eg. rs_cnf).
cases.

Yeah, I agree, when the client submits the acce= ss token req with the credentials from the req_rs claims pointing to the pu= blic key of DO, the AS can identify the registered client in the previous s= tep. What about the client id that is obtained from the AS in the previous = step (client registration step)? Shall we have to include it as well? Or is= there a way the=C2=A0AS can recognize the C without this identifier (Clien= t ID or Keyid)? I have more questions regarding this we can discuss next we= ek.=C2=A0

<= span style=3D"font-family:Arial,Helvetica,sans-serif">The credentials are n= ot sent in plain text in EDHOC: the initiator's
credentials (ie. the token) wou= ld only be revealed to the RS after C has
verified that the RS just presented the rig= ht rs_cnf.
Okay.

Multiple entities definitely make this more complex.= If the RSes can be
expresed as a group audience, tools like rs_cnf2 (also from
ace-workflow-an= d-params) could help.


I understand, now=C2=A0the last section in the draft t= alks about the use of PoA with multiple entities. This might be the right s= ection to elaborate on the issues and possible solutions with n number of R= Ss and clients.=C2=A0


/= Sree





On Fri, May 17, 2024 at 3:57=E2= =80=AFPM Christian Ams=C3=BCss <christian@amsuess.com> wrote:
Hello Sree,

On Fri, May 17, 2024 at 02:57:24PM +0200, sree lakshmi wrote:
> In this draft, we have assumed a pre-established mutual authentication=
> step between the DO and the AS. We haven=E2=80=99t explained it in det= ail
> because it is an assumption.

The assumption I've been working on is that DO is enrolled to the AS as=
a C. Either the authorizations the AS associates with the DO have a
"this may be delegated" flag on them, or the AS simply treats its= elf as
an RS, where some C (such as the DO) are authorized to utilize the
"register more clients and transfer some authorizations" interfac= e.

As I understand the interfaces we lack, the OAuth dynamic client
registration covers both the creation of a client and giving it the
right scope; for ACE I hope we can do something much slimmer.

> I read a new alternative protocol flow of ACE (L1), this will even
> decrease the load on the client side. We can discuss. I will look into= the
> CoRE dynlink you mentioned. Will see how we can use it.

The alternative flow can certainly be a good simplification in some
cases.

It would be a *great* simplification if by the mere request from the DO
it could already issue the token and install it on the RS, and refresh
it on expiry (for this would free the C from the need to ever actually
perform the C-AS protocol). Some prior chats indicate that this would
contradict the ACE architecture where the AS needs to prove that C
actually has that key, but let's discuss that more. (Personally I don&#= 39;t
see anything wrong with the AS issuing a token to C blindly -- the token will be bound to the key included, and success of EDHOC proves
possession of that key to the RS).

If that larger simplification is possible, the data the C receives from
the DO would not even include AS details any more, but instead would
contain details of the token response (eg. rs_cnf).

> We also do not like to send the credentials in plaintext, we can go wi= th
> EDHOC with key identifiers, but I am not well aware of how this works = and
> how to show this in the protocol flow diagram. We can have a discussio= n on
> this.

The credentials are not sent in plain text in EDHOC: the initiator's credentials (ie. the token) would only be revealed to the RS after C has verified that the RS just presented the right rs_cnf.

> The problem with bundling of the AS URI, AS credentials, audience, sco= pe;
> we haven=E2=80=99t thought about it in this way. We had a small though= t on multiple
> entities and the scalability of the solution.

Multiple entities definitely make this more complex. If the RSes can be
expresed as a group audience, tools like rs_cnf2 (also from
ace-workflow-and-params) could help.

> We can meet in Paris, me and Olov will participate in person:)

Looking forward to that!

BR
c

--
To use raw power is to make yourself infinitely vulnerable to greater power= s.
=C2=A0 -- Bene Gesserit axiom
--000000000000d770970618becdc9--