[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new revision: draft-ietf-netconf-tls-01.txt

Dear Kaushik,

Thank you for your review and for your comments.
First of all, I would like to clarify a point on the document as it is written by today: it is based on using a PSK derived from a password, on using a certificate, or on both of them. Consequently, its main objective isn't to enable any password exchange type inside TLS for the user authentication. This authentication is done using ant TLS ciphersuite that is able to ensure mutual authentication.
Regarding your 2nd point, I think that RADIUS or LDAP can be used within the document by simply collect the PSK and its identity as en entry in the database, or by collect the password with the PSK and its identity at the TLS server and leave this server reacts as a proxy.
Regarding your 1st point, it is possible for the server to authenticate the user using SASL or EAP. But IMO, SASL or EAP over TLS should provide crypto-binding and I don't think we have that today. However, if the WG think that using PSK derived from a password isn't sufficient and that an abstraction layer (SASL, EAP, etc.) is required to enable using OTP and other password types, so please let me know, like that we can insert such a layer between NETCONF and TLS. 

Best regards,
Badra

Kaushik Narayan a écrit :

Hi Eliot, Mohamad,

The password authentication mechanism defined in section 3.3 would be
problematic to support if the authentication needs to be done by a RADIUS
server for a couple of reasons

1. I am not a TLS expert but I presume that the TLS server would need to
possess the PSK; I don't think it would be appropriate for a RADIUS server
to provide a RADIUS client with keys derived (PSK) from the user's password
without authenticating the user.

2. In many cases the user's password might not even be available with the
RADIUS server, they might be stored in LDAP (there may be ways to acquire
the password using a LDAP getuserpassword instead of a bind) or token
servers (OTP).

Given that password based mechanisms with passwords stored in a central
database (RADIUS, LDAP, OTP) would probably be the most widely used
mechanisms for NetConf & the security issues in deriving the PSK from a
password that you have pointed out in the draft; I am wondering why you
wouldn't consider using SASL or alternatively perform user authentication
once the TLS tunnel has been established (similar to HTTP).

Regards,
 kaushik

On 2/19/08 12:36 AM, "Eliot Lear" <lear@cisco.com> wrote:


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.

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.

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.

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.

HTH...

Eliot

Bert Wijnen - IETF wrote:

Thanks Badra. My initial comments have been addressed.

All WG Members, pls review this new revision and comment
prefereably well BEFORE we have our meeting at IETF71.
Bert Wijnen 
-----Oorspronkelijk bericht-----
Van: owner-netconf@ops.ietf.org
[mailto:owner-netconf@ops.ietf.org]Namens Mohamad Badra
Verzonden: vrijdag 15 februari 2008 11:12
Aan: Charlie Kaufman
CC: netconf@ops.ietf.org
Onderwerp: Re: FW: review/comments of/on draft-ietf-netconf-tls-00.txt


Thank you Charlie.

I submitted a new version of the document that addresses the raised
comments. Please don't hesitate to submit your comments. Many thanks!

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