This draft is the result of a design team set up to suggest a solution for
the working group. I notice that we haven't discussed this in the last
meeting.
I think we should adopt this document. Any reason why we shouldn't?
I support this.
But I also think that document should be updated to solve one more problem.
Currently the choice of authentication methods is arbitrary - both peers may
choose
any method they consider appropriate. Unlike IKEv1 no negotiation is
possible.
This is not a problem if any peer has only one private key, but if one peer
has
several keys for different algorithms, while the other supports only subset
of this
algorithms, they may run into trouble. The problem is that currently peer
cannot
advertise which signature algorithms it supports. The world was simple when
almost everyone used RSA, but currently there are plenty on signature
algorithms available,
and the situation I described is not uncommon. Even if it looks strange to
have
multiple keys for everyday use in single VPN, consider the situation when
all hosts in the VPN need to change signature algorithms (for any reason,
whether
the old was broken, or just became obsoleted by some authorities).
This cannot be done at once, so in transition period some hosts will
have both private keys. In some situations peer may deduce which key to use
by analyzing Certificate Request, but in general this is unreliable, as
this payload is optional and one CA may sign both keys.
Currently the draft allows peers to advertise the list of hash functions
they support.
I'd sujjest to update the draft to include ability for peer to also
advertise the list of signature
algorithms it supports.
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
