I didn't see the original notification go by, so I'll respond to Stefan's post. In short, I agree with Stefan. :)
Nits: Section 2.1, I suggest just deleting the mention of a particular product. Everyone knows what a RADIUS server is. The typical IETF draft doesn't mention _any_ product unless it's in the context of what it gets wrong (to fix) or right (to standardize) I'd echo Stefan's comments about just using EAP, instead of mentioning certificates. The benefits are even more than using certs, as EAP provides for many more kinds of authentication types. There should be much more detail on exactly how the EAP packets are transported in SSH, and how the SSH negotiation decides to use EAP. Finally, there should be a discussion of how certificates are managed on the SSH client. There will likely be need for a *separate* certificate store for use with SSH, as with 802.1X. There should be a hard requirement to not trust the default root CAs used for web traffic. Instead, each CA MUST be configured separately for use with SSH. The draft should also discuss how the client certificate is chosen. Section 3.2 has some text, but it is insufficient: The SSH client MUST choose a client certificate installed in the operating system as described in the section 2.1 Basic Setup. If there are multiple client certificates then the SSH client SHOULD choose a client certificate. If there is no certificate installed on the SSH client, then the client MAY choose another authentication methods defined in [RFC4251]. Except Section 2.1 does not say how to choose the client certificate. And the text above repeatedly says "choose", but doesn't say *how*. The document also needs to say how the *server* certificate is validated. The good news is that SSH can know the hostname of the server it's connecting to, unlike 802.1X. So all of the typical Web checks for "cert matches hostname" should apply. and should be discussed here. Which then means that the client certificate (if used) should be chosen based on the hostname being connected to: use the "user@hostname" field to find a matching client certificate. Then, verify that the server certificate comes from the same root CA, and that the server certificate CN field matches the hostname being connected to. I suggest referencing RFC 7542 (NAI) for a discussion of "user@hostname" issues. Over all, I think this proposal is useful. My team has struggled with the exact issues outlined here, when using SSH in a distributed environment. Being able to use EAP would significantly decrease deployment complexity. Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
