Subject: Re: review/comments of/on draft-ietf-netconf-tls-00.txt

From: "Bert Wijnen" <[email-masked]>
Date: Mon, 28 Jan 2008 22:32:01 +0100

I hope Charlie (our Security Advisor) can chime in on this.

Bert Wijnen

> -----Oorspronkelijk bericht-----
> Van: Mohamad Badra [mailto:[email-masked]]
> 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:[email-masked]]
> >> 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
> >>
> >>
>
>
>

Bert Wijnen

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