[Netconf] NETCONF ovet TLS changes proposed

["Bert Wijnen \(IETF\)" <[e-mail]>]

WG members,

The Security ADs have given their feedback on this document,
see attached email from Pasi Eronen at the bottom.

As a result, Badra wants to remove all text related to password.
authetication. IT only makes sense that he does so if we have WG
consensus on that. My personal feeling from the mailing list discussions
and from the last session at IETF72 is that the WG indeed does
agree with that removal.

Please speak up before September 1st if you do not agree.

Thanks,
Bert Wijnen (sepaking as WG chair)

----- Original Message ----- 
From: "Badra" <[e-mail]>
To: "Bert Wijnen (IETF)" <[e-mail]>; "Ersue, Mehmet (NSN - 
DE/Muenich)" <[e-mail]>
Sent: Thursday, August 21, 2008 6:43 PM
Subject: NETCONF ovet TLS: Mail


> Dear Bert,
>
> I would like to send the following text to the mailing list, but I prefer
> that you of Mehmet do that since it includes a WG consensus request. 
> Please
> advice.
>
>
> Dear all,
>
>
>
> Pasi Eronen and Tim Polk (Security Ads) have revised the document during 
> the
> last IETF session (see minutes) and via e-mail from Pasi (see below).
>
>
>
> Early versions of the document didn't specify the password-based
> authentication and this later has been added to the document since some
> members wanted ala unix authentication, which why PSK derivation from
> passwords has been specified.
>
>
>
> Based on the comments from the Security ADs: the main reason for using 
> TLS;
> especially considering that the document can't anyway integrate with many
> existing password databases (RADIUS, LDAP, etc.) the way SSH and BEEP can, 
> I
> would like to suggest removing text related to password authentication.
> Also, I am looking for WG consensus on this issue.
>
>
>
> Best regards,
>
> Badra
>
>
> On Thu, Aug 21, 2008 at 6:24 PM, Badra <[e-mail]> wrote:
>
>>  Dear Pasi,
>>
>> Thank you very much for your comments and review. I totally agree with 
>> you
>> regarding the password authentication and the first version of the 
>> document
>> specification doesn't handle password-based authentication.
>>
>> But as you read on the mailing list discussion, people wants to keep ala
>> unix authentication, which why the PSK derivation from password has been
>> added to the document. But later they proposed to don nothing for the
>> moment...
>> I think the situation is clear especially after the AD comments, the best
>> way is to remove any text related to password authentication.
>>
>> I will bring your comments to the mailing list to have a WG consensus on
>> that.
>> Thank you again.
>> Best regards,
>> Badra
>>
>>
>>
>> On Thu, Aug 21, 2008 at 11:12 AM, <[e-mail]> wrote:
>>
>>> Dear Badra,
>>>
>>> I've now read the threads from NETCONF mailing list in June/July/August,
>>> minutes from IETF 72, and versions -02 and -03 of the NETCONF-over-TLS
>>> document.
>>>
>>> After reading the mailing list, I did get the impression that many WG
>>> member thought that password-based authentication is already handled
>>> well enough by the existing NETCONF transports (SSH and BEEP), and the
>>> NETCONF-over-TLS specification doesn't need to handle passwords.
>>>
>>> I would tend to agree with this view, and would recommend scoping
>>> draft-ietf-netconf-tls to certificate-based authentication, which
>>> isn't that well handled by the existing transports. I believe this
>>> would be the main reason for using TLS -- especially considering that
>>> NETCONF-over-TLS can't anyway integrate with many existing password
>>> databases (RADIUS, LDAP, etc.) the way SSH and BEEP can.
>>>
>>> At least in SNMPv3, integrating with existing password databases has
>>> been found to be very important, and that's why we have ISMS WG trying
>>> to support that. NETCONF in the current RFCs got this part right, and
>>> doing passwords the way proposed in current NETCONF-over-TLS draft
>>> would IMHO be a step backwards.
>>>
>>> I'm also not very happy to see new cryptography in this specification
>>> (the SHA-1 thing in Section 3.3). Although it's similar to what IKEv2
>>> does, that doesn't mean it would be a good idea for NETCONF -- and in
>>> IKEv2, it's part of the IKEv2 itself; here it's something added
>>> on top of RFC 4279 (BTW, something along those lines *was* proposed
>>> when RFC 4279 was being done, but was rejected).
>>>
>>> Best regards,
>>> Pasi
>>>
>>> > -----Original Message-----
>>> > From: ext Badra [mailto:[e-mail]]
>>> > Sent: 05 August, 2008 14:54
>>> > To: Eronen Pasi (Nokia-NRC/Helsinki); [e-mail]
>>> > Cc: Ersue Mehmet (NSN - DE/Muenich); ext Bert Wijnen (IETF);
>>> > Mohamad Badra
>>> > Subject: Re: NETCONF ovet TLS: Password issue
>>> >
>>>  > Dear Tim and Pasi,
>>> >
>>> > During NETCONF session at Dublin meeting, there was a request from Tim
>>> > to more explain why PSK computation from passwords is needed for the
>>> > document "NETCONF over TLS". Please kindly comment on the following
>>> > text and tell your recommendations. Many thanks.
>>> >
>>> > Best regards,
>>> > Badra
>>> >
>>> >
>>> > "NETCONF requires that its transport provide mutual authentication of
>>> > client and server. Consequently, "NETCONF over TLS" reuses only those
>>> > cipher suites that provide mutual authentication using certificates
>>> > and/or PSK. In other words, anonymous cipher suites are forbidden with
>>> > this document.
>>> >
>>> > On the certificate side:
>>> > Both the client and the server MUST have a certificate to be sent
>>> > during the Handshake phase.
>>> >
>>> > On the PSK side:
>>> > In the first version of the document, it was expected to use RFC 4279
>>> > as it is and to apply section 5 of this RFC. However, and based on
>>> > discussion on the NETCONF mailing list, people wants to keep using ala
>>> > unix password/username. Consequently, the draft moved toward deriving
>>> > the PSK from a couple of password/username.
>>> >
>>> > Note: the username is the psk_identity (in the RFC4279 terminology).
>>> >
>>> > In conformity with section 5.4 of RFC 4279, a management interface
>>> > should be defined for entering the username (and the PSK). With the
>>> > document, it consists of entering the username (psk_identity) and the
>>> > password but the password isn't the PSK: both the username and the
>>> > password are then used as inputs for the PSK derivation function as
>>> > defined in the "NETCONF over TLS" document. The output value (20
>>> > bytes) of this function is the PSK.
>>> >
>>> > As you can see, this way of computing the PSK is specific to NETCONF
>>> > and couldn't be used for other purpose. In addition, it doesn't
>>> > require any modification, at least on the server side since this
>>> > server stores directly the PSK (the result of the PSK derivation
>>> > function)."
>>>
>>
>
>
> -- 
> Badra
> 


_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf