[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: review/comments of/on draft-ietf-netconf-tls-00.txt
Dear Charlie,
Charlie Kaufman a écrit :
The Security Considerations section should at least strongly recommend
and possibly even require that users choose different passwords
for the different servers they manage. As designers, we should
anticipate that real users will ignore that advice (unless we can
figure out a way to enforce it, which seems unlikely).
I will insert the following text somewhere in section 3.2 and in the
security considerations:
"It is RECOMMENDED that users choose different passwords for the
different servers they manage."
We could recommend that they use some secure password storage
mechanism to allow passwords to be long and randomly generated, but
it's unrealistic to expect such options will always be available.
In most scenarios where that is possible, use of client TLS certificates
would also be feasible and they offer better security.
AFAIK, IETF documents don't specify any recommendation for secure and
safe storage, do they? Moreover, RFC4279 said "This document does not
specify how the server stores the keys and identities, or how exactly it
finds the key corresponding to the identity it receives." In the same
way, I think the document should not specify any recommendation for the
storage.
The security considerations of RFC4279 said:
"As with all schemes involving shared keys, special care should be
taken to protect the shared values and to limit their exposure over
time."
We can extend this as follow:
"As with all schemes involving shared keys and passwords, special
care should be taken to protect the shared values and passwords as
well as to limit their exposure over time. Alternatively, using
certificates would provide better protection".
There probably should be an RFC with recommendations for deriving
PSKs from passwords generally so that documents like this one would
have something to reference, but I expect the subject would be so
controversial that it would never be approved. There are people who
believe that IETF should never standardize any protocols based on
passwords; we can only hope that this one has a sufficiently low
profile to escape their notice.
I will ask the TLS WG about that.
The series of hashes in the current proposal already captures the
advantages proposed earlier in this thread. In particular,
2) on each agent, the user
stores the hashed value of the concatenation of the password and the
agent_id (the agent_id is the agent identifier, e.g. IP address).
the current proposal includes in the computation of the PSK the value
of psk_identity_hint, which is the DNS name of the agent. This allows
agents to store a PSK that even if disclosed is not helpful in
authenticating to any other agent.
OK.
Other comments on this spec:
1) This spec calls for running NETCONF over TLS on a dedicated TCP port.
If there is also a TCP port allocated to running NETCONF not over TLS
(is there?), this goes against what has been recent IETF policy. While
this was done in the early days of SSL (in particular, for HTTP), it
uses up twice as many ports and more recently the practice has become
some negotiation on the unprotected port in which use of TLS for the
rest of the TCP session is negotiated.
AFAIK, no TCP port for NETCONF. Note that netconfsoaphttp, netconf-beep,
and netconf-ssh run NETCONF over the security protocol on a dedicated
TCP (or UDP) port.
2) The last sentence of section 3.1 says that server-only authentication
or anonymous mechanism can have password-based client authentication
added on as specified in section 3.2. I don't believe that's
technically correct. There are mechanisms that do mutual authentication
based on public keys (which are described in section 3.1.*), mechanisms
that do mutual authentication based on a pre-shared key (which are
described in section 3.2.*), mechanisms which use Kerberos (which are
not described in this document, but logically could be), mechanisms
which are anonymous (which can't be used with NETCONF), and mechanisms
which do both public key based authentication of the server and mutual
authentication based on a pre-shared key. These last use the techniques
of both sections 3.1.* and 3.2.*. For some of the mechanisms, client
authentication is optional; those variants also cannot be used with
NETCONF. THIS IS ONLY AN ISSUE WITH YOUR TERMINOLOGY; THE IDEAS ARE
RIGHT. I could help with text if it's not obvious how to fix it.
I agree, all of the above mechanisms, excepting the anonymous one, are
supported by the document.
What about replacing:
When public key is used for authentication, TLS supports three
authentication modes: authentication of both parties, server
authentication with an unauthenticated client, and total anonymity.
For the last two modes, a profile to enable the password-based client
(manager) authentication is defined in section 3.2.
with:
When public key based-certificate authentication is used, TLS
supports two authentication modes: mutual and server-side
authentication. For the second mode, the client authentication may be
done at the application layer or by negotiating one of the
ciphersuites defined in RFC4279. This document defines a profile to
authenticate the client using PSKs derived from passwords (see
section 3.2).
Please don't hesitate to submit your text if you think it is always not
clear or not fixed.
3) Particularly in section 2.1, but also elsewhere, I was confused by
the relationship between the terms NETCONF manager, NETCONF client,
NETCONF agent, and NETCONF server. I believe that for purposes of this
document, the first two terms are synonyms and the second two terms
are synonyms.
Yes
If that's true (and more so if it is not), that should
be stated somewhere.
Fixed.
4) Section 3.2 does not specify how "stored-hash" is derived from
"password". If it is by hashing it, you need to specify what hash
function (probably SHA-1). I believe it would be better to
dispense with the term "stored-hash" entirely and use "password" in
its place. The value to be stored on the server for the purpose of
running this protocol should be the PSK rather than the password
or any earlier intermediate hash.
Phil Shafer writes :
"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."
In this way, I replaced the password with its hash value. (In JUNOS, the
plain text and the hash value (MD5) are supported!!
I will fellow your point of view and use the password instead of the
hash value and then store the PSK instead of any other hash value.
5) You should specify canonicalization of the password as entered
by the user to the byte string input to the first hash function.
RFC 4013 is probably the best reference to cite unless you want
something more restrictive.
RFC4279 specifies that in section 5 and recommendes RFC4013.
What about saying: "RFC4279 defines some conformance requirements for
the PSK, for the PSK identity encoding and for the identity hint. The
same requirements apply here as well; in particular on the password."
6) There should probably be a statement of required cipher suites
to support interoperability (unless there is some RFC somewhere
that can be referenced for this purpose). I would expect that the
most commonly used would be:
TLS_DHE_PSK_WITH_AES_128_CBC_SHA (authentication using a password),
TLS_RSA_WITH_AES_128_CBC_SHA (authentication using X.509 certs), and
TLS_RSA_PSK_WITH_AES_128_CBC_SHA (authentication using both).
OK.
--Charlie
Thanks!
Badra
--
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/>