Re: [http-auth] I-D Action: draft-morand-http-digest-2g-aka-03.txt

Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 04 September 2013 13:49 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A78C21E80D0 for <http-auth@ietfa.amsl.com>; Wed, 4 Sep 2013 06:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 53pjfS68SFHc for <http-auth@ietfa.amsl.com>; Wed, 4 Sep 2013 06:49:14 -0700 (PDT)
Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id E448921F94FF for <http-auth@ietf.org>; Wed, 4 Sep 2013 06:49:13 -0700 (PDT)
Received: by mail-bk0-f50.google.com with SMTP id mz11so186127bkb.37 for <http-auth@ietf.org>; Wed, 04 Sep 2013 06:49:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cYQna2CZ4tFZios7DchVJJfe5ZICY3dN/eIMqxTV64Y=; b=tV8pGgMxRFROZ3HgJ0pRcs/4k4I9/nBFtD7rSuCjce+fHL/ZrV9VN3WCptvrfFYHzR pLi85Ccgp6tG7Oq/uI6WrCFVAl4w3BGWIWlvhKKtirE1WWGammH06vhB3lby+nO7Bf3R yng+qrliKBlHFzqTy2J9loAepunF6Wi7vEVTo3ulcZmMCMVPYtEV/lkxAsdASSTeae/u OcNFMLDZ2Nk6alOccGgTnNP+/oouNTIBEKx87HKFWrT0ueXji6h2NJiaZassd2qCpsIC aogmk3H0/6kuBMeDrI2KgLL3/ayE24PTNtJ6Ux81228+Xe93TGu/kmD2m5FwwIDSLYwj gGxg==
X-Received: by 10.204.71.133 with SMTP id h5mr2669453bkj.0.1378302552892; Wed, 04 Sep 2013 06:49:12 -0700 (PDT)
Received: from [10.0.0.8] (bzq-79-182-222-201.red.bezeqint.net. [79.182.222.201]) by mx.google.com with ESMTPSA id rj5sm3281936bkb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Sep 2013 06:49:12 -0700 (PDT)
Message-ID: <52273A55.6050201@gmail.com>
Date: Wed, 04 Sep 2013 16:49:09 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: lionel.morand@orange.com
References: <20130121181639.10474.27297.idtracker@ietfa.amsl.com> <5225E5BD.9040306@ieca.com> <D4896BEB-F6BA-4712-8345-96CA945020FC@checkpoint.com> <52265596.9090604@gmail.com> <22825_1378299137_52272D01_22825_6326_1_6B7134B31289DC4FAF731D844122B36E262094@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <22825_1378299137_52272D01_22825_6326_1_6B7134B31289DC4FAF731D844122B36E262094@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "<http-auth@ietf.org>" <http-auth@ietf.org>
Subject: Re: [http-auth] I-D Action: draft-morand-http-digest-2g-aka-03.txt
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-auth>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2013 13:49:15 -0000

Hi Lionel,

I would recommend to include your clarification in the document, and if 
possible, references to the relevant documents. In a world where many 
phishing attacks use valid certificates 
(http://www.thewhir.com/web-hosting-news/report-netcraft-sees-valid-ssl-certificates-on-phishing-sites), 
saying "just use TLS" is unfortunately not enough.

Thanks,
	Yaron

On 09/04/2013 03:52 PM, lionel.morand@orange.com wrote:
> Hi Yaron,
>
> I was assuming that the TLS specific requirements could have been left out of this document, as these requirements/recommendations can be found in other documents (e.g. RFCs or 3GPP specifications) and it is assumed that people using such TLS certificate-based server authentication will refer to them.
>
> In the mobile context, it is assumed that the client uses a preconfigured list of trusted root certificates for server certificate validation. The use of a small set of CAs trusted by the home mobile operator limits the risk of root certificates associated with a compromised CA.
>
> I don't know if such details are needed in the doc. What would be your recommendation?
>
> About Independent Submission vs. WG document, as I said, I have no strong opinion. It was concluded that the mechanism was maybe too specific to be part of the new httpauth WG charter. The same conclusion was reached about the discussion on moving RFC3310 (Digest 3G AKA) from informational to Proposed Standard RFCs. There was no intention to bypass any specific expertise. The idea is just to document within IETF the Digest 2G AKA mechanism, as a companion of the RFC3310.
>
> Regards,
>
> Lionel
>
> -----Message d'origine-----
> De : Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
> Envoyé : mardi 3 septembre 2013 23:33
> À : Yoav Nir
> Cc : Sean Turner; <http-auth@ietf.org>; MORAND Lionel IMT/OLN
> Objet : Re: [http-auth] I-D Action: draft-morand-http-digest-2g-aka-03.txt
>
> While I agree with Yoav that this draft requires expertise that we
> (httpauth) probably do not have, I also have a major issue with the draft.
>
> Although TLS is proposed as a solution for mutual auth, there are no
> requirements on the server's identity and so there is no way specified
> to actually authenticate the server.
>
> As a result, I suspect that this method can be used by a MITM attacker
> to impersonate another IMSI ("user" in common terms) for regular
> AKA-based authentication.
>
> Thanks,
> 	Yaron
>
> On 09/03/2013 08:39 PM, Yoav Nir wrote:
>> Hi Sean,
>>
>> Looking over the discussion in httpbis ([1]), it's not clear to me whether this is documenting existing practice or whether it's proposing a new method. Either way, this method seems specific to a domain, where I believe the author has much more expertise than people in the working group. I am personally fine with it proceeding as an independent submission. I would also be fine with the working group discussing this, but I don't know how much value we could add.
>>
>> Yoav (with no hats)
>> [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0375.html
>>
>> On Sep 3, 2013, at 4:35 PM, Sean Turner <turners@ieca.com> wrote:
>>
>>> Hi!
>>>
>>> The following draft is currently on the IESG telechat for next week and as part of the process an AD does what's called and "RFC 5742 review", which is basically a check to see if there's been an endrun on the process.   This draft has been around for a while and I know it was at least discussed on the httpbis wg mailing list in early '12 (and maybe even earlier), but that was before the httpauth working group was chartered.  So I gotta ask: Is this something that the working group should consider adopting?
>>>
>>> spt
>>> -------- Original Message --------
>>> Subject: I-D Action: draft-morand-http-digest-2g-aka-03.txt
>>> Date: Mon, 21 Jan 2013 10:16:39 -0800
>>> From: internet-drafts@ietf.org
>>> Reply-To: internet-drafts@ietf.org
>>> To: i-d-announce@ietf.org
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>> 	Title           : Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G Authentication and Key Agreement (AKA)
>>> 	Author(s)       : Lionel Morand
>>> 	Filename        : draft-morand-http-digest-2g-aka-03.txt
>>> 	Pages           : 15
>>> 	Date            : 2013-01-21
>>>
>>> Abstract:
>>>     This memo specifies a one-time password generation mechanism for
>>>     Hypertext Transfer Protocol (HTTP) Digest access authentication based
>>>     on Global System for Mobile Communications (GSM) authentication and
>>>     key generation functions A3 and A8, also known as GSM AKA or 2G AKA.
>>>     The HTTP Authentication Framework includes two authentication
>>>     schemes: Basic and Digest.  Both schemes employ a shared secret based
>>>     mechanism for access authentication.  The GSM AKA mechanism performs
>>>     user authentication and session key distribution in GSM and Universal
>>>     Mobile Telecommunications System (UMTS) networks.  GSM AKA is a
>>>     challenge-response based mechanism that uses symmetric cryptography.
>>>
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-morand-http-digest-2g-aka
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-morand-http-digest-2g-aka-03
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-morand-http-digest-2g-aka-03
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>
>>>
>>> _______________________________________________
>>> http-auth mailing list
>>> http-auth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/http-auth
>>
>> _______________________________________________
>> http-auth mailing list
>> http-auth@ietf.org
>> https://www.ietf.org/mailman/listinfo/http-auth
>>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>