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

[Kent Watsen <[e-mail]>]

Hi Michal,



>> In ietf.-ssh-client: should "leaf-list submethods” or "leaf-list oids” be ordered-by user?
> 
> Right, yes, I believe so.

Fixed.


>> RELATED:  In iets-ssh-server: should any of “list submethod, “list prompt”, or "list gssapi-with-mic” be ordered-by user?
> 
> Reading through the RFCs again, I think all of these lists should actually be user-ordered, I missed that before. Moreover, if "list submethod" is user-ordered, the default submethod should simply be the first one and you can remove the "leaf default-submethod".

All done.  Now the description on "list submethod” says:

               "All the submethods supported for the user.
                If the user does not request any specific
                submethod, the first one will be used."



>>> But, our NETCONF library does provide some additional configuration of the client SSH authentication so I will mention it and leave for you whether you want to add it into the modules or not. We support customizing the priority of each method so that there are no 'wasted' methods that only increase the authentication attempts. It seems that this is prevented in the SSH client module by all the "if-feature" on the individual methods, so that the unsupported ones can be disabled. But I think it may be useful for the client to be able to configure its preferred methods, in order, because you probably do not want to be bothered with the "password" authentication when you have a public key configured, for instance.
>> 
>> 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."




>>>> On #3, this is likely mostly for me to resolve, but it seems to me that *all* client-auth details should be under the “user” node.  Yes, a bag-of-certs (or a single CA cert) could be used to auth a multiplicity of users, but having that reference configured per user (perhaps redundantly) is 1) more consistent and 2) better supports the server being able to produce a list of “productive method names” to return to the client.  Thoughts?
>>>> 
>>>> Separately, for background, I mentioned before that X.509-cert auth is a variation of the “publickey” authentication method.  RFC 4253, Section 6.6 clearly indicates this, as it consistently says "certificate or public key”, and RFC 6187, Section-2.1 likewise supports this.  So, we could push the whole “how to support X.509 formatted keys” into/under the “publickey” umbrella.   That said, it is way more natural for administrators to configure certs in their normal form then in the ssh-publickey form, hence why the ssh-client and ssh-server models have them broken out as they are.
>>> 
>>> But you do need to configure the public key for the user if you want to authenticate it by a certificate, right? Assuming so, I think it is fine the way it is but I do agree with your points and see no problems with the change you proposed, either way seems fine.
>> 
>> 
>> If in your first question you mean an “X.509-based publickey”, then yes, but...
>> 
>> - if auth happens via an "ee-cert”, the ee-cert for each user needs to be configured, but it’s open as to if each user points to a specific ee-cert or if all users point to a bag of ee-certs.
>> 
>> - if auth happens via “ca-cert”, the same statements apply, but there is even less affinity, as typically a CA issues many EEs.
> 
> Yes, I understand, but I have too little experience with certificates and practical use-cases so I am not able to decide whether the certificate configuration can be only per-server or needs to be per-user.

This is why I wrote before that it would likely be up to me to resolve  ;)

I think I’ll sleep on it, maybe insight will come in the morning...



>>>>>>>> BTW, this introduces an issue as to if “client-identity-mappings” are required for SSH when certs are used, or if the SSH username that is built into the protocol (and used in al non-cert scenarios) should take precedence. Thoughts?
>>>>>>> 
>>>>>>> I have never configured or used certificates for SSH authentication so this is not a question that I can answer. But based on my other experience, I would naively guess that it means you are using certificates instead of SSH keys, which seems to me is relevant for the "hostbased" and "publickey" authentication methods and would, in-effect, replace the configuration of these methods. But that is not what is found in these YANG modules so I guess I am wrong.
>>>>>> 
>>>>>> X.509-based auth *is* a variation of “publickey” auth, so a “username” is still being passed in the SSH_MSG_USERAUTH_REQUEST message...
>>>>> 
>>>>> Right, it takes me some time to absorb all the implications. So what exactly is the purpose of "client-identity-mappings" for SSH? A client must always present its username when authenticating using SSH and it can be chosen so I do not see the point of changing the NETCONF session username based on the presented certificate and the cert-to-name mapping configuration. Am I missing something?
>>>>> 
>>>>> Actually, maybe I can think of a scenario. Supposing there are some NETCONF clients deployed that use SSH for authentication but want to identify users based on their certificates. Then there could be a single username always used for SSH authentication but the NETCONF client would map the specific certificate to a NETCONF username. That would allow the server, for example, to still implement NACM but effectively identify users only based on their certificates.
>>>>> 
>>>>> In this case your original question makes sense to me and I would see 2 solutions. Either there would have to be the expected SSH username configured in order for all the associated cert-to-name mappings to take effect or simply all the configured mappings would always be tried and if some is successful, the resolved username will always be used for NETCONF. I suppose a combination of this is also possible when the expected SSH username may or may not be configured.
>>>> 
>>>> 
>>>> Digging into RFC 6187 again, I find this jewel:
>>>> 
>>>> For the purposes of user authentication, the mapping between
>>>> certificates and user names is left as an implementation and
>>>> configuration issue for implementers and system administrators.
>>>> 
>>>> This is wild as is simultaneously suggests that a mapping (i.e. x509c2n:cert-to-name) may be needed while ignoring the fact that the “user name” is already being passed in the base SSH_MSG_USERAUTH_REQUEST message.
>>>> 
>>>> Popping this discussion back up to YANG models, ietf-netconf-server current has this snippet:
>>>> 
>>>>        container netconf-server-parameters {
>>>>          description
>>>>            "A wrapper around the NETCONF server parameters
>>>>             to avoid name collisions.";
>>>>          uses ncs:netconf-server-grouping {
>>>>            refine "client-identity-mappings" {
>>>>              if-feature "sshcmn:ssh-x509-certs";
>>>>              description
>>>>                "Augments in an 'if-feature' statement
>>>>                 ensuring the 'client-identity-mappings'
>>>>                 descendent is enabled only when SSH
>>>>                 supports X.509 certificates.";
>>>>            } // FIXME: does an X.509-derived identity
>>>>          }   //        override SSH username?
>>>>        }
>>>> 
>>>> The questions are:
>>>> 
>>>> 1) are "client-identity-mappings” needed at all?
>>>> 2) if “yes”, then do they override the base “user name” value?
>>>> 
>>>> For #1, I think you’re saying that flexibility is good and, for #2, RFC 6187 seems to be saying that it’s a matter of local policy.  Agreed?
>>> 
>>> 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*


K.