From hosnieh@iknowlaws.de Sat Jan 4 14:35:12 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86FE1AE0B1 for ; Sat, 4 Jan 2014 14:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 UDVcfobo9OgP for ; Sat, 4 Jan 2014 14:35:11 -0800 (PST) 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 00F011AE0AA for ; Sat, 4 Jan 2014 14:35:10 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 4706123E2D55; Sat, 4 Jan 2014 22:35:01 +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 UABwCTMFI5YN; Sat, 4 Jan 2014 23:34:58 +0100 (CET) Received: from kopoli (g225188242.adsl.alicedsl.de [92.225.188.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 6021923E2D36; Sat, 4 Jan 2014 23:34:58 +0100 (CET) From: "Hosnieh Rafiee" To: "'Jerome Athias'" References: <8EBBE4774B42FC45BA1143BE7F3F5A0F169478@MXMA2012.hpi.uni-potsdam.de> <52AF5517.8090705@joelhalpern.com> <05BCCEB107AF88469B9F99783D47C1D60D6771C7@CISEXCHANGE2.msisac.org.local> <8EBBE4774B42FC45BA1143BE7F3F5A0F176CE3@MXMA2012.hpi.uni-potsdam.de> <000c01cf059f$4f578b30$ee06a190$@iknowlaws.de> <000b01cf0616$1c944540$55bccfc0$@iknowlaws.de> <000c01cf0616$bad74130$3085c390$@iknowlaws.de> In-Reply-To: Date: Sat, 4 Jan 2014 23:34:58 +0100 Message-ID: <000001cf099d$3320b250$996216f0$@iknowlaws.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGx40UtNkwuU47TsWzwYWUDFybFxgKE8FArAs/ceo8BcTmCjwI1FideAzua+uABufAw2QJg677sATgJPAiaIyTW4A== Content-Language: en-us Cc: secauth@ietf.org, 'Adam Montville' Subject: Re: [Secauth] Summary of the last discussions X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 22:35:13 -0000 Hi, > well, so, sorry to be off-topic... > If it is assumed that no other works/approaches* are covering these problems > (difficult to judge without use cases), so defining the requirements could help > to start. > http://csrc.nist.gov/projects/abac/index.html > https://downloads.cloudsecurityalliance.org/initiatives/sdp/Software_Defined > _Perimeter.pdf > > My 2bc Thank you for the links. I will check it out. Please consider a week delay in the response. At the moment I'm in time constraints for a work. I'd like to ask everybody to share their opinions about the whole discussions up to now. As far as I can remember, I explained a few of requirements in last posts but probably not enough yet. So, please share your ideas about the expectations for such API from your own points of view. What do you expect to see from this API? Then I will summarize and include my own ideas so that we can proceed faster to come up with the same agreements. Thank you, Smile, Hosnieh From hosnieh@iknowlaws.de Sat Jan 25 13:46:37 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6381A003A for ; Sat, 25 Jan 2014 13:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qmSndScUBFPv for ; Sat, 25 Jan 2014 13:46:35 -0800 (PST) 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 9EBA11A005F for ; Sat, 25 Jan 2014 13:46:34 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 17B1423E2D48 for ; Sat, 25 Jan 2014 21:46:32 +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 5L4Krv9WwdQm for ; Sat, 25 Jan 2014 22:46:29 +0100 (CET) Received: from kopoli (g225190094.adsl.alicedsl.de [92.225.190.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 675DE23E2B25 for ; Sat, 25 Jan 2014 22:46:29 +0100 (CET) From: "Hosnieh Rafiee" To: Date: Sat, 25 Jan 2014 22:46:27 +0100 Message-ID: <000b01cf1a16$e6a5c520$b3f14f60$@iknowlaws.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8aFt7qC5dGDkqWRc2dINqO+sfJFw== Content-Language: en-us Subject: [Secauth] Perspectives and possibilities X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 21:46:37 -0000 Hello, Sorry for a long pause to get back to group again. Recently I tried to categorize all the current security approaches either in network layer or in upper layers. What I found is that most of the applications use either TLS (RFC 6176, 5246, etc.) or SSL (RFC 6101, etc.) as a security mechanisms. Some try to secure the whole communications via the use of VPN (RFC 4026) or IPsec (RFC 4301, 6071, etc.). There are also two security approaches in IPv6 to avoid IP spoofing that is CGA (RFC 3972) and SSAS (http://tools.ietf.org/html/draft-rafiee-6man-ssas ). In IPv4 there is no way to avoid IP spoofing otherwise one uses a certification that is verifiable via a third party trusted authority. So, what I found out is that, the two top popular security approaches are TLS and SSL. You can see the use of them in SSH or in application layer for securing domains or a part of IPsec is also the use of these approaches. Now consider an example scenario using SSH: Node A wants to connect to Node B over the internet using an IP address: at the beginning of this communication before the user A start entering his username and password, he needs to accept the certification of Node B. If the node B certificate is authorized by the a trusted authority (TA) that the name of this TA is listed in the trusted list of Node A, then after Node A verifies this certificates and check this by asking that TA, it does not ask for any confirmation from the user. This only happens once. Next time, the SSH service in Node A stores the information regarding Node B public key and will not process this process again. If Node B has a certification that is not listed in the trusted list of Node A, then it needs to provide Node A with a list of CAs so that Node B can be verified by Node A. One problem here is that, there are some inexpensive certifications that many hosting companies sell them. I mostly see their use for domains and not IP addresses. For buying these certificates, no paper works are required and the certificates is issued for a certain domain and not bounded completely to any person or company! What I can see as a weaknesses here is that, usually the sender node needs to provide the verifier nodes with the list of CAs (usually one or two). Since these certification are not bound to any IP addresses or they are more for a certain domain, then IMHO, the attacker can also play a role in between and provide Node A with a false list that is related to his own fake CA. If Node A really checks all the list up to root certificate (or what it really trusts) then the attacker has no chance to proceed the attack that I am going to explain. But if this doesn't happen and only Node A checks only the first level certificates (this means Node A only asks the fake CA to provide the public key and also the list of CAs and trust this list), or the attacker register domains with no ascii codes (other codes and other language but look similar to the Node B's domain . In this case, the attacker can play a MITM attack and these SSL certificates does not help the node. The reason for such problem.... IP spoofing in network layer. If Node B has a self-generated certification, then the user in Node A will receive a message that asked whether he would like to trust a node with this certification. This is where the attacker can spoof this message and send his own public key to the node. When the initiate phase of the SSL is not secure, then it does not matter whether not user A proceed with any further authentication approach. One possibility to protect the Node A, in my sample scenario, from this attack is the use of the mechanisms used to avoid IP spoofing in network layer. For IPv6 as I explained earlier, it is CGA or SSAS. But CGA is not an ideal solution if one wants to consider all kinds of nodes and consider all situations. I guess, one possibility to start this work while continue this discussion is to have a base mechanism for this API and use this base to extend it and consider all possible problems and improve it until the API become an ideal one. IMHO, SSAS might be an ideal solution, since it is simple and no extra efforts while it also provide the node with the prevention of IP spoofing. For IPv4 we still needs some thoughts. Is it good to have efforts toward having a bounding between IPv4 and IPv6 (if the node supports both). In this case can we come up with an algorithm to provide this bindings? Are we limited because of the subnet prefixes in IPv4? If anybody has any thought about any mechanisms for IPv4, please share it. Any thought about the base of this API? Are we ready to start with the base? Smile, Hosnieh From hosnieh@iknowlaws.de Sat Jan 25 14:21:38 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714611A00A4 for ; Sat, 25 Jan 2014 14:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 dF8I6bSJDQRq for ; Sat, 25 Jan 2014 14:21:37 -0800 (PST) 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 323881A0094 for ; Sat, 25 Jan 2014 14:21:37 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id C401123E2D48 for ; Sat, 25 Jan 2014 22:21:34 +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 gtUG0dT6_Rcv for ; Sat, 25 Jan 2014 23:21:31 +0100 (CET) Received: from kopoli (g225190094.adsl.alicedsl.de [92.225.190.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id B9F3B23E2B25 for ; Sat, 25 Jan 2014 23:21:31 +0100 (CET) From: "Hosnieh Rafiee" To: Date: Sat, 25 Jan 2014 23:21:29 +0100 Message-ID: <001501cf1a1b$cbbf3a20$633dae60$@iknowlaws.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8aG8tat4MGo20wREOcEXgbDQn3Tg== Content-Language: en-us Subject: [Secauth] Follow-up - Perspectives and possibilities X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 22:21:38 -0000 - One of the main problem in most authentications is spoofing. If the authentication is protected by the use of username/password (common authentication approach), fake website, fake DNS, etc. are the possible attacks that enable the attacker to obtain these data even though one use a secure channel like SSL or TLS that I explained in last email. This is why I guess the first step to provide a better secure authentication is to prevent/mitigate IP spoofing in network layer. This can be the point of start and then we can think about whether or not possible to replace the common authentication with a better and more secure one. If so, how?? Please share your comments, whether or not you agree on this point. If you agree whether or not you agree on my proposal for IPv6 networks. Can we have a similar approach in IPv4? Thanks, Smile, Hosnieh From hosnieh@iknowlaws.de Thu Jan 30 14:15:37 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0331A0489 for ; Thu, 30 Jan 2014 14:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 leemn-WokXo8 for ; Thu, 30 Jan 2014 14:15:36 -0800 (PST) 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 26AE71A0486 for ; Thu, 30 Jan 2014 14:15:35 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 8E85C23E2D55 for ; Thu, 30 Jan 2014 22:15:31 +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 4MQEwVOo9ff3 for ; Thu, 30 Jan 2014 23:15:30 +0100 (CET) Received: from kopoli (g229054181.adsl.alicedsl.de [92.229.54.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 2D67623E2D36 for ; Thu, 30 Jan 2014 23:15:30 +0100 (CET) From: "Hosnieh Rafiee" To: Date: Thu, 30 Jan 2014 23:15:29 +0100 Message-ID: <008d01cf1e08$c93466e0$5b9d34a0$@iknowlaws.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8eCMjXWAOc4sGgRTuwKOYNnupPyQ== Content-Language: en-us Subject: [Secauth] Share your idea about the base of the API X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 22:15:37 -0000 Do folks think that the base of the API is ok and can we work on it to extend it? Please share your opinions so that we know what to do. Just share whatever you think. If there is any question and it is not yet clear please also let me know. Then after this step we can decide about the language to use and start it to find its weak points and try to improve it. It would be good if we can have any progress before the upcoming IETF meeting. Thanks Smile, Hosnieh