Re: [netconf] Latest ietf-netconf-server draft and related modules

[Kent Watsen <[e-mail]>]

Hi Juergen,


>>> a) Is the issue that there is no support for keyboard-interactive in
>>>  the SSH model?
>> 
>> There is now per this commit: https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b25c0c4c518379accffcf0 <https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b25c0c4c518379accffcf0>
>> 
> 
> To me this makes little sense, you are not done by statically
> configuring challenges and responses, this is from my view really
> missing the point of keyboard interactive. I am sure you can write
> a PAM module that does that but the value of keyboard is not this
> kind of trivial configuration.
> 
> My point is that if we model keyboard-interactive, we have to get it
> right, which is complex. Hence my suggestion is to not model it at this
> point in time.


I tend to agree.  While I also agree with Michal that the “keyboard-interactive” model reflects RFC 4252, it doesn’t seem practical in a production environment to have canned prompts/responses beyond, e.g., developing unit tests.

Take, for instance, the two examples in https://tools.ietf.org/html/rfc4256#section-4.  

The first example attempts to authenticate a crypto card, presumably by getting it to perform a private-key operation over the “challenge”.   However, in a production environment, the challenge would have to a random value each time (i.e., a nonce) as, otherwise it’s susceptible to a replay attack.

The second example reflects the case of an expiring password and the need to generate a new one.  First, passwords don’t expire *all* the time, so having static config doesn’t make sense.  Second, there’s no way to predict the new password value, and hence the “response” could not be configured.  Third, in order to apply the password-change, app-logic (e.g., a callout) would be need (e.g., to update a user database entry).

Michal, you said that you used “keyboard-interactive” before.  Can you please provide a concrete example?  Hopefully something beyond just prompting for a password, which I contend SHOULD use the “password” auth method instead...


> I also stumbled over
> 
> 	"A list of locally configured users (i.e., SSH clients).";
> 
> For me, an SSH client and a locally configured user are very different
> things. For me, the SSH client is the piece of code running on the
> client side, the user is an account on the remote system.

Yes, they are different things.


>>> b) Is the issue that there is no support for non-local user databases
>>>  for SSH and HTTP authentication?
>> 
>> If we think that is important, yes.  The current “solution” for non-local user databases is 1) don’t enable "client-auth-config-supported” and 2) augment-in what is needed for the application…and maybe 3) only use TLS, where the truststore/keystore + cert-to-name obviate the need for a user database.
>> 
> 
> Well, you can configure SSH user authentication mechanism to reach out
> to RADIUS or Kerberos or Diameter or ... RFC 7317 does support the
> RADIUS backend option. Having to augment in new trees to support lets
> say RADIUS is somewhat expensive. (I _assume_ you can call out to
> RADIUS from the SSH password authentication method, i.e., this may not
> require to have keyboard-interactive.) But perhaps also this can be
> dealt with once there is more implementation experience.

Exactly what is likely needed for a production environment.  RFC 7317 includes RADIUS-client config, which we could embrace and extend (to support other mechanisms, e.g., LDAP, PAM, etc.), but this gets into the “more complicated than I want for now” teritory.  

My thinking, again, is to:

    1) enable "static user auth” to define a simple/built-in user database with static/canned auth configs.

    2) enable the “static user auth” tree to be disabled, so better (production-grade) mechanisms can be augmented-in.



K.