Subject: Re: [OPSAWG] draft-vishwakarma-opsawg-ssh-cert-radius-00

From: Stefan Winter <[email-masked]>
Date: Thu, 19 Nov 2020 08:48:35 +0100

Hello!

Thanks for this submission.

First of all, I like this idea a lot! Being able to centralise SSH
access decisions to a centralised server can make management of large
fleets of SSH-enabled servers easier. I would look forward to deploy
this myself in our environment if it were to exist.

That said, I have to say that the draft remains too vague in many
aspects yet, while it is overly verbose in others.

It would help to frame the text along existing standards: in essence,
what you are suggesting is the exact analog to 802.1X authentication -
the SSH client is in the equivalent role to an EAP supplicant (EAP
peer), the SSH server takes the role of the pass-through authenticator,
and the RADIUS server is the RADIUS server (in union with the EAP server).

When looking at the packet flows with that in mind, one can see how the
narrative should be, and where the points to elaborate on are.

EAP content needs to flow from the EAP peer (SSH Client) to the
authenticator (SSH Server) (protocol: ?), be re-encapsulated by the
authenticator for transmission towards the EAP server (protocol: RADIUS).

You did not mention which protocol would be on the hop EAP peer to
authenticator. I imagine it is the SSH Transport Protocol. In that case,
you need to be more precise on how the EAP content is encapsulated in
the SSH TP PDUs.

By making SSH TP a transport for EAP,  it becomes an "EAP lower layer".
There are requirements to EAP lower layer protocols, see RFC3748,
section 3. Your draft should explain how SSH TP satisfies those
requirements. Text analogous to "EAP Usage Within ..." of that same
section 3 of RFC3748 would be good.

Once this is cleared, we can see where your draft is unnecessarily
limiting its own usefulness: you are limiting yourself to
certificate-based authentication with EAP-TLS. EAP itself has a method
negotiation and the EAP server can enforce that EAP-TLS is the only
supported EAP type for authentication *if it so wants*. An EAP server
could also support tunneled password-based EAP methods, which means your
draft could also achieve authenticating SSH logins using a
username/password with encrypted transmission of the password from SSH
client to the EAP server. You should maybe not lobotimize EAP with the
arbitrary limitation to "Cert Login" service type - the EAP type to use
is a policy decision by the deployment, so let it be that.

It is not necessary to re-iterate the packet format of RADIUS in your
section 4.2 and 4.3. Everyone can read RFC2865 and see those same diagrams.

If you are willing to lift the arbitrary restriction that your draft
only allows certificate login, in place of letting EAP do its method
negotiation job, you actually do not need a new Service-Type at all.
"Login" will then do just fine. This would make your entire section 4
moot, and you could do without touching RADIUS specs.

Once the draft establishes that this is an entirely normal EAP
authentication, with SSH TP as the EAP lower layer and RADIUS as the
auth server transport protocol, much of your section 3.3's long sequence
of packet exchanges can be reduced to the single sentence: "... and
then  EAP authentication (as per RFC3748) happens over those channels."

Finally, the Security Considerations falls short of what needs to be
discussed. EAP authentication with a pass-through authenticator suffers
from possible attacks due to the lack of channel binding. The need for
channel binding when using EAP for other uses besides its original scope
of network access authentication was discussed extensively during the
developments in the abfab working group (where EAP is used with a
different EAP lower layer, GSSAPI, and also for non-network-access
purposes). You should thoroughly read RFC7057 which makes clear that EAP
peers MUST use channel binding in non-network access scenarios.

I hope this provides you with some good starting points and food for
thought for a future rev.

Greetings,

Stefan Winter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 19 Nov 2020 09:25:38 -0500

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.