Re: [dane] Reviewers needed - Secure DNS authentication

Warren Kumari <warren@kumari.net> Sat, 28 September 2013 01:03 UTC

Return-Path: <warren@kumari.net>
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 BC95821F9A31; Fri, 27 Sep 2013 18:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Level:
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
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 YICY9RFkGsJ6; Fri, 27 Sep 2013 18:03:51 -0700 (PDT)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC4621F90DC; Fri, 27 Sep 2013 18:03:50 -0700 (PDT)
Received: from [10.243.40.142] (mobile-198-228-224-005.mycingular.net [198.228.224.5]) by vimes.kumari.net (Postfix) with ESMTPSA id EFA381B400DE; Fri, 27 Sep 2013 21:03:48 -0400 (EDT)
References: <002601cebbce$c37c3f80$4a74be80$@rozanak.com>
In-Reply-To: <002601cebbce$c37c3f80$4a74be80$@rozanak.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Message-Id: <B8A15455-A272-4B31-B431-57C9F24BC269@kumari.net>
X-Mailer: iPhone Mail (11A465)
From: Warren Kumari <warren@kumari.net>
Date: Fri, 27 Sep 2013 21:03:46 -0400
To: Hosnieh Rafiee <ietf@rozanak.com>
Cc: perpass <perpass@ietf.org>, "<dane@ietf.org>" <dane@ietf.org>
Subject: Re: [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: Sat, 28 Sep 2013 01:03:55 -0000

I'm sorry, but this is not related to DANE (nor was it last time you came shopping around).

I (of course) have no problem with folk reviewing it, just making it clear that it isn't a DANE thing...

W

Warren Kumari
------
Please excuse typing, etc -- This was sent from a device with a tiny keyboard.

> On Sep 27, 2013, at 6:13 PM, "Hosnieh Rafiee" <ietf@rozanak.com> wrote:
> 
> 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??? :-)
> 
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
>