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

From: "Bert Wijnen" <[email-masked]>
Date: Mon, 28 Jan 2008 14:50:00 +0100

Here are my initial comments. Mainly editorial/administrative
for now, except for the last comment/question.

- ID-NITS tells us:
   == Missing Reference: 'RFC4279' is mentioned on line 246, but not defined

   -- Duplicate reference: RFC4346, mentioned in 'TLSEXT', was also
mentioned
      in 'TLS'.

     Summary: 0 errors (**), 1 warning (==), 1 comment (--).

     Run idnits with the --verbose option for more detailed information
about
     the items above.

  see:
http://tools.ietf.org/wg/netconf/draft-ietf-netconf-tls/draft-ietf-netconf-t
ls-00.nits.txt

- expand acronyms.
  You have as title:  NETCONF over TLS
  I suggest to change it to

     NETCONF over Transport Layer Security (TLS)

  that would also bee more conistent with the titles of
  RFC4742, 4743 and 4744

  I would also expand the TLS acronym in the abstract and in
  section 1.1

- general
  Personally I like ciatations of the form [RFC4346] better than
  [TLS}. The reason is that I can immediately see which RFC
  to check. I know it is subjective. So if you feel strong about
  your form of citation, then I will respect that.

- Section 1.1
  I wonder if it would not be better to be more consistent with the
  other NETCONF documents and use the terms "client"and "server"
  instead of "manager" and "agent"
  In fact throughout the document, you sometimes do use the
  terms client and server and other times manager and agent.

- section 3.2

   of the password is stored is used to generate the PSK. It is
   ----------------^^--------^^

   for the seconf "is" maybe change it to "and is" ??

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

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

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 28 Jan 2008 16:07:51 +0100

Dear Bert,

Thank you for your comments, I will integrate all of them in the future 
version.

>               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

---

From: "Bert Wijnen" <[email-masked]>
Date: Mon, 28 Jan 2008 16:30:06 +0100

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

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 28 Jan 2008 16:58:26 +0100

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Jan 2008 17:10:48 +0100

>   terms client and server and other times manager and agent.

The only reason I used manager and agent in RFC 4744 was that to not do 
so would have caused more confusion.  This ought not apply to NETCONF/TLS.

Eliot

---

From: Charlie Kaufman <[email-masked]>
Date: Mon, 28 Jan 2008 21:45:19 -0800

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
> >> 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:[email-masked]]
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

> Verzonden: maandag 28 januari 2008 16:58
> Aan: Bert Wijnen
> CC: Netconf

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 29 Jan 2008 18:17:55 +0100

Dear Charlie,

> 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."

> 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".

> profile to escape their notice.

I will ask the TLS WG about that.

> authenticating to any other agent.

OK.

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

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

> are synonyms. 

Yes

>If that's true (and more so if it is not), that should
> be stated somewhere.

Fixed.

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

> 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."

> TLS_RSA_PSK_WITH_AES_128_CBC_SHA (authentication using both).

OK.

>         --Charlie

Thanks!
Badra
-- 
Mohamad Badra
CNRS - LIMOS Laboratory