[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: review/comments of/on draft-ietf-netconf-tls-00.txt
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).
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.
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.
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.
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.
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.
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. If that's true (and more so if it is not), that should
be stated somewhere.
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.
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.
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).
--Charlie
-----Original Message-----
From: Bert Wijnen [mailto:bertietf@bwijnen.net]
Sent: Monday, January 28, 2008 1:30 PM
To: Netconf
Cc: Charlie Kaufman
Subject: RE: review/comments of/on draft-ietf-netconf-tls-00.txt
I hope Charlie (our Security Advisor) can chime in on this.
Bert Wijnen
> -----Oorspronkelijk bericht-----
> Van: Mohamad Badra [mailto:badra@isima.fr]
> Verzonden: maandag 28 januari 2008 16:58
> Aan: Bert Wijnen
> CC: Netconf
> Onderwerp: Re: review/comments of/on draft-ietf-netconf-tls-00.txt
>
>
> Dear Bert,
>
> The TLS documents don't discuss the storage of the credentials
> (certificates, PSK, etc.). However, they recommend some documents to
> particularly generate the PSK as described in section 7.2 of RFC4279.
>
> I can insert a sub-section on that but I think it will create some
> interoperability issues if we replace the hashed value of the password
> with the hashed value of the concatenation of the password and the agent
> identifier.
>
> Personally, I prefer to recommend the use of a different password on
> each agent. The issues related to the password storage are not related
> to the TLS itself, and then better to don't discuss them in the
> document. But adding some hints in the security considerations section
> may be useful.
>
> Best regards,
> Badra
>
>
> Bert Wijnen a écrit :
> > OK, so that explanation/detail/advice that you give below may
> > be something worthwhile to add to the text, or maybe state such
> > a thing in security considerations section?
> >
> > Or is that already covered in the standard TLS documents?
> >
> > Bert Wijnen
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: Mohamad Badra [mailto:badra@isima.fr]
> >> Verzonden: maandag 28 januari 2008 16:08
> >> Aan: Bert Wijnen
> >> CC: Netconf
> >> Onderwerp: Re: review/comments of/on draft-ietf-netconf-tls-00.txt
> >>
> >>
> >> Dear Bert,
> >>
> >> Thank you for your comments, I will integrate all of them in the future
> >> version.
> >>
> >>> - In section 3.2 I read:
> >>>
> >>> The psk_identity_hint is initially defined in section 5.1
> of RFC4279
> >>> 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 agents.
> >>>
> >>> and wonder: would that not be risky in that if an intruder discovers
> >>> the password of one agent, that he then has access to
> >>> all/several other agents as well?
> >>
> >> Of course it is risky in having the same password shared with several
> >> agents, not only from intruder (external entity) point of view but also
> >> from any legitimate agent (internal entity) that has the password.
> >>
> >> The easier way to minimize this risk is by recommending the use of a
> >> different password for each agent.
> >>
> >> However, it is possible to minimize the risk of discovering
> the password
> >> of one user as follows: 1) the user has to store its password in a
> >> secure way (e.g. on a temper-resistant), and 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
> >> user computes the hash version of the concatenation of the password and
> >> the agent_id before connecting to the agent. In this way, the intruder
> >> that discovers the password of one agent will not be able to
> have access
> >> to all other agents, unless he is able to perform a brute-force or
> >> dictionary attack to recover the password in clear text.
> >>
> >> 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/>