search

netconf-wg / keystore

repo for draft-ieft-netconf-keystore
2 stars 1 forks source link

YANG annotation for cleartext-password --> ciphertext-password? #5

Closed kwatsen closed 6 years ago

kwatsen commented 7 years ago

Current YANG module has:

                 +--:(ciphertext-password)
                  |  +--rw ciphertext-password?   string
                  +--:(cleartext-password)
                     +--rw cleartext-password?    string

The idea is that a cleartext-password is configured, which gets converted by the server into a ciphertext-password, at which point the cleartext-password is deleted by the server.

But shouldn't there be a YANG annotation to describe this behavior to clients? Otherwise they’ll forever think that they are out of synch!

kwatsen commented 7 years ago

Moved to Edit based on the assumption we could use the 'crypt-hash' type from the iana-crypt-hash module, but this doesn't work in this case, as we need to configure a client (not server) to be able to retain the original password in order to log into a server.

Moving back to OPEN state.

kwatsen commented 7 years ago

Ref: https://github.com/netconf-wg/keystore/issues/5.

During IETF 96, Andy pointed out the iana-crypt-hash module defined in RFC

  1. Looking at the 'crypt-hash' type more closely, it appears to not be what is needed here, as it does not retain the original clear text value.

Background: The crypt-hash type is perfect for a server that needs to authenticate clients, but what we're looking for here is a way to configure a client to log into a server, using password-based authentication. The immediate goal is to support the ietf-ssh-client module (i.e., an SSH client logging into an SSH server), but one can imagine password-based client auth being used for other protocols as well (e.g., HTTPS, LDAPS, SMTPS, IMAPS, etc.).

So, after thinking about this more, I think that the original problem was misstated (see subject line) and the real solution is to just define the password field as a plain-old string type field, and then rely on access control (e.g., NACM) to restrict read access to admins. This solution is similar to the what we said we'd do for the private-key (github issue #2).

Anyway, that do people think? Makes sense? Any objections? I'll assume it's okay if there are no responses this week.

Thanks, Kent

[Moving back to VERIFY state now]

kwatsen commented 7 years ago

The 'password' field was moved to the ietf-ssh-client module.

Moving this issue to DEAD state.