[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new revision: draft-ietf-netconf-tls-01.txt
Hi Eliot,
Thank you for the comments. Responses and comments in-line..
Eliot Lear a écrit :
Hi Bert & Mohamad,
I am not a radius expert, but I think you might have a radius problem.
It would seem that either the identity & identity_hint discussed in the
draft cannot be unique to a host OR the radius server must perform the
transformations with appropriate identity & identity_hint passed along
with the string presented by the client. Keeping in mind that OTPs
should be supported, it seems likely that the radius server would have
to do the support.
I see that RFC 4590 might be related work. It could be possible to
propose a radius extension along similar lines. However, I am by no
means a radius expert. Kaushik is, and David Nelson is, so I've CC'd
them. While the extension itself might be out of scope for NETCONF and
in fact might be more generally useful, not having such an extension
leads us towards an SNMPv3 problem and a future ISMS analog. I don't
think you have to gate this draft on that work, but the mandate that you
hash the password is what causes the problem. SASL solves this with
PLAIN, but some people complain that it is not bound well to TLS.
I am not a RADIUS expert too, and any reply from Kaushik Narayan, David
Nelson and others is welcome.
I agree on the fact that the document doesn't make use of all existing
password databases features. It only gives a way to generate a PSK from
a password for NETCONF operating over TLS. While NETCONF relies on the
transport layer for the user authentication, we are forced to provide a
profile for using password within TLS "without" modifying TLS (note that
there are some expired IDs that propose using OTP and passwords within
TLS, e.g., draft-linn-otp-tls).
Regarding the transformations, I guess the exact encoding with RADIUS is
implementation dependent. But I think RADIUS recommends UTF-8, (doesn't
it?). If then it will be OK for the document when relying on RFC4279
(the PSK identity, identity hint, and password are converted to a
character string, and then encoded to octets using UTF-8).
Regarding OTP and the other passwaord mechanisms, I can identify the
following three options to move forward with the password authentication:
1. keep the proposed profile to derive a PSK from a password and store
the PSK with the identity and the hint in the database.
2. use TLS for establishing a secure session with the server
authentication and then implement a "RADIUS client" on the client (AVP
attributes inside the established TLS session).
3. specify NETCONF over EAP (encapsulation) over TLS.
4. others?
Personally, I am for the 1st option.
Also, here are a few additional comments:
In that Section 3.3 Note 1, if you're going to say something is NOT
secure, you should bound that statement and preferably provide a reference.
OK, I will insert RFC 4306 as reference.
In that same section, Note 2, and I realize this may be my poor reading
of RFC 4279, I do not see how the form of the PSK resultant (ASCII or
HEX) is specified.
RFC4279 section 5.1 gives the form of that. If this is not clear in the
draft, what about inserting the following at the beginning of note 2:
"The PSK identity, identity hint, and password MUST be first converted
to a character string, and then encoded to octets using UTF-8 [UTF8]."
Above that point, the following statement requires further elaboration
and the term "random" does not sit well on its own.
It is RECOMMENDED that implementations
that allow the administrator to manually configure the password also
provide functionality for generating a new random password, taking
[RFC4086] into account.
While it's good that you cited RFC 4086, I doubt that Don Eastlake would
use the term "random", but perhaps "pseudo random". All of this having
been said, I believe you're a bit off the beaten path, and you could
probably cut this text in its entirety.
I would prefer to keep RFC4086 as a reference and remove the 'random'.
HTH...
Eliot
Many thanks!
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/>