[Ace] a possible solution candidate?

"Hosnieh Rafiee" <ietf@rozanak.com> Tue, 11 March 2014 18:55 UTC

Return-Path: <ietf@rozanak.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355C31A07B5; Tue, 11 Mar 2014 11:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf9j4uqAPInM; Tue, 11 Mar 2014 11:55:36 -0700 (PDT)
Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 1138A1A077D; Tue, 11 Mar 2014 11:55:33 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 7933B23E24C2; Tue, 11 Mar 2014 18:55:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at rozanak.com
Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRhVMWAAjeSJ; Tue, 11 Mar 2014 19:55:21 +0100 (CET)
Received: from kopoli (g226057108.adsl.alicedsl.de [92.226.57.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 298AD23E24BC; Tue, 11 Mar 2014 19:55:21 +0100 (CET)
From: Hosnieh Rafiee <ietf@rozanak.com>
To: Ace@ietf.org
Date: Tue, 11 Mar 2014 19:55:19 +0100
Message-ID: <00f101cf3d5b$736152b0$5a23f810$@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: Ac89W3Ggj+VLatgRRfeVFuptbnG7TA==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/oZGutxBZ_IVqz0xMAZq3W-5hzsU
Cc: secauth@ietf.org
Subject: [Ace] a possible solution candidate?
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Mar 2014 18:55:38 -0000

Hi,

I just get to know this WG during IETF in London. Since I am also working in
secure authentication and authorization in a non-WG group (CC), but in
general and not only for constrained devices. In other words, the scope of
your mailinglist is a small part of that. The outcome of secauth will be an
API that allows the application layers' services or other layers' services
to use this API for authentication purposes. Based on the needs, one can
also integrate it with other approaches an duse it for securer
authentication and at the same time avoid IP spoofing. This is why the work
of this mailinglist grabbed my attention. Before IETF I was in a process of
preparing a requirement document for using a network layer approach for
authentication in other layers and still working on it (probably you can
read more about my purpose there). One of the solution space approach that I
thought might be useful for the start was one of my draft that is called
SSAS (http://tools.ietf.org/html/draft-rafiee-6man-ssas ).
-----The new version of this draft will be coming soon (I know the current
version is messy.. :-| )------

I thought maybe you also find it useful as a candidate solution for your
authentication purposes. I try to explain how SSAS can be helpful

General advantages
-  Prevent IP spoofing (binding between the public key and the IP address)
- The authentication can be only based on IP address (or one can also
integrate it with other approaches)
- Since IP spoofing can prevents other attacks such as MITM, TCP/UDP
amplifications, 
- It uses a short key size algorithm so that it avoids the use of large
memories

Some of other advantages:
- It is enough that the two communication nodes only know the IP address of
each other, then they can ensure that there is no MITM.
- It does not need to check the keys up to certain level to ensure that this
key belongs to this node with this IP address (like what is needed for TLS
if one wants to ensure about the key authorization).
-  It doesn't need to buy a certificate for each single nodes in order to
provide the node with a secure TLS or SSL authentication
etc.



At the moment I integrated this approach for DNS confidentiality, data
integrity and secure authentication (please refer to these slides
http://www.ietf.org/proceedings/89/slides/slides-89-dnsop-2.pdf ). I also
saw a paper that integrated SSAS as a secure authentication purposes in SIP
protocol. This is because in SIP, an attacker can easily spoof the identity
of the two ends of communication nodes. Since SSAS prevents IP spoofing,
this prevents identity spoofing as well (if the identity is the IP address).

One disadvantage of this approach was that it only supports iPv6, I also
tried to cover it (Please check the approach in the slides for CGA-TSIG).
So, the support of IPv4 will appear in the next version of draft. 

If you have any question, do not hesitate to ask.

Thanks,
Best,
Hosnieh