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

["David B. Nelson" <d.b.nelson@comcast.net>]

Thanks for forwarding this, Eliot.

I'll take a few days to read the draft and then send you my thoughts.

Regards,

Dave Nelson

> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com]
> Sent: Tuesday, February 19, 2008 3:37 AM
> To: Bert Wijnen - IETF
> Cc: Mohamad Badra; netconf@ops.ietf.org; Nelson, David; Kaushik Narayan
> Subject: Re: new revision: draft-ietf-netconf-tls-01.txt
> 
> 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/>
> >
> >
> 



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