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

From: "Panwei (William)" <[email-masked]>
Date: Mon, 11 Jan 2021 08:56:39 +0000

Hello,

I've read this draft and I agree with Stefan's opinions.

I feel the purpose of using the specific Service Type "Cert Login" is just to allow the SSH Server to indicate the Radius Server to use EAP-TLS. But with the EAP Nak response, the SSH Server can indicate the desired EAP methods it wants to use, and this is much more flexible than "Cert Login". So the valuable direction isn't to expand the Radius Service Type, but to allow to use EAP authentication in SSH.

Regards & Thanks!
Wei Pan

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Stefan
> Winter
> Sent: Thursday, November 19, 2020 3:49 PM
> To: [email-masked]
> Subject: Re: [OPSAWG] draft-vishwakarma-opsawg-ssh-cert-radius-00
> 
> 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