Deb Cooley via Datatracker <nore...@ietf.org> wrote:
> Section 7.3, para 2: Pick one: either 'mutual authentication' or 'client
> authentication'. If you pick 'mutual authentication', then in sentence
2, it
> could be 'mTLS uses....' [one should do a global search, there are a
bunch of
> 'client authentication' instances throughout the draft]
I don't understand your comment.
Mutual Authentication = Server Authentication + Client Authentication.
In section 7.3, paragraph we are explaining that the client authentication
uses a different kind of key.
> Section 7.3, para 3: Is this suggesting that the registrar only needs to
> verify the Registrar-Agent's connection if it doesn't already have the
> Registrar-Agent's EE certificate? seems odd....and possibly insecure.
Typically, the Registrar Agent's EE certificate is issued by the Registrar.
I can't see what the exception for the SHOULD in this paragraph is though.
I agree that paragraph needs rework.
> Section 12.1: Is there a resource exhaustion DOS attack on the Pledge?
A pledge that can maintain only n-outstanding voucher-requests could
be DoS by n+1 attackers. Each voucher-request contains a nonce which if just
randomly generated would need to be remembered somehow for a time.
A pledge could also attempt to make the nonce stateless by encrypting/signing
something it doesn't have to remember. There are many ways to deal with
this, which is why SC raises it.
> Section 6.1 and 12.3: Doesn't frequent rekey of the Registrar-Agent lead
to
> synchronization issues with the Registrar? How is this mitigated?
The new EE key is issues by the Registrar, but maybe you are asking about the
key that would be in the agent-signed-data. Whatever the rekey interval, the
Agent should not rekey while it has undischarged voucher-requests.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
