Subject: Re: [Ace] draft-ietf-ace-oauth-authz

From: Seitz Ludwig <[email-masked]>
Date: Mon, 4 May 2020 06:42:34 +0000

For the sake of getting the document finished before I die of old age ;-) would it be possible to specify this in a separate document?

/Ludwig

From: Ace <[email-masked]> On Behalf Of Peter van der Stok
Sent: den 1 maj 2020 08:56
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; 'Ace' <[email-masked]>
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

HI Jim,

I try to answer your question,

When I want to access an OCF device I can find its IP address through service discovery (rfc7252 section 7) using an rt-value registered at the IANA core parameters registry.
For example, when I want to initialize the AS I have to type in the IP address of the AS.
From that moment on keys and certificates can be compared to continue initialization.

Using service discovery can automate that process.

My request is that authz draft registers an rt-value in core parameters registry for service discovery of the AS,
unless a different process has already been established for AS initialization.

Many thanks,

peter

Jim Schaad schreef op 2020-04-30 17:25:

What do you expect to see?   By default a client needs to know that something is an AS and have a key to interact with that AS.

Jim

From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Peter van der Stok
Sent: Wednesday, April 29, 2020 11:57 PM
To: Ace <[email-masked]<mailto:[email-masked]>>
Subject: [Ace] draft-ietf-ace-oauth-authz

Hi authz authors,,

While implementing a version of AS, I noticed that there is no resource type (rt) registered for /.well-known/core discovery.
Is this voluntary?
If not, can it still be added?

thanks,

peter

--

Peter van der Stok
vanderstok consultancy
mailto: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
www: www.vanderstok.org<http://www.vanderstok.org>
tel NL: +31(0)492474673     F: +33(0)966015248

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 4 May 2020 08:51:54 +0200

> For the sake of getting the document finished before I die of old age ;-) would it be possible to specify this in a separate document?

I think there may be multiple of these RT registrations, because the fact that a resource is part of an AS is only part of the information that is needed: The RT could tell us more about the way the AS wants to be used.

I think that is a strong argument to *not* do these RT registrations in the framework, because we will not have enough imagination to catch them all.

So my recommendation would indeed be a separate document.

Grüße, Carsten

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 04 May 2020 09:15:08 +0200

Hi Carsten,

The imagination will not have finished its work in 10 yeras time if coap
and the authorization will enjoy the success they merit.
Also I don't see anybody being ready to start such  a document the
coming month.
Do you see another document in which a first set of these registrations
can be added?

FYI, today I do my iplementation and (to my regret) will invent
something of my own. 

cheerio,

Peter
Carsten Bormann schreef op 2020-05-04 08:51:

> [email-masked]

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 04 May 2020 09:21:06 +0200

Hi Peter,

Peter van der Stok <[email-masked]> writes:

> When I want to access an OCF device I can find its IP address through
> service discovery (rfc7252 section 7) using an rt-value registered at
> the IANA core parameters registry.  For example, when I want to
> initialize the AS I have to type in the IP address of the AS.  From
> that moment on keys and certificates can be compared to continue
> initialization.
>
> My request is that authz draft registers an rt-value in core
> parameters registry for service discovery of the AS, unless a
> different process has already been established for AS initialization.

That is exaclty what originally has been done in section 9 of
draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the
process.

[1] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04#page-30

Grüße
Olaf

---

From: Seitz Ludwig <[email-masked]>
Date: Mon, 4 May 2020 07:20:12 +0000

Peter,

Why not document what you invent in a draft? To me it would be a good starting point.

/Ludwig

From: Peter van der Stok <[email-masked]>
Sent: den 4 maj 2020 09:15
To: Carsten Bormann <[email-masked]>
Cc: Seitz Ludwig <[email-masked]>; Jim Schaad <[email-masked]>; peter van der Stok <[email-masked]>; Ace <[email-masked]>
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

Hi Carsten,

The imagination will not have finished its work in 10 yeras time if coap and the authorization will enjoy the success they merit.
Also I don't see anybody being ready to start such  a document the coming month.
Do you see another document in which a first set of these registrations can be added?

FYI, today I do my iplementation and (to my regret) will invent something of my own.

cheerio,

Peter

Carsten Bormann schreef op 2020-05-04 08:51:
On 2020-05-04, at 08:42, Seitz Ludwig <[email-masked]<mailto:[email-masked]>> wrote:

Grüße, Carsten

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 4 May 2020 21:09:17 -0700

> draft-gerdes-ace-dcaf-authorize [1]. Somehow, this got lost in the

I think I'm still a little confused as to what good being able to
"discover" that the network says something is an AS is, without some prior
trust and/or key material for that AS.  How would the necessary trust be
established as part of such a discovery scheme?

Thanks,

Ben

---

From: Jim Schaad <[email-masked]>
Date: Mon, 4 May 2020 21:54:59 -0700

I have much the same problem.  While a client could find an AS which would
authenticate the client, I don't know how the client would establish any
degree of trust in the AS which is going to give it tokens.  If you have
already put a local public key for the AS into the client, then you might as
well put in a name for the AS as well.  I suppose you could get by with a
shared secret but that does not seem to be a good way to build up the
system.

Jim

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Monday, May 4, 2020 9:09 PM
To: Olaf Bergmann <[email-masked]>
Cc: Peter van der Stok <[email-masked]>; Jim Schaad
<[email-masked]>; [email-masked]; 'Ace' <[email-masked]>
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote:
> > When I want to access an OCF device I can find its IP address 
> > through service discovery (rfc7252 section 7) using an rt-value 
> > registered at the IANA core parameters registry.  For example, when 
> > I want to initialize the AS I have to type in the IP address of the 
> > AS.  From that moment on keys and certificates can be compared to 
> > continue initialization.
> >

I think I'm still a little confused as to what good being able to "discover"
that the network says something is an AS is, without some prior trust and/or
key material for that AS.  How would the necessary trust be established as
part of such a discovery scheme?

Thanks,

Ben

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 May 2020 07:38:20 +0200

On 2020-05-05, at 06:54, Jim Schaad <[email-masked]> wrote:
> degree of trust in the AS which is going to give it tokens.  

Hence the four-corner model [1].

Grüße, Carsten

[1]: https://tools.ietf.org/html/draft-ietf-ace-actors

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 05 May 2020 09:25:58 +0200

HI all,

I agree about the authorization/trust problem.
My request concerns something more trivial.

Suppose we have this new network with a set of servers, an (AS) (may be
more) and a controller.
The servers, controller and AS may have used BRSKI to enter the network.
The servers will only provide their service when a token has been sent.
The AS is completely empty, not aware of the servers or its clients.
The controller wants to fill the AS with the necessary information.

Both controller and AS have agreed on an initialization protocol, and
are equipped with the necessary secrets. (A protocol to be standardized
in general, but not my concen here)

Now, what IP address does the controller use to start the communication?

Typing in the IP address is a possibility, switching off all other
devices is another, etc...
I hoped that a coap discovery could be used such that the controller
learns the IP address of the AS.

When several AS servers are present, the controller can access each one
of them out till it accesses the AS with the correct credentials.

I hope my request has become a bit clearer.

Peter
Benjamin Kaduk schreef op 2020-05-05 06:09:

> On Mon, May 04, 2020 at 09:21:06AM +0200, Olaf Bergmann wrote: Hi Peter,
> 

I think I'm still a little confused as to what good being able to
"discover" that the network says something is an AS is, without some
prior
trust and/or key material for that AS.  How would the necessary trust be
established as part of such a discovery scheme?

Thanks,

Ben

---

From: Jim Schaad <[email-masked]>
Date: Tue, 5 May 2020 08:39:13 -0700

I don't see how the four-corner model solves the issue that I highlighted.  If the client does not have a key for any local AS, then nothing helps.  The four-corner model deals with the issue of the client and the RS not trusting the same AS, but the different AS entities trust each other on the back side.

Getting trust in a local AS seems to be a bootstrapping problem.

Jim

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Monday, May 4, 2020 10:38 PM
To: Jim Schaad <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>; Olaf Bergmann <[email-masked]>; Peter van der Stok <[email-masked]>; peter van der Stok <[email-masked]>; Ace <[email-masked]>
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

On 2020-05-05, at 06:54, Jim Schaad <[email-masked]> wrote:
> 
> I have much the same problem.  While a client could find an AS which 
> would authenticate the client, I don't know how the client would 
> establish any degree of trust in the AS which is going to give it tokens.

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Tue, 5 May 2020 08:43:53 -0700

Thanks Peter, that makes things a lot clearer.  However I think that you are not asking for who is an AS, but who is an AS that has a particular interface.  It would make more sense to define a new interface identifier for the upload/control protocol rather than just identifying who is an AS.

Jim

From: Ace <[email-masked]> On Behalf Of Peter van der Stok
Sent: Tuesday, May 5, 2020 12:26 AM
To: Benjamin Kaduk <[email-masked]>
Cc: Jim Schaad <[email-masked]>; Olaf Bergmann <[email-masked]>; 'Ace' <[email-masked]>
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

HI all,

Suppose we have this new network with a set of servers, an (AS) (may be more) and a controller.

Both controller and AS have agreed on an initialization protocol, and are equipped with the necessary secrets. (A protocol to be standardized in general, but not my concen here)

Typing in the IP address is a possibility, switching off all other devices is another, etc...
I hoped that a coap discovery could be used such that the controller learns the IP address of the AS.

When several AS servers are present, the controller can access each one of them out till it accesses the AS with the correct credentials.

Peter

Hi Peter,

Peter van der Stok <[email-masked] <mailto:[email-masked]> > writes:

Thanks,

Ben

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 05 May 2020 19:11:22 +0200

HI Jim,

Agree.
That's a new draft then with an rt value for a given upload protocol.

Peter
Jim Schaad schreef op 2020-05-05 17:43:

Thanks,

Ben

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2020 14:07:21 -0400

> establish any degree of trust in the AS which is going to give it

Is your question that you don't know how to trust that the AS is the correct
AS for RS-foo?

    > If you have already put a local public key for the AS into the
    > client, then you might as well put in a name for the AS as well.  I
    > suppose you could get by with a shared secret but that does not seem to
    > be a good way to build up the system.

Maybe there are redundant instances of the AS, or maybe there are multiple ways
(thus different IP addresses) by which to reach the AS.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jim Schaad <[email-masked]>
Date: Tue, 5 May 2020 19:38:38 -0700

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Tuesday, May 5, 2020 11:07 AM
To: Jim Schaad <[email-masked]>; 'Ace' <[email-masked]>
Subject: Re: [Ace] draft-ietf-ace-oauth-authz

[JLS] No, my question is how do I know to trust the AS period.  I don't have
a key to establish a secure session with the AS.  I guess doing full X.509
certificate processing would be an answer, but that could be difficult in
the event of a key compromise.

    > be a good way to build up the system.

Maybe there are redundant instances of the AS, or maybe there are multiple
ways (thus different IP addresses) by which to reach the AS.
[JLS] It could be that there are redundant instances of the AS, but then you
have the problem of either doing key sharing between all of them or needing
the ability to validate the key assigned to each of them.  If you have
different addresses, that might be interesting, but you are going to need to
do trial connections to each possible AS found until you get one that works.

Jim

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -=
IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 May 2020 06:09:04 +0200

> Getting trust in a local AS seems to be a bootstrapping problem.

If you only have one security domain, there is no benefit.
But in general is it much easier to bootstrap a device once into its own security domain, instead of having to do the bootstrapping again and again for each server that device needs to access.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 May 2020 11:47:32 -0400

Carsten Bormann <[email-masked]> wrote:
    >> I don't see how the four-corner model solves the issue that I
    >> highlighted.  If the client does not have a key for any local AS, then
    >> nothing helps.  The four-corner model deals with the issue of the
    >> client and the RS not trusting the same AS, but the different AS
    >> entities trust each other on the back side.
    >>

    > If you only have one security domain, there is no benefit.  But in
    > general is it much easier to bootstrap a device once into its own
    > security domain, instead of having to do the bootstrapping again and
    > again for each server that device needs to access.

That was my understanding.

The four corner removes the problem of how C trusts RS to a problem of how
does C ask CAS whether it can trust RS.  Which could involve significant
layers of PKI or human override (or pixie dust).