Re: [netconf] client identification in ietf-netconf-server

[Kent Watsen <[e-mail]>]

> On Nov 14, 2019, at 2:51 AM, Martin Bjorklund <[e-mail]> wrote:
> 
> Kent Watsen <[e-mail]> wrote:
>> Hi Martin,
>> 
>> 
>>> Martin Bjorklund <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> Kent Watsen <[e-mail]> wrote:
>>>> 
>>>> Hi Martin,
>>>> 
>>>> [Not trimming down because too much context would be lost.]
>>>> 
>>>> 
>>>>>>> The ietf-netconf-server module has this:
>>>>>>> 
>>>>>>> grouping netconf-server-grouping {
>>>>>>> ...
>>>>>>> container client-identification {
>>>>>>>   ...
>>>>>>>   container cert-maps {
>>>>>>>     when "../../../../tls";
>>>>>>>     uses x509c2n:cert-to-name;
>>>>>>>     ...
>>>>>>>   }
>>>>>>> }
>>>>>>> }
>>>>>>> 
>>>>>>> Note the "when" expression.  This means that the grouping has a strong
>>>>>>> depency on where is it used.  We should try to avoid such a design.
>>>>>> 
>>>>>> 
>>>>>> Would this be better?   
>>>>>> 
>>>>>> OLD
>>>>>>     when "../../../../tls";
>>>>>> 
>>>>>> NEW
>>>>>> 	if-feature "tls-listen or tls-call-home";
>>>>> 
>>>>> Yes, but see below.
>>>>> 
>>>>> 
>>>>>>> But should't this cert-to-name list be available when x509-certs are
>>>>>>> used also with SSH?
>>>>>> 
>>>>>> Hmmm.  I'd assumed that, with RFC 6187, the username was still passed
>>>>>> as its own field, but I see this in Section 4:
>>>>>> 
>>>>>> 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.
>>>>> 
>>>>> If the username was used as identification it would mean that with a
>>>>> valid cert I could present myself as any user!
>>>>> 
>>>>>> So you may be right about that.  I only ever looked at RFC 6187 from
>>>>>> the perspective of the server presenting an IDevID certificate.  But,
>>>>>> assuming it's true, then perhaps this:
>>>>>> 
>>>>>> NEWEST:
>>>>>> 	if-feature "tls-listen or tls-call-home or sshcmn:ssh-x509-certs";
>>>>> 
>>>>> Ok.
>>>>> 
>>>>> This gives:
>>>>> 
>>>>> grouping netconf-server-grouping {
>>>>>  description ...;
>>>>>  container client-identification {
>>>>>    description
>>>>>      "Specifies a mapping through which clients MAY be identified
>>>>>       (i.e., the NETCONF username) from a supplied certificate.
>>>>>       Note that a client MAY alternatively be identified via an
>>>>>       alternate authentication scheme.";
>>>>>    container cert-maps {
>>>>>      if-feature "tls-listen or tls-call-home or sshcmn:ssh-x509-certs";
>>>> 
>>>> Yes.
>>>> 
>>>>> But since the description of the "client-identification" says that it
>>>>> is used only with certificates, perhaps that container's name should
>>>>> reflect this, and the if-feature statement moved to that container?
>>>>> Perhaps:
>>>>> 
>>>>>  container client-cert-identification
>>>>>    if-feature "tls-listen or tls-call-home or sshcmn:ssh-x509-certs";
>>>>> 
>>>>> and also perhaps remove 'cert-maps', and use the cert-to-name grouping
>>>>> directly here?
>>>> 
>>>> Good.  My only hesitation is that someday there may be a need for
>>>> another way to identify clients, but that sounds too far out (even for
>>>> me) to squabble over.  But a better name is needed.
>>>> "cert-based-client-identification" would be more accurate, but that
>>>> seems overly long.  Looking at a snippet of config might help...
>>>> 
>>>>     netconf-server-parameters : {
>>>>       something-here : [
>>>>         {
>>>>           cert-to-name : { ... }
>>>>           cert-to-name : { ... },
>>>>           ...
>>>>           cert-to-name : { ... }
>>>>         }
>>>>       ]
>>>>     }
>>>> 
>>>> How about "cert-to-name-mappings"?  ( know, almost the same length,
>>>> but half the number of syllables!).  But that name leaves out the word
>>>> "identity", which is may be important in security circles, so maybe
>>>> "client-identity-mappings"?
>>> 
>>> I think this name is as generic as "client-identification".  The best
>>> so far imo is "cert-based-client-identification".  A bit long, but
>>> descripitive.
>> 
>> Actually, I think we should go back to "client-identification" now that raw-public-key and pre-shared/pairwise-symmetric key (PSK) has been added as alternate ways that TLS clients and servers may identify themselves and authenticate peers.   Thus it seems that there is a need to map usernames from things other than just certificates.
> 
> I think I'll have to see how that works out.  But if the container is
> more general than just client certificates, then the description text
> needs to be updated.

Agreed.  Actually, saying just this was going to be my response a couple days ago, but then I saw how everything flattened out and I held my tongue.  But, yes, updating the description text would be a prerequisite.

In an effort to stem the effort, unless someone else wants to drive it, and the WG agrees, I think that it would be okay for the NETCONF/RESTCONF modules to leave defining how to map PSK/RPK keys to usernames to a future effort.   We will have successfully added PSK/RPK keys for Henk's needs (CoAP), while having a clear path for to proceed if ever NETCONF wants to pick it up.



>>> Hmm, I realize that I have misunderstood 'host-keys' here.  How
>>> exactly is this supposed to be used?  This is the client
>>> authentication part of a server.  How is the *host* key used here by
>>> the server?   I mean, the client doesn't present a host key to the
>>> server, so I don't understand what this is.
>> 
>> It seems that I've been overzealous with the term "host-key" here.  In SSH, a "host-key" is a special term for the server's public key.  Clients may also authenticate using a public key, but there isn't a special term for that case.   RFC 4252 states that clients can authenticate using "publickey", "password", and "hostbased".   Per RFC 6187, section 1, 1st paragraph, the "publickey" algorithm is is also used for X.509 certificates (e.g., x509v3-rsa2048-sha256).
> 
> So what is the conclusion?  Remove host-key here?  Or was the
> intention that this is the user's public key?

User's publickey.


Kent // contributor