Subject: RE: Password-based user authentication with Netconf over TLS

From: [email-masked]
Date: Tue, 11 Dec 2007 01:34:15 +0100 (CET)

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: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, December 09, 2007 12:03 PM
> To: Charlie Kaufman
> Cc: [email-masked]
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: [email-masked]
Date: Tue, 11 Dec 2007 01:56:36 +0100 (CET)

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

---

From: Phil Shafer <[email-masked]>
Date: Mon, 10 Dec 2007 22:22:14 -0500

>pre-shared keys are symmetric keys, shared in advance among the

I'm not a security dude, but just wanted to confirm that this is a
new pre-shared key per user, and the normal CLI passwords will not
be usable in this scheme, given that the passwords are not stored
on the router (or anywhere else), rather the salted or hashed version
of the password is stored, ala unix.  Deploying new PSKs will be
an impediment to deployment.

Also: what is the impact of section 7.3 of rfc4279?

  7.3.  Identity Privacy

   The PSK identity is sent in cleartext.  Although using a user name or
   other similar string as the PSK identity is the most straightforward
   option, it may lead to problems in some environments since an
   eavesdropper is able to identify the communicating parties.  Even
   when the identity does not reveal any information itself, reusing the
   same identity over time may eventually allow an attacker to perform
   traffic analysis to identify the parties.  It should be noted that
   this is no worse than client certificates, since they are also sent
   in cleartext.

Does this mean we'll be announcing our netconf users' information
to would-be crackers?  Is this identity as in "phil" or something
else?

Thanks,
 Phil

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 11 Dec 2007 10:42:23 +0100

Hi Phil,

> an impediment to deployment.

So what about using the stored hash or about replacing the password with 
the hash version as shown in the following formula?

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

> to would-be crackers?  Is this identity as in "phil" or something

The traffic analysis by here means that an intruder can learn who is 
reaching the network, when, and from where, and hence can correlate the 
user identity to the connection location.

RFC4279 does not provide credentials protection and then any info 
related to the user identity is sent in clear text. However TLS 
renegotiation (re-handshake) implements a way to avoid sending the user 
identity and credentials in clear text: doing a TLS Handshake with only 
server authentication, and then a second authentication with mutual 
authentication (all second handshake messages are sent encrypted).

Best regards,
-- 
Mohamad Badra
CNRS - LIMOS Laboratory