[Dots] SEC-001: draft-ietf-dots-requirements

<mohamed.boucadair@orange.com> Tue, 02 May 2017 07:49 UTC

From: mohamed.boucadair@orange.com
To: "Mortensen, Andrew" <amortensen@arbor.net>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: SEC-001: draft-ietf-dots-requirements
Thread-Index: AdLDF+enKpBDbqwnQrGmOMdIQdKVGg==
Date: Tue, 02 May 2017 07:44:20 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E5F447@OPEXCNORMAD.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E5F447OPEXCNORMADcorp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/BRmLPCbeBNDPXjCqJO0CbJX02Oc>
Subject: [Dots] SEC-001: draft-ietf-dots-requirements
Precedence: list

Re-,

   SEC-001  Peer Mutual Authentication: DOTS agents MUST authenticate
      each other before a DOTS session is considered valid.  The method
      of authentication is not specified, but should follow current
      industry best practices with respect to any cryptographic
      mechanisms to authenticate the remote peer.

Shouldn't that mutual authentication be relaxed to not only mention cryptographic mechanisms, but to cover the case of trusted domains that may leverage on existing tools to authenticate/authorize DOTS clients?

Leveraging on existing tools is motivated by various reasons:

*         minimize provisioning data on the CPE because that data may be lost due to a system crash (and therefore lead to calls to the hotline).

*         If credentials to authenticate the DOTS server are provisioned anyway by the provider on the CPE, this biases the DOTS server authentication. Trusting the DOTS server provisioned by the provider + authenticate the DOTS client provides the same protection level.

Cheers,
Med

[Dots] SEC-001: draft-ietf-dots-requirements mohamed.boucadair