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

[Kent Watsen <[e-mail]>]

Hi Michal,

> starting with the issue of the exact purpose of all these modules, I may have misunderstood. It seemed to me they are meant to fully configure an SSH server/client, NETCONF server/client, ... With the limitation of leaving out some rare or too complex use-cases up to augments. At least that is what I was trying to help you with, but these criteria are subjective, of course.

I’d say “fully configure, within reason.”


1) Easy: TCP and TLS

    These are easy because they don't ever entail interacting with user databases.


2) Moderate: SSH (password, publickey, hostbased, none) and HTTP (basic, digest)

    These are moderate because there’s a potential for callouts to remote user databases and, if so, then we don’t have the model to define how to do those callout yet.   However, a simple/built-in user-database is straightforward to configure.  [caveat: some SSH servers (e.g., sshd) enable a multiplicity of these mechanisms (e.g., first publickey, then password), which we don’t have an answer for yet.]

<aside> The “http" draft originally modeled a number of HTTP auth methods.  In an early review, the HTTPBIS working group beat-up that approach, so we backed-off to having an “auth-type” choice node with just a single “basic” case statement, thus enabling consuming models to augment-in any other auth mechanism config desired. </aside>


3) Not Easy: SSH and HTTP, the other auth mechanisms.

    These are not easy because they seem to require callouts to app-logic in order to be useful in a production environment.  Assuming static/canned responses are okay, it might be okay to enable these auth mechanisms (via their features) for, e.g., unit-testing purposes.



> Still, I think we are pretty close now, from my perspective. As was discussed, the "keyboard-interactive" method is a completely generic one where the user is presented with a set of challenges and must correctly respond to them to pass the authentication. That should already work and the issue I was trying to solve is a security one, when the expected response is some sensitive information. Adding that, I think the configuration would be able to (safely) express all configurations that do not require any additional information (such as, I don't know, retrieving the expected response from some remote server). Incidentally, the expected response of the user password would also be supported.

The problem with the current keyboard-interactive model is that each “response” is effectively a password, even if it’s not a password, in that it is the magic answer that the client needs to provide.  

Thus, all the responses SHOULD be, e.g., hashed, so that the value that needs to be provided isn’t in the clear.  In this sense, we could use the iana:crypt-hash type for the “response” node, pushing it to the administrator to configure the hashed values.

That said, if we’re leaning towards static/canned “keyboard-interactive” config being sold for, e.g., unit-testing, it would be easier on the administrator to leave the values in the clear.


>>>> The ssh_config manage has:
>>>> 
>>>>   PreferredAuthentications
>>>>           Specifies the order in which the client should try authentication methods.  This allows a client to prefer one
>>>>           method (e.g. keyboard-interactive) over another method (e.g. password).  The default is:
>>>> 
>>>>                 gssapi-with-mic,hostbased,publickey,
>>>>                 keyboard-interactive,password
>>>> 
>>>> We could support this either by:
>>>> 
>>>> 1) wrap everything inside an “ordered-by user” list
>>>> 
>>>> 2) define a “PreferredAuthentications” like variable, to provide an external ordering
>>>> 
>>>> Thoughts?
>>> 
>>> This is probably just a YANG modeling issue. I was already thinking about 1) and it seems to me it would make for a nice configuration data, but the YANG itself would be cluttered. Nevertheless, there may be a clean solution I am missing so it is up to you. We have simply assigned a priority to each authentication method, but I am not saying that is ideal.
>> 
>> #1 seems better at first but, assuming the list is called “authentication-method”, the immediate issue is what the “key” should be.  We’d have to introduce a somewhat artificial “name” node, which makes the approach less appealing.
>> 
>> #2 seems easy enough:
>> 
>>   leaf-list preferred-authentications {
>>     type enumeration {
>>       enum publickey { ... }
>>       enum password { ... }
>>       enum hostbased { ... }
>>       ...
>>     }
>> 
>> But new “enums” cannot be augmented into an “enumeration” (in case that is ever desired).  We could use “type string”, but that's too open.  Another option would be to define a hierarchy of identities and then have a leaf-list of identityrefs.  This could work, but...
>> 
>> Now I’m thinking to leave the order unspecified, since it’s a minor optimization (saving a round-trip), as the “none” option can be used to get a “productive methods” list from the server.
>> 
>> You said that you’d did this optimization before, but did it really matter, to save one roundtrip, especially in the context of using the keyboard-interactive method?
>> 
>> How about this for the the “client-identity” node’s description?
>> 
>>      "The credentials are unordered.  Clients may initially send
>>        any configured method or, per RFC 4252, Section 5.2, send
>>        the 'none' method to prompt the server to provide a list
>>        of productive methods."
> 
> Like I said, the best example of a problem we were solving with these priorities was that when your SSH client has both "publickey" and "password" authentications supported and working and you connect to an SSH server that supports the "publickey" authentication, it is probably the method you prefer. I may be missing something but how do you solve this problem without some way of expressing these priorities explicitly? I do not see how getting the supported methods from the server will help you, it is strictly up to the client which of the methods it will select next (first).

I understand you’re trying to enable the client to know exactly the right auth mechanism to use first.  My last response was, effectively, “let’s NOT solve that problem, because it’s a minor optimization, saving just one round-trip."

My question before was (and still is), since you did this optimization before, did it really matter (to save that roundtrip), especially in the context of using the (very slow) keyboard-interactive method?



>>>>> For #1 I came up with a possible scenario when the "client-identity-mappings" could possibly have their use. If the scenario is unlikely to be used in practice or simply not relevant for some reason and you (or anyone else) are not able to come up with any other, I think these mappings are not needed. Just a note, we do not and not plan to support the scenario.
>>>> 
>>>> Ack, and we shouldn't support a low-probability use-case.
>>>> 
>>>> 
>>>>> As for #2, I think I have suggested a way to allow configuring it either way so that the 'local policy' can be directly configured. And that would probably be the best solution.
>>>> 
>>>> I think what you are saying is:
>>>> 
>>>> 1) if a cert-to-name mapping is NOT found, then fallback to the SSH-level username
>>>> 
>>>> 2) if a cert-to-name mapping IS found, then it SHOULD override the SSH-level username.
>>> 
>>> If you decide to keep this mappings, I was suggesting a completely generic solution when you could configure a specific username for the cert-to-name mappings.
>>> 
>>> 1) If the user name is configured and
>>> a) matches the SSH user name, you try to use the mapping and override the SSH user name.
>>> b) does not match the SSH user name, you ignore this mapping.
>> 
>>> 2) If the user name is not configured, you always try to use the mapping.
>>> 
>>> But there is still the question of what to do if you find no matching mapping. I suppose it could be a separate configuration leaf deciding whether you want to fall back on the SSH user name or fail the authentication altogether.
>> 
>> Added that mappings override the SSH-level username.
>> 
>> Added a separate configuration leaf for if a mapping is *required*
> 
> So you have decided to keep it? In any case, its functionality should now be unambiguous.

Yes, and yes.


K.