Hi. I'm not the secdir reviewer assigned to this draft, but felt that
this draft needed additional security review, so I decided to perform a
secdir-like review.
Overall, I think this is a much-needed specification and believe it is
mostly ready for publication as an experimental RFC. I'd say a bit more
clarity would be required if we wanted to move this to the standards
track.
General issues:
1) I'm reasonably sure that RADSEC MUST NOT be used with TLS versions
prior to 1.1. The concern I have is that RADSEC has long-lived TLS
connections under which an attacker could potentially observe ciphertext
generated from some plaintext before sending additional plaintext. TLS
1.1 includes explicit IVs that prevent various attacks that may happen
against earlier versions of TLS.
There are implementation work arounds that can also prevent these
attacks. However since all RADSEC implementations are required to
support TLS 1.1, I'd prefer to add a requirement that RADSEC
implementations MUST NOT negotiate TLS versions prior to 1.1 in order to
avoid this issue.
2) Section 2.3 implies that you need to do cert validation all the time,
even when you have a certificate fingerprint. I think it could more
clearly indicate that multiple ways of figuring out if you have the
right public key are provided. It's also not clear to me from section
2.3 whether there is a mandatory-to-implement strategy. You SHOULD
support cert fingerprints. You MUST support cert path validation, but is
there a required name form to support? There are discussions of several
name forms but none seem mandatory. I see no discussion of RFC 6125,
which I would have expected to see here. However, most of this is OK
for an experimental spec. This is the big area where I'd expect to see
more clarity before this could move to the standards track.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf