RE: Password-based user authentication with Netconf over TLS

[badra@isima.fr]

Dear Charlie,

I think the best way to do that is to follow section 5 of RFC4279 for
formatting and section 7.2 for brute force and dictionary attacks. I
totally agree with you on the psk_identity_hint and I would expect too
that a DNS name for the server would be the common case.

It is true that the password can be compromised by the compromise of this
server, but it is the PSK case too, so I don't know if we can go far from
what said on that in RFC4279.

SHA-1 seems sufficient, and using the hash algorithm negotiated by TLS is
also possible. (BTW, what do you mean by "Key Pad for Netconf", is it a
ASCII string?)

Best regards,
Badra


> How best to transform a password into a PSK depends on what attacks you're
> trying to defend against, what formatting issues and constraints are
> imposed by rfc4279.
>
> Your #3 below is the "obvious" approach; it has the virtue of simplicity.
> Your modification #1 adds no cryptographic strength to the exchange (other
> than making dictionary attacks slightly more CPU intensive) because
> hashing the password and folding in ClientHello.Random and
> ServerHello.Random is already done in the key derivation in rfc4279. #2
> does offer an advantage, but I think we can do better.
>
> There are some enhancements that I would suggest to deal with different
> attacks.
>
> An administrator is likely to choose the same password for multiple uses
> (in spite of all advice to the contrary). It is therefore undesirable to
> save the administrator's password on the server, since anyone who
> compromises the server could learn the administrator's password and use it
> to authenticate to other systems where the administrator has rights. So
> the first enhancement to consider is to have the PSK be a one way hash of
> the password (per your #2) so the server only needs to store the one way
> hash.
>
> That still has the problem that if other systems also authenticate based
> on the one way hash of the password rather than the password itself, they
> can be compromised by the compromise of this server (and vice versa). It
> is better, then, that each server use a distinct hash function or some
> "salting" of the password. In the protocol specified in rfc4279, the
> client identity and proof of the PSK occur in the same message, so there
> is no opportunity for the server to look up a "salt" specific to the user.
> The only logical value for salt is the information specified in the
> psk_identity_hint sent as part of the ServerKeyExchange.
>
> The psk_identity_hint can do double duty and also provide a form of server
> authentication in the case where the user has the same password on a
> number of NETCONF servers. The psk_identity_hint should be a string
> representation of the name of the server recognizable to the administrator
> or his software. In the case where the user types a server name to connect
> to, it should be that string. If the string the user enters differs from
> the one returned as psk_identity_hint, the software could display the
> server's name and ask the user to confirm. For automated scripts, the
> names could be expected to match. I don't know exactly where Netconf is
> used, but I would expect that a DNS name for the server would be the
> common case.
>
> Finally, both to keep the server's hashed password from being useful in
> impersonating other services on the same host and to allow a centralized
> password changing service to be able to update all of the Netconf services
> without itself knowing the administrator's cleartext password, it would be
> helpful to hash in something specific to the Netconf protocol.
>
> Taking all of these together, I'd recommend defining:
>
> PSK = Hash( Hash(Password || "Key Pad for Netconf") || psk_identity_hint)
>
> There is a politically thorny issue of what to use for a hash function.
> SHA-1 is the "logical" candidate. From a security point of view, the
> relevant attack is a "1st preimage attack" - learning the password from
> the hash with less effort than a dictionary attack. This is the most
> difficult attack to mount against a hash function, and I believe that even
> MD4 would have adequate strength. Nevertheless, there is pressure to
> discontinue use of SHA-1 (or at least have a plan for migrating away from
> it) even in contexts where there is nothing wrong with it. While one could
> imagine using whatever hash algorithm TLS negotiates (starting with
> TLSv1.2), this does not provide an easy migration story in this context.
>
> So my technical recommendation would be to use SHA-1. If that fails for
> political reasons, a second choice would be SHA-256, and a third would be
> SHA-512. If forced to be "algorithm agile", you should probably specify
> using the hash algorithm negotiated by TLS even though that will be
> problematic to implement.
>
>         --Charlie
>
> -----Original Message-----
> From: badra@isima.fr [mailto:badra@isima.fr]
> Sent: Sunday, December 09, 2007 12:03 PM
> To: Charlie Kaufman
> Cc: dromasca@avaya.com
> Subject: Password-based user authentication with Netconf over TLS
>
> Dear Charlie and Dan,
>
> To continue our discussion regarding NETCONF over TLS with a
> password-based user authentication, you kindly find below three proposals
> (as we briefly discussed them at IETF-Vancouver).
>
> RFC4279 enables pre-shared key (PSK) based user authentication. Thus:
>
> 1. The PSK within NETCONF can be generated from the password using one of
> the following ways:
>      a. Apply the PKCS#5 KDF on the password, the ClientHello.Random and
> the ServerHello.Random,
>      b. Replace the PSK (RFC4279) with the result of the KDF.
>
> 2. Apply a hash function
>      a. MD5 or SHA1 on the password,
>      b. Replace the PSK with the hash result.
>
> 3. Use the password "as it is" the PSK in RFC4279.
>
> Please feel free to give yours preferences, suggestion or alternatives to
> the above ways of using passwords with RFC4279.
>
> With my best regards,
> Badra
>

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>