anima-wg / anima-brski-ae Goto Github PK

Here is a suggestion. Update/extend the existing text:

4.2.1. Pledge - Registrar Discovery
The discovery is done as specified in [RFC8995].

as follows:

4.2.1. Pledge - Registrar Discovery

The pledge discovers the registrar basically as specified in [RFC8995].
The pledge may already know or simply assume that
the discovered registrar supports BRSKI-AE with the certificate enrolment protocol its wants to use.
In case the pledge receives an error response on its enrolment request,
it may take this as an indication that the registrar does not support this
and then may decide to try some other variant or terminate the bootstrapping.

At the time of writing this specification, an extension to BRSKI [TDB informative reference to BRSKI-discovery]
was under development that aims to allow include in the discovery of the registrar
an optional list of capabilities it has, namely the BRSKI variants it supports
such as BRSKI-AE and related parameters such as CMP as the enrolment protocol.
If and when this extension is available, the pledge can make use of it to determine
beforehand whether the registrar supports BRSKI-AE with the wanted enrolment protocol.
This will be helpful to gain in advance a clear picture of the capabilities of the
discovered registrars and to choose, as far as possible, a matching enrolment protocol.
This way, trial and error regarding the capabilities of the registrar is avoided.

Proposal to include a signed statement (e.g., the pledge serial number) from the registrar-agent into the voucher request trigger to the pledge. This is in addition to the registrar certificate, which is also provided by the registrar-agent for inclusion into the pledge's voucher request. This requires another leaf in the voucher request (e.g. agent-signed-pledge-SN).

This allows the registrar in addition to the registrar-agent TLS authentication with the LDevID(RegAgt) to log the bootstrapping registrar-agent for a specific pledge. If the LDevID(RegAgt) is short lived (e.g., 24h) or a different registrar-agent is used for providing the pledge voucher-request to the registrar, a more detailed logging can be provided with information about the initial registrar-agent.

The call flow after discovery may perform as:

     +-------+                          +----------+   
     | Pledge|                          | Registrar|   
     |       |                          | Agent    |   
     |       |                          |          |   
     +-------+                          +----------+   
       |                                   |       
       |                                   | - sign pledge SN 
       |                                   |   with LDevID/Reg     
       |<- trigger pledge voucher-request -|       
       | (registrar-cert, signed pledge SN)|       
       |                                   |       
       |-------- Voucher-Request --------->| - store       
       | (w/nonce, reg-cert, signedSN )    |   voucher-request    
       |                                   |       
       |<--- trigger enrollment request ---|       
       |                                   |       
       |------- Enrollment-Request ------->| - store       
       |                                   |   enrollment request    

The registrar can log the signed pledge SN to be able to verify, which registrar-agent was used for bootstrapping, also in the case that the agent was changed during the process or the original agent certificate expired during the process. The signed SN could be another new leaf in the voucher, in addition to the agent-provided-registrar-certificate. The MASA would neglect this information.

For the Join Proxy, BRSKI-AE refers to Section 4 of RFC 8995. This section says:

This section is normative for uses with an ANIMA ACP. The use of the GRASP mechanism is part of the ACP. Other users of BRSKI will need to define an equivalent proxy mechanism and an equivalent mechanism to configure the proxy.

So it narrows the context down to only GRASP, and only for an ANIMA ACP. Is BRSKI-AE also targeting the same narrow scope?
If the scope is wider it would need to define the discovery mechanism(s) for the Join Proxy, explicitly.

It could re-use GRASP for example for a non-ACP context, but in that case it would still need to explicitly define this other context and say that/how GRASP is re-used. For other protocol use, like mDNS or DNS-SD, a detailed definition would be needed following the quoted RFC 8995 paragraph.

The document should put a reference against [RFC8366] after the first mentioning
of the word Voucher to justify the existing reference for RFC8366.

This is fine to be done when reveiving review request from AD (e.g.: don't fix before AD review).

In #9 we discussed to include agent-signed-data into the trigger and the pledge voucher request to address proximity between the registrar-agent and the pledge. This signed object is a JWS-object containing a reference to the utilized agent signing certificate.

The question is if this reference should be "x5t" containing the certificate hash or a "kid" containing the SubjectKeyIdentifier of the agent signing certificate.

Example:

{
    "alg": "ES256", 
    "x5t": "base64encodedvalue=="    //base64 encoded SHA-1 fingerprint of the registrar-agent signing certificate  
}
{
  "ietf-voucher-request-trigger:agent-signed-data": { // TBD: agent-signed-data in IETF BRSKI-AE draft
    "created-on": "2021-04-16T00:00:01.000Z",         
    "serial-number": "callee4711"                     // pledge product serial-number e.g. QR code or entered
  }
}
{
    SIGNATURE
}

Comment received:

During IETF/IESG review of what became RFC9262, we had a reviewer who did not like the
target name "Traffic Engineering for BIER" (because of ultimately not too shabby arguments),
so we had to have a re-naming contest in the WG and finally renamed it to "Tree Engineering".
Now, when i look at "Alternative Enrollment" protocols and read the text, even this abstract,
then i am thinking that a significant part of the text is about those protocols having to
support authenticate self-contained signed objects. Which does really not become clear
from the title and name "alternative". Alternative for example could also describe
a protocol which like EST does NOT meet the the requirements that this document
defines as MUST

Proposal from Toerless to rename to "Advantageous Enrollment Protocols in BRSKI" to better underline the advantages of using authenticated self-contained objects for enrollment.

I'd propose to do some house cleaning and remove the generated and outdated files from the repo.

As suggested by @toerless on Friday, I tried adding an image extracted from the presentation,
but cannot recall how I was supposed to do this.

When I add it as an image to the MarkDown source file like this:

![BRSKI-AE abstract protocol overview](BRSKI-AE_abstract_protocol_overview.png "BRSKI-AE abstract protocol overview")

then

 kdrfc --v3 draft-ietf-anima-brski-async-enroll.md

fails like this:

draft-ietf-anima-brski-async-enroll.xml(595): Error: Did not expect element xref there, at /rfc/middle/section[4]/section[2]/xref
draft-ietf-anima-brski-async-enroll.xml(595): Error: Element section has extra content: xref, at /rfc/middle/section[4]/section[2]/xref
/home/david/Siemens/proj/PKI/anima-brski-async-enroll-internal/draft-ietf-anima-brski-async-enroll.xml(15): Error: Invalid document before running preptool.
Unable to complete processing draft-ietf-anima-brski-async-enroll.xml

Does it make sense in such a way after all, or how else to add the image?

The LDevID issued by the registrar to the registrar-agent should be short-lived (on the order of a day to a week). Thus there is no need for long-term protection of the device.

New LDevID can be issued every morning if needed.

Also, for maintenance actions later on, that there is no requirement to use the same tool.
We want the technicians to be able to use whatever device they have available.

Security Considerations on lifetime of the Agent LDevID.

Do we need to provide for some application specific connection data to be returned through the registrar-agent to the pledge, to further configure it to the right network, and/or even to the right set of peer pledges?

It is proposed to assume an already available LDevID on the registrar-agent (former pledge-agent), as it is considered to be a site/domain component. This LDevID can be provided by a prior BRSKI run or by other means.
The registrar-agent uses this LDevID for (D)TLS client authentication at the protected registrar endpoints.

Rename YANG module for voucher-request from ietf-async-voucher-request to ietf-voucher-request-async

• to allow better listing of YANG modules for voucher related extensions,
• alignes with contraint voucher

The currently used terminology PULL and PUSH may lead to misunderstanding to which component the model actually applies. The term should clarify, that the pledge is either acting as a client or as a server.
Based on this it is proposed to rename:

• PULL mode to pledge-client mode (pledge initiates the bootstrapping)
• PUSH mode to pledge-server mode (pledge is waiting for being triggered for bootstrapping

Do we augment 8995? Do we augment 8366? Do we need to do both? What does it mean to augment something that augments something?

Should the agent-signed data in the trigger message from the registrar-agent to the pledge relate to a new module "ietf-voucher-request-trigger" or be part of the existing module "ietf-voucher-request" ?

{
"alg": "ES256",
"kid": "base64encodedvalue=="
}
{
"ietf-voucher-request-trigger:agent-signed-data": { // alternatively part of ietf-voucher-request:agent-signed-data
"created-on": "2021-04-16T00:00:01.000Z",
"serial-number": "callee4711"
}
}
{
SIGNATURE
}

Reasoning can be provided for both. As the agent-signed-data is also part of the pledge-voucher-request, it may be better to include it into the existing module.

I had to revert for now the change to aasvg, to avoid the following kramdown errors.
How to fix this?

    Traceback (most recent call last):
            17: from /usr/local/bin/kramdown-rfc2629:23:in `<main>'
            16: from /usr/local/bin/kramdown-rfc2629:23:in `load'
            15: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/bin/kramdown-rfc2629:3:in `<top >
            14: from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
            13: from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
            12: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc/command.rb:575:>
            11: from /var/lib/gems/2.7.0/gems/kramdown-2.4.0/lib/kramdown/document.rb:116:in `method_m>
            10: from /var/lib/gems/2.7.0/gems/kramdown-2.4.0/lib/kramdown/converter/base.rb:107:in `co>
             9: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:323:in `>
             8: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:328:in `>
             7: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:1400:in >
             6: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:340:in `>
             5: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:333:in `>
             4: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:333:in `>
             3: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:335:in `>
             2: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:619:in `>
             1: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:463:in `>
    /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:463:in `binread': No such>
            23: from /usr/local/bin/kramdown-rfc2629:23:in `<main>'
            22: from /usr/local/bin/kramdown-rfc2629:23:in `load'
            21: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/bin/kramdown-rfc2629:3:in `<top >
            20: from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
            19: from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
            18: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc/command.rb:575:>
            17: from /var/lib/gems/2.7.0/gems/kramdown-2.4.0/lib/kramdown/document.rb:116:in `method_m>
            16: from /var/lib/gems/2.7.0/gems/kramdown-2.4.0/lib/kramdown/converter/base.rb:107:in `co>
            15: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:323:in `>
            14: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:328:in `>
            13: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:1400:in >
            12: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:340:in `>
            11: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:333:in `>
            10: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:333:in `>
             9: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:335:in `>
             8: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:619:in `>
             7: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:462:in `>
             6: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:466:in `>
             5: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:466:in `>
             4: from /var/lib/gems/2.7.0/gems/kramdown-rfc2629-1.6.17/lib/kramdown-rfc2629.rb:517:in `>
             3: from /usr/lib/ruby/2.7.0/open3.rb:281:in `capture3'
             2: from /usr/lib/ruby/2.7.0/open3.rb:101:in `popen3'
             1: from /usr/lib/ruby/2.7.0/open3.rb:213:in `popen_run'
    /usr/lib/ruby/2.7.0/open3.rb:213:in `spawn': No such file or directory - aasvg (Errno::ENOENT)
    *** kramdown-rfc failed, status 1

Proposal to split the current BRSKI-AE draft to separate the contained use cases as they have developed differently.

• Use Case 1 targets the definition of requirements for a communication architecture using the existing BRSKI components and call model (pledge-initiator-mode, formerly PULL) to enable the use of alternative enrollment protocols for certificate enrollment (voucher handling untouched).

• Use Case 2 targets the specification of a reversed call model (pledge-responder-mode, formerly PUSH) in which the pledge has no or only limited connectivity to a registrar or cannot initiate requests to a registrar. To facilitate the interaction between pledge and registrar, the registrar-agent component is established. The interaction between pledge and registrar-agent results in new or enhanced data objects (voucher-request-trigger, voucher-request, voucher, enrollment-request-trigger, enrollment-request). Exchanges between registrar-agent and registrar follows BRSKI (RFC8995) and EST (RFC7030), with the enhanced objects.

Declaration of conformity to „AE“ is difficult, as the use cases have developed in different directions. Therefore the proposal to split the draft into two separate documents for use case 1 and use case 2. We may also discuss, what the target for each document would be (informational / standard RFC).

If the WG is in favor of the split, the expectation would be that the resulting document would proceed as WG documents.

<enrollment-protocol>: MUST reference the protocol being used, which MAY be CMP, CMC, SCEP, EST [[RFC7030](https://github.com/anima-wg/anima-brski-ae/issues/new#RFC7030)] as in BRSKI, or a newly defined approach.

I guess that EST RFC7030 already fits exactly into this pattern :-)
Are you proposing to standardize each of CMP, CMC (do we actually need both?), and also SCEP?
SCEP was published after great debate (and a 20 year..! delay).... EST was actually created to replace it, but inertia.

If you want /.well-known/cmc or /.well-known/cmp then IANA Considerations needs to say that.
Or perhaps that work is occuring in LAMPS, in which case we should reference it here.
If there is no present customer demanding SCEP, then we should leave that for future work rather than stir up the SecDir hornets nest.

The approach in draft -01 describes the trust between the pledge(-callee) and registrar-agent relation based on a PSK, which is used in a TLS connection establishment as kind of proximity assertion. The PSK may be provided using a QR code on the pledge(-callee). Intention was to address potential DoS attacks on the pledge.
After further discussion, the actual target for a potential DoS is most likely the registrar and not the pledge(-callee). The pledge is also assumed to be not in operation and providing services at this point in time.

It is proposed now to use plain HTTP for communication between pledge(-callee) and registrar-agent. The registrar-agent can also provide data to the pledge(-callee) to be included in the pledge voucher-request, this can be verified by the registrar and by the MASA. The provided data relates to the registrar certificate, which may be included in the pledge voucher-request as new leaf “agent-provided-registrar-certificate”.

The registrar-agent supplies the pledge voucher-request to the registrar. The registrar performs acceptance checks for pledge bootstrapping in its domain based on IDevID and maybe additional pledge voucher-request payload data as in BRSKI.
After registrar and MASA performed the verification of the voucher-request successfully, MASA creates a voucher to be returned to the pledge. If the pledge voucher-request contained a registrar certificate marked as “agent-provided-registrar-certificate”, existing voucher assertions "verified" or "logged" could be used, but not “proximity”.
May be a more direct indication of agent proximity would be to define a new assertion like “agent-proximity”.

As agreed on Friday during the IETF113 presentation,
I wanted to change the name of this repo from anima-brski-async-enroll to anima-brski-ae
but I do not have the necessary privileges and thus am am missing the "settings" menu item.
@mcr or @stfries, can you do?

In section 4.2, figure 3, the time sequence diagram has the steps 1,2, which does not fit into the BRSKI RFC8995 flow,
nor does it seem to fit into the PRM model of communications.
Specifically, the CA Certs Request/reply occurs after enrollment, I think, but I guess it just occurs after voucher response.
The Attribute Request/Response is I guess the same as the /csrattrs request.
The Certificate Confirm step seems fine.
Mostly, I am concerned that this is not synchronized with PRM's needs.

Current term used in BRSKI-AE for the component between the pledge(-callee) and the registrar is pledge-agent. This component is supporting the registrar and is considered to be a site/domain component with own LDevID credentials.
Therefore a terminology change to registrar-agent is proposed.

In order to prove proximity of the pledge-agent contained in the commissioning tool, the Registrar should provide a signed statement to the pledge-agent attesting to the agent acting on behalf of the Registrar. (This could be a TLS Certificate?)
The pledge should sign this artifact as part of it's voucher-request, such that the Registrar can validate it, and the MASA can pin to the correct Registrar.

Comment summary:

Remove of paragraph 624-629 regarding the discovery optimization in controlled environments requested. It is not seen as necessary as there is already a reference to the discovery document as such and an interim solution is already described in section 5.1. This should be sufficient enough. Providing statements about controlled environments here may rather lead to irritation.

Proposal from Toerless to justify the sage of agent-signed-data.

BRSKI-PRM enhances the enrollment message flow so that the registrar will
cryptographically know which registrar-agent was performing the BRSKI-PRM
message passing with the pledge. Network operations may choose not to be interested
in which registrar-agent performed this operation. In this case, BRSKI-PRM
achieves similar secure enrollment properties as BRSKI, with the difference, that this is
not achieved via a secure TLS connection but via forwarding of signed message
objects. On the other hand, if the registrar does choose to take the registrar-agent
information that is tracked by BRSKI-PRM into account, then this can provide additional security
validation that are not achievable in BRSKI through cryptographic means alone.

In one (likely common) example, the registrar-agent is an application on
some mobile device (notebook, tablet, phone) of a trusted installer person who first
verifies the presence and correct physical installation (location and any other
properties) of the pledge before initiating enrollment of the pledge via simple
clicks on the registrar-agent-appplication. Later, software on the registrar
can therefore take the execution of those physical installation steps as
granted because it can verify the identity of the installer/registrar-agent
through the BRSKI-PRM agent-signed-data. In contrast, with BRSKI no trusted
installer had to be on location (which often may be a benefit), but in return,
not only could many aspects of the installation be performed incorrectly and
there is no accountability who was responsible for verifying the installation,
but it would also easily possible for a pledge to be enrolled that was not
even physically present at the location of the BRSKI join-proxy network,
but instead the pledge could be in a remote attackers location and only
a remote layer 2 bridge would be at the target installation location.
While this attack by itself can not be excluded by the mechanisms of BRSKI-PRM alone,
the tracking of the registrar-agent allows to create more accountability for
verification of the physical installation.

In summary, BRSKI-PRM utilizes the need for support of nomadic network connectivity
of a pledge to also support identification of the registrar-agent that was
performing the enrollment and therefore allows to tie the cryptographic
BRSKI-PRM messaging to other workflows performed during installation as well as
allowing for accountability of the pledges installation.

Now since the line

 venue:

is followed by

-  group: anima
-  anima mail: {[email protected]}

I get

    *** attributes left {"group"=>"anima", "anima mail"=>{"[email protected]"=>nil}}!