[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
- [Ace] a possible solution candidate? Hosnieh Rafiee
- Re: [Ace] a possible solution candidate? Hannes Tschofenig
- Re: [Ace] a possible solution candidate? Hosnieh Rafiee
- Re: [Ace] a possible solution candidate? Hannes Tschofenig
- Re: [Ace] a possible solution candidate? Hosnieh Rafiee
- Re: [Ace] a possible solution candidate? Hannes Tschofenig