Hi,
Just trying to check my understanding. In section 5.5.1 we have:
In
addition, the registrar-agent MUST know the product-serial-
number(s) of the pledge(s) to be bootstrapped. The registrar-
agent MAY be provided with the product-serial-number in different
ways:
- configured, e.g., as a list of pledges to be bootstrapped via
QR code scanning
- discovered by using standard approaches like mDNS as described
in Section 5.4.2
In 5.4.2 we have:
The registrar-agent MAY use
* "product-serial-number._brski-pledge._tcp.local", to discover a
specific pledge, e.g., when connected to a local network.
* "_brski-pledge._tcp.local" to get a list of pledges to be
bootstrapped.
So where does the list at "_brski-pledge._tcp.local" come from?
Is that configured in the same way as section 5.5.1 suggests, except
that it's configured into the host providing _brski-pledge._tcp.local?
In any case, isn't the list of pledges itself a point of attack
for someone attempting to install a rogue device? So the security
of the list of pledges should perhaps be discussed in the Security
Considerations, even though it's outside the protocol itself.
Regards
Brian Carpenter
On 09-Jul-22 03:21, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and
Approach WG of the IETF.
Title : BRSKI with Pledge in Responder Mode (BRSKI-PRM)
Authors : Steffen Fries
Thomas Werner
Eliot Lear
Michael C. Richardson
Filename : draft-ietf-anima-brski-prm-04.txt
Pages : 61
Date : 2022-07-08
Abstract:
This document defines enhancements to bootstrapping a remote secure
key infrastructure (BRSKI, [RFC8995]) to facilitate bootstrapping in
domains featuring no or only timely limited connectivity between a
pledge and the domain registrar. It specifically targets situations,
in which the interaction model changes from a pledge-initiator-mode,
as used in BRSKI, to a pledge-responder-mode as described in this
document. To support both, BRSKI-PRM introduces a new registrar-
agent component, which facilitates the communication between pledge
and registrar during the bootstrapping phase. For the establishment
of a trust relation between pledge and domain registrar, BRSKI-PRM
relies on the exchange of authenticated self-contained objects
(signature-wrapped objects). The defined approach is agnostic
regarding the utilized enrollment protocol, deployed by the domain
registrar to communicate with the Domain CA.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-prm/
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-prm-04
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-brski-prm-04
Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima