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

[Peter van der Stok <[e-mail]>]

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 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 <[e-mail]> On Behalf Of Peter van der Stok
> Sent: Tuesday, May 5, 2020 12:26 AM
> To: Benjamin Kaduk <[e-mail]>
> Cc: Jim Schaad <[e-mail]>; Olaf Bergmann <[e-mail]>; 'Ace' <[e-mail]>
> Subject: Re: [Ace] draft-ietf-ace-oauth-authz 
> 
> 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,
> 
> Peter van der Stok <[e-mail]> 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.
> 
> 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. 
> 
> 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.

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