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, internet-dra...@ietf.org 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
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to