Re: Password-based user authentication with Netconf over TLS

[Mohamad Badra <badra@isima.fr>]

Hi Phil,

Phil Shafer writes :
> badra@isima.fr writes:
> > RFC4279 supports authentication based on pre-shared keys (PSKs). These
> > pre-shared keys are symmetric keys, shared in advance among the
> > communicating parties.
>
> 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.

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)

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

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


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