[dane] Reviewers needed - Secure DNS authentication

"Hosnieh Rafiee" <ietf@rozanak.com> Fri, 27 September 2013 22:13 UTC

Return-Path: <ietf@rozanak.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2897621F8E51; Fri, 27 Sep 2013 15:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8vjCJ-lSXDH; Fri, 27 Sep 2013 15:13:22 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id F1A4E21F9808; Fri, 27 Sep 2013 15:13:19 -0700 (PDT)
Received: from kopoli (g225191041.adsl.alicedsl.de [92.225.191.41]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MQzYs-1VHXqn3j3O-00U5Ui; Fri, 27 Sep 2013 18:13:18 -0400
From: Hosnieh Rafiee <ietf@rozanak.com>
To: perpass <perpass@ietf.org>, dane@ietf.org
Date: Sat, 28 Sep 2013 00:13:10 +0200
Message-ID: <002601cebbce$c37c3f80$4a74be80$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac66GAmkrg604EBOQj6E9T/FIDhOTg==
Content-Language: en-us
X-Provags-ID: V02:K0:qHdZjREDdYsBxNOj/2+4SNOj6BexqynEi7n9Cn6tbfT MYuQCJe6abQcytQphj0p7kpwJywBjB9AIRS2DQXNxZNEFDOESi rlWAZldg+mQn4fC+Ebif+WKUp9Zg4HH0PaIrShzOfBfm90PKuq WVb29YgKgcw/hOtOpAaRg0zBDSkQsKxwIwdBswV3iE8x5qfdLE VW8cN4rve8tgNGitmcjqACzhctR07BwocRhSnax9BPMRttm+rj Mc3r8iaqi8C95s8tppNfZEgoJrOAP34urGzBB0NMBPTMP4vdp8 3CGY6yKE5YyWhqdl+dpcw/Hmhd88o3Z4/bLGCAv0Vo/vX+00ZW nnD4IKh63iE96pJgwELk=
Subject: [dane] Reviewers needed - Secure DNS authentication
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2013 22:13:27 -0000

Hello,

I am looking for reviewers to review the
http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig draft. It deals
with the use of CGA (RFC 3972) or SSAS for authentication purposes during
various types of scenarios. This is truly possible when the authentication
is based on the source IP address. Everything in this authentication is done
"on the fly" and only once is there a need to configure the Servers.
Advantages:
- If the shared secret is compromised (which is true in TSIG, you won't need
to repeat the process of re-sharing the shared secret among the many hosts
that used the compromised shared secret)
- If for any reason the IP address of any nodes involved in authentication
is changed, then the other nodes will  still be able to verify that it is
the same node
- It is both easier and preferable to use this approach to prove the address
ownership while at the same time performing source IP address
authentication.
- The nodes don't need to go through the chain of trusts  because the magic
of CGA or SSAS works well. This means that if the other nodes are aware of
one node's real IP address then that is all the information the other nodes
need  to identify this node. No matter how your node changes its IP address.
This draft explains how to easily handle this situation, automatically,
without the need for human intervention. 
I am sure you will find it interesting. 

The different scenarios that are considered are:
- Authentication during FQDN
- Authentication during zone transfer
- Authentication of the resolvers in stub resolvers
- Authentication of root DNS servers to recursive DNS servers

We also considered the scenario where the server doesn't support CGA or
SeND. The interesting thing about this draft is that you can use a CGA
script generator that I will provide and make available to everybody. Then
just manually set the IP address for the node that wants to use CGA-TSIG.
The CGA-TSIG implementation will thereafter  processes the handling for all
the CGA parameters. 

This scenario is good for the future of the Internet where IPv6 is used. I
guess many DNS servers now support IPv6 as well as IPv4. 

I am looking forward to receiving your comments. 

Thank you,
Hosnieh
P.S. So if you'll review mine i'll review yours.. Deal??? :-)