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

[<[e-mail]>]

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:[e-mail]] 
Envoyé : mardi 3 septembre 2013 23:33
À : Yoav Nir
Cc : Sean Turner; <[e-mail]>; 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 <[e-mail]> 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: [e-mail]
>> Reply-To: [e-mail]
>> To: [e-mail]
>>
>>
>> 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
>> [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/http-auth
>
> _______________________________________________
> http-auth mailing list
> [e-mail]
> 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.