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

[Stefan Winter <[e-mail]>]

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