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 protected]> On Behalf Of Peter van der Stok Sent: Tuesday, May 5, 2020 12:26 AM To: Benjamin Kaduk <[email protected]> Cc: Jim Schaad <[email protected]>; Olaf Bergmann <[email protected]>; 'Ace' <[email protected]> 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 <[email protected] <mailto:[email protected]> > 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
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
