Security Considerations - Misuse of Registrar-Agent Credentials

[siethower]

Comment from Toerless to section 10

2821    10.3.  Misuse of Registrar-Agent Credentials   2823       Concerns of misusage of a registrar-agent with a valid 2824       LDevID(RegAgt), may be addressed by utilizing short-lived 2825       certificates (e.g., valid for a day) to authenticate the registrar- 2826       agent against the domain registrar.  The LDevID(RegAgt) certificate 2827       may be acquired by a prior BRSKI run for the registrar-agent, if an 2828       IDevID is available on registrar-agent.  Alternatively, the LDevID 2829       may be acquired by a service technician from the domain PKI system in 2830       an authenticated way.   These problems would be eliminated with the LDevID of the registrar-agent would as i suggested in part 1 of my review only be used for tracing on or behind the registrar which registrar-agent was forwarding messages, but not making any actual enrolment security decisions based on it. Which i tried to outline how.   2832       In addition it is required that the LDevID(RegAgt) certificate is 2833       valid for the complete bootstrapping phase.  This avoids that a 2834       registrar-agent could be misused to create arbitrary "agent-signed- 2835       data" objects to perform an authorized bootstrapping of a rogue 2836       pledge at a later point in time.  In this misuse "agent-signed-data" 2837       could be dated after the validity time of the LDevID(RegAgt) 2838       certificate, due to missing trusted timestamp in the registrar-agents 2839       signature.  To address this, the registrar SHOULD verify the 2840       certificate used to create the signature on "agent-signed-data". 2841       Furthermore the registrar also verifies the LDevID(RegAgt) 2842       certificate used in the TLS handshake with the registrar-agent.  If 2843       both certificates are verified successfully, the registrar-agent's 2844       signature can be considered as valid.   Same.

[stfries]

The registrar utilizes the agent-signed data for tracing which registrar-agent was in contact with the pledge and triggered the onboarding. With that it also traces, if the registrar-agent was authorized to perform the onboarding. Without that verification, arbitrary registrar-agents may submit pledge-voucher requests for pledges, which may not been intended for bootstrapping.

Proposal to keep text as is.

[siethower]

Fine, just some small changes in writing and consistent use: "agent-signed data" -> "agent-signed-data" "pledge-voucher requests " -> "pledge-voucher-request" "onboarding" -> "bootstrapping"

As already state by Steffen, it should be ok to keep the existing text in the draft.

[mcr]

"onboarding" -> "bootstrapping"

Even though the "B" in BRSKI is for bootstrapping, terminology consensus has moved on.

I'd like to keep Onboarding as being the name for the process we are doing. That "B" is really just two "O" together, trying to spell "O"nb"O"arding. Or maybe on"B"oarding.

[stfries]

Hm, we actually used the term "Bootstrapping" more in the context of the credential management, so establishing Trust and enrolling an LDevID. We used the term "Onboarding" to also include the configuration of application related information, which is actually the step after trust and credential establishment. This part is currently not covered by BRSKI, hence the proposal to use "bootstrapping".

[siethower]

I am also in favor of keeping the term "Bootstrapping" for BRSKI related tasks. As Steffen already stated in our terminology we are using "Bootstrapping" for the LDevID ceredentialing, on top of that there can be additional configuration or even application specific data. So we have: "Bootstrapping" + "Configuration" = "Onboarding"
(Note, the Configuration" can be optional, means in this special case: "Bootstrapping" == "Onboarding" )

[toerless]

.. This avoids that a 2834 registrar-agent could be misused to create arbitrary "agent-signed- 2835 data" objects to perform an authorized bootstrapping of a rogue 2836 pledge at a later point in time.

I think i do not understand what attack vectors a "rogue" or "unauthorized" registrar-agent may hav other than DoS attacks. I certainly do not understand how it could do what those lines 2834...2836 imply.

My thinking came from exactly that understanding: Other than mayb for tracing or logging, i do not care which agent is helping the pledge to get enrolled. This is similar to ACME, where certificates especially for renewal also can sit on the "whatever/who-cares" web server - because they're self-standing secure objects from a CA to a pledge.

[stfries]

Did not change the text in "Misuse of Registrar-Agent Credentials"

To answer Toerless' question, the misuse opportunity described in lines 2834 - 2836 came from the following scenario:

• (rogue) registrar-agent has certificate and creates arbitrary agent-signed data blobs with a much later validity date to be used later on
• if (rogue) registrar-agent certificate is revoked, these blobs would still be treated valid by the registrar as signed before the revocation and used later on

Note that with the allowance of short term certificates it is possible that the certificate used by the registrar-agent to authenticate to the registrar when providing the voucher response and the enrollment response may be different that the certificate used to sign the agent-signed-data blob. This can be the case, if the service technician collect the pledge response on day 1 and then his shift ends and he provides the information to the registrar the next day, with a new short term certificate.

May be closed