Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt

[[e-mail]]

>> "The benefits of pre-shared symmetric-key vs. public-/private-key pair
>> based authentication for the key exchange in TLS have been explained in
>> the Introduction of [RFC4279]".
>>
>
> Weeeellllll I sort of see what you mean. Section 1.1 says
>
> "1.1.  Applicability Statement
>
>    The ciphersuites defined in this document are intended for a rather
>    limited set of applications, usually involving only a very small
>    number of clients and servers.  Even in such environments, other
>    alternatives may be more appropriate.
>
>    If the main goal is to avoid Public-Key Infrastructures (PKIs),
>    another possibility worth considering is using self-signed
>    certificates with public key fingerprints.  Instead of manually
>    configuring a shared secret in, for instance, some configuration
>    file, a fingerprint (hash) of the other party's public key (or
>    certificate) could be placed there instead.
>
>    It is also possible to use the SRP (Secure From [e-mail]  Wed Oct  1 05:57:26 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 416B03A6BF1;
	Wed,  1 Oct 2008 05:57:26 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C5CF83A6BF1
	for <[e-mail]>; Wed,  1 Oct 2008 05:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.426
X-Spam-Level: 
X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[AWL=0.371, 
	BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3,
	SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id XclUweD61+0g for <[e-mail]>;
	Wed,  1 Oct 2008 05:57:24 -0700 (PDT)
Received: from sp.isima.fr (sp.isima.fr [193.55.95.1])
	by core3.amsl.com (Postfix) with ESMTP id 44DDD3A6BA8
	for <[e-mail]>; Wed,  1 Oct 2008 05:57:24 -0700 (PDT)
Received: from www.isima.fr ([e-mail] [193.55.95.79])
	by sp.isima.fr (8.13.8/8.13.8) with SMTP id m91DvhFP594070;
	Wed, 1 Oct 2008 14:57:43 +0100
Received: from 88.164.98.77 (SquirrelMail authenticated user badra)
	by www.isima.fr with HTTP; Wed, 1 Oct 2008 14:56:32 +0200 (CEST)
Message-ID: <[e-mail]>
In-Reply-To: <000c01c923aa$054cc6e0$0601a8c0@allison>
References: <[e-mail]><00bb01c92265$a9c7ba90$[e-mail]>
	<[e-mail]>   
	<001301c9230c$7ed77940$0601a8c0@allison>
	<[e-mail]>
	<000c01c923aa$054cc6e0$0601a8c0@allison>
Date: Wed, 1 Oct 2008 14:56:32 +0200 (CEST)
From: [e-mail]
To: "=?utf-8?Q?tom.petch=C2?=" <[e-mail]>
User-Agent: SquirrelMail/1.4.2
MIME-Version: 1.0
X-Priority: 3
Importance: Normal
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0
	(sp.isima.fr [193.55.95.1]); Wed, 01 Oct 2008 14:57:43 +0100 (WEST)
Cc: =?utf-8?Q?=C2?= <[e-mail]>
Subject: Re: [Netconf]
 =?utf-8?q?WGLC=C2=A0for=C2=A0draft-ietf-netconf-tls-04?=
 =?utf-8?q?=2Etxt?=
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/netconf>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

>> "The benefits of pre-shared symmetric-key vs. public-/private-key pair
>> based authentication for the key exchange in TLS have been explained in
>> the Introduction of [RFC4279]".
>>
>
> Weeeellllll I sort of see what you mean. Section 1.1 says
>
> "1.1.  Applicability Statement
>
>    The ciphersuites defined in this document are intended for a rather
>    limited set of applications, usually involving only a very small
>    number of clients and servers.  Even in such environments, other
>    alternatives may be more appropriate.
>
>    If the main goal is to avoid Public-Key Infrastructures (PKIs),
>    another possibility worth considering is using self-signed
>    certificates with public key fingerprints.  Instead of manually
>    configuring a shared secret in, for instance, some configuration
>    file, a fingerprint (hash) of the other party's public key (or
>    certificate) could be placed there instead.
>
>    It is also possible to use the SRP (SRemote Password)
>    ciphersuites for shared secret authentication [SRP].  SRP was
>    designed to be used with passwords, and it incorporates protection
>    against dictionary attacks.  However, it is computationally more
>    expensive than the PSK ciphersuites in Section 2."
>
> which is all quite negative, not exactly benefits or applicability; and
> syslog
> went down the fingerprint route so what makes netconf different, why is it
> one
> of those 'limited set of applications'?
>

Maybe I don't understand well your point here; using PSK is optional with
the document and the only mandatory mode to implement is certificate base
authentication.

The Jurgen proposal works for you? (inserting the following sentence at
the end of paragraph 1 of Section 3: "For details concerning pre-shared
key based authentication see [RFC4279]".)

And what is the reason to add fingerprint to Netconf?

Best regards,
Badra

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


ecure Remote Password)
>    ciphersuites for shared secret authentication [SRP].  SRP was
>    designed to be used with passwords, and it incorporates protection
>    against dictionary attacks.  However, it is computationally more
>    expensive than the PSK ciphersuites in Section 2."
>
> which is all quite negative, not exactly benefits or applicability; and
> syslog
> went down the fingerprint route so what makes netconf different, why is it
> one
> of those 'limited set of applications'?
>

Maybe I don't understand well your point here; using PSK is optional with
the document and the only mandatory mode to implement is certificate base
authentication.

The Jurgen proposal works for you? (inserting the following sentence at
the end of paragraph 1 of Section 3: "For details concerning pre-shared
key based authentication see [RFC4279]".)

And what is the reason to add fingerprint to Netconf?

Best regards,
Badra

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