RE: Password-based user authentication with Netconf over TLS

[badra@isima.fr]

Charlie and all,

Please give your comments on the following section to be added to the
document...

Password-Based NETCONF manager Authentication:
----------------------------------------------

RFC4279 supports authentication based on pre-shared keys (PSKs). These
pre-shared keys are symmetric keys, shared in advance among the
communicating parties.

The PSK can be generated in many ways and its length is variable.
Implementation of this document MAY rely on RFC4279 to enable password
based user authentication. In this case, the password is used to generate
the PSK. It is RECOMMENDED that implementations that allow the
administrator to manually configure the password also provide a
functionality for generating a new random password, taking RFC4086 into
account.

This document generates the PSK from the password as follow:

    PSK = SHA-1((password + "Key Pad for Netconf") + psk_identity_hint)

Where:
+ means concatenation.
The label "Key Pad for Netconf" is an ASCII string.
psk_identity_hint is defined in section 5.1 of RFC4279, and it is set here
to the DNS name of the NETCONF agent (i.e., the TLS server).

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/>