Thanks Deb for your DISCUSS item.
I'm not sure to understand exactly in which direction(s) your concern
was meant.
I've meanwhile had an exchange with my co-authors, who provided part of
this response.
1. Is the concern about the pledge having the right trust anchor(s) to
use also in the cert enrollment phase?
If so, then Michael's response goes in the right direction,
and this topic is essentially already addressed in the introduction
as follows:
* The pledge first obtains via the voucher [RFC8366] exchange a
trust anchor for authenticating entities in the domain such as the
domain registrar.
Note that this is a general statement that holds for any enrollment
protocol used, including CMP.
2. Please note that in BRSKI-AE we do take over the use of the (d)TLS
channel
already established in the core BRSKI phase for all enrollment
protocols, including CMP.
This is already written at the end of section 4.1:
For transporting the certificate enrollment request and response
messages, the (D)TLS channel established between pledge and
registrar is MANDATORY to use.
Therefore, like with EST, no other party can interfere between the
pledge and the registrar,
also during the enrollment protocol phase of any other enrollment
protocol like CMP.
3. Is the concern about the authentication of the RA/CA servers at CMP
level?
This boils down to the protection of the CMP response messages,
which - as usual with CMP - is independent of any transfer-level
security
because the CMP-internal (message-level) protection is entirely
sufficient -
in other words, CMP messages are self-contained also from the
security perspective.
What we can still point out more clearly is that the basis for
authenticating the
CMP server side is the already mentioned trust anchor established at
BRSKI level.
To make these points more explicit for the CMP case and to more clearly
address the concern(s),
we are going to add as the first item of list of specific requirements
in section 5.1, i.e., just after
When using CMP, adherence to the LCMPP [RFC9483] is REQUIRED.
In particular, the following specific requirements apply (cf. Figure 2).
the following text:
* The validation of server response messages performed by the CMP
client within the pledge MUST
be based on the trust anchor established beforehand via the BRSKI
voucher, i.e., on the pinned-domain-cert.
Note that the integrity and authenticity checks on the RA/CA by the
CMP client can be stronger than for EST
because they do not need to be performed hop-by-hop, but are usually
end-to-end.
Does this sufficiently address the below DISCUSS item?
David
On 02.09.24 15:17, Michael Richardson wrote:
Deb Cooley via Datatracker<[email protected]> wrote:
> While this draft clearly outlines the requirements for proof of
possession and
> integrity/authentication of the pledge, I did not see any discussion on
> integrity/authentication of the RA/CA. How can the pledge determine if
it is
> requesting certificates (either its own or CA) from the proper RA/CA?
One of
> the advantages of EST is that the pledge can verify the EST server
certificate,
> and an on-path attack is harder when there is an adequate TLS session.
Is that
> the case with CMP (or SCEP)? If so, either point me to where that is
> documented or add a couple of sentences on how that is done. If not,
please
> add a section to the Security Considerations.
Hi, you are asking a BRSKI question, which is a super-set of EST.
This is all in RFC8995, section 5, especially section 5.6.2.
The short answer is that the RFC8366 voucher pins the RA/CAs' key.
For CMP, the process is similiar. A TLS or DTLS is still created,
but when it comes to enrollment, EST is not used.
I wonder if including the vouchers in figure 2 would help?
brski.org contains a bunch of slides, and some videos of a few presentations
on BRSKI.https://brski.org/brski-impls.html
_Generic Animation of BRSKI - Bootstrapping Remote Secure Key Infrastructure_
https://www.youtube.com/watch?v=Mtbh_GN0Ce4
is something I put together specifically to answer this question.
It's only 5 minutes. Watchable at 1.5X too.
--
Michael Richardson<[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
On 02.09.24 13:13, Deb Cooley via Datatracker wrote:
Deb Cooley has entered the following ballot position for
draft-ietf-anima-brski-ae-12: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer tohttps://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
While this draft clearly outlines the requirements for proof of possession and
integrity/authentication of the pledge, I did not see any discussion on
integrity/authentication of the RA/CA. How can the pledge determine if it is
requesting certificates (either its own or CA) from the proper RA/CA? One of
the advantages of EST is that the pledge can verify the EST server certificate,
and an on-path attack is harder when there is an adequate TLS session. Is that
the case with CMP (or SCEP)? If so, either point me to where that is
documented or add a couple of sentences on how that is done. If not, please
add a section to the Security Considerations.
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
