[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new revision: draft-ietf-netconf-tls-01.txt
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
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).
On 2/19/08 12:36 AM, "Eliot Lear" <firstname.lastname@example.org> 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.
> 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: email@example.com
>>> [mailto:firstname.lastname@example.org]Namens Mohamad Badra
>>> Verzonden: vrijdag 15 februari 2008 11:12
>>> Aan: Charlie Kaufman
>>> CC: email@example.com
>>> 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,
>> to unsubscribe send a message to firstname.lastname@example.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/netconf/>
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.