> From: Michael Richardson <[email protected]> wrote: > > Sorry for the late response. > >> We have struggled with brski-ae to deal with how the pledge can pin a > >> thing from the pledge-agent to prove proximity. > > > Based on some further discussion, we have to decide, how the proximity > > is handled in BRSKI-AE. The motivation for now was to have it to avoid > > DoS attacks on the pledge. > > Understood. > Christian Amsuss has done some work with CoAP over the websocket version of > BTLE/NFC (Please correct me here). The idea being that we could do EDHOC or > some such over that link. That wouldn't be an IPv6 link. > > A reason for this interest is that this interface is available to one-page > WEB apps > on a smartphone via Javascript, while mucking around with IPv6 over BTLE or > changing wifi access points is a serious pain on smartphones. > > This provides a fair bit of physical proximity, which I think can mitigate > the DOS > attack concern. Really, we need to do some experiments here with some kind > of spike solution. > > EDHOC, running over CoAP, should be relatively happy with the store-and- > forward mechanism that BRSKI-AE would like. Wouldn't this still require that the pledge is able to verify the certificate of the pledge-agent during the first contact? The pledge authentication at the pledge-agent is probably easier, if we assume the pledge-agent knows the signing certificate of the pledge manufacturer. We run into a similar issue with the discussion when using TLS. The pledge (acting as server in PUSH) itself does not have a certificate the has the correct subjectAltName (and the key usages) to perform the verification on the pledge-agent side. Also, the Pledge would not be able to authenticate the pledge-agent until it receives the voucher.
> > > If we assume that the likelihood for DoS > > attacks is higher on the registrar side, it is important to protect the > > registrars endpoints. > > I think that we can handle attacks on this side. Yes, that is why we though to utilize the same endpoints (via https) > >> It feels that something like either Delegated STAR could work well. > >> Or, if not that, and we are using TLS, then draft-ietf-tls-subcerts-10 > >> Failing that, we need to create some kind of JWT, or CWT artifact > >> which the Registrar uses to bless the pledge-agent. > > > Currently, the proposal would be to utilize an LDevID between the > > pledge-agent and the registrar. It can be provided either by a separate > > BRSKI run to the pledge-agent or manually. > > Agreed, that's what I had in mind as well. > > > connecting or a pledge-agent based on the utilized certificate (IDevID > > or LDevID). I would like to discuss the trust relations in the next > > design team meeting. > > Awesome! > > >> I find the PULL/PUSH terminology confusing. I recognize that the > >> directionality that is implied by the PULL/PUSH is based upon, I > >> thought, whether the RFC8366 voucher is retrieved by the pledge, or > >> provided to the pledge. But, in section 5.1, I think that it's called > >> PULL because the communication with the RA? > > > The naming PULL and PUSH was motivated by the pledge behavior, that it > > either PULLs information from the registrar or that it is pushed with > > the information from the pledge-agent. From a naming perspective we > > already introduced some further names like pledge(-callee) in the PUSH > > case, as the pledge is acting as a server while in the PULL case the > > pledge acts as a client. So one option would be to state pledge-client > > (UC1) and pledge-server (UC2). Would you have further suggestions for a > > naming? We could also discuss this in the next design team meeting. > > I suggest we refer to it as "pledge-initiated onboarding" (PULL), or > "registrar (or > pledge-agent) initiated onboarding". A further alternative may be pledge-client or pledge server. > Also, it is a Pledge-Agent, or is it really a Registrar-Agent? > > (In real-estate: we have seller's agent or buyer's agent...) Yes, this is some point I already put on the slides to have a change in terminology. We discussed this and the agent is actually acting rather as a registrar agent, specifically in the case were it has an LDevID. Best regards Steffen > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
