Re: [VoT] Security Problem with Primary Credential Usage

Justin Richer <jricher@mit.edu> Fri, 13 May 2016 22:39 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F6A12D620 for <vot@ietfa.amsl.com>; Fri, 13 May 2016 15:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.216
X-Spam-Level:
X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Yslr6O8rbROy for <vot@ietfa.amsl.com>; Fri, 13 May 2016 15:39:23 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E1612D171 for <vot@ietf.org>; Fri, 13 May 2016 15:39:23 -0700 (PDT)
X-AuditID: 1209190d-fdbff700000076cb-88-573657993f1c
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 32.D3.30411.99756375; Fri, 13 May 2016 18:39:21 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u4DMdLmB025433; Fri, 13 May 2016 18:39:21 -0400
Received: from [192.168.1.80] (104-13-170-63.lightspeed.austtx.sbcglobal.net [104.13.170.63]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u4DMdGe3029940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 May 2016 18:39:19 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_F783372A-7191-40A3-9F48-ACB23E3C33A4"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <CAL4gWiLS+Z15QApwLTiLw4rT8xQW4ALQL5aP6BD0=m6RxvMLSg@mail.gmail.com>
Date: Fri, 13 May 2016 17:39:16 -0500
Message-Id: <6C12DA4D-839A-4C1A-813D-988E8318220C@mit.edu>
References: <1523279479.20160508222427@CryptoPhoto.com> <CAL4gWiJDg4CDFpwGm-AAJXig9f8HXYNyCRUrm+yirs5ntSfiNw@mail.gmail.com> <753DBE1F-3891-4BB6-811B-5B8682A81A28@mit.edu> <CAL4gWiJJtsEPk=5+vrtQpx4zsV04jjtZPh0CpxZs7cPBJxJa5w@mail.gmail.com> <CAL4gWiLS+Z15QApwLTiLw4rT8xQW4ALQL5aP6BD0=m6RxvMLSg@mail.gmail.com>
To: Julian White <jwhite@nu-d.com>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR4hRV1p0ZbhZu0PjSxmLlp++MFuvXn2K0 aPj5gNWB2ePStgnMHkuW/GTyaPnQwRbAHMVlk5Kak1mWWqRvl8CVcfb7WcaCqZUVK26/ZWtg vJvWxcjJISFgInHw3VymLkYuDiGBNiaJzncP2SGcjYwSi5c3MkM4t5gk/hzbwgrSwiyQILFp wntGEJtXQE9i0/q3TCC2sICjxP/mE+wgNpuAqsT0NS1AcQ4OToFAiZsfwUpYgMLfV/9lhBij KbFrejM7xBgridvz1rNC7NrKJLGm7TkbSEJEQEnibPdKVohTZSWenFzEMoGRfxaSM2YhOQMi ri2xbOFr5llQO/Z3L2fBFNeQ6Pw2kXUBI9sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXSO93MwS vdSU0k2M4HCX5N3B+O+u1yFGAQ5GJR7eBCXTcCHWxLLiytxDjJIcTEqivOkmZuFCfEn5KZUZ icUZ8UWlOanFhxglOJiVRHjTw4ByvCmJlVWpRfkwKWkOFiVx3pibR8OEBNITS1KzU1MLUotg sjIcHEoSvBEgjYJFqempFWmZOSUIaSYOTpDhPEDD40NBhhcXJOYWZ6ZD5E8xKkqJ8+qANAuA JDJK8+B6Qekog3eV/StGcaBXhHnPgVTxAFMZXPcroMFMQIOrrxuBDC5JREhJNTAyfsnnOWWi NV1EobLZKKx4fuWPEMFLLFz+8bIiej9uXcvqUF10VvrKifMLPwgWHWvwmZm4M2L55pdhbpsy TJSd5BSPHEhi/Vl18pjI05pVPW2Pk9Ye/L2t6MvjUl22b/HXHb0/3fm76+U/+R9TFH4fYplw nFGjj40hvbUyae7l4pti7Y1b9x1SYinOSDTUYi4qTgQAbMXTviIDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/GG-9RARNq-kWYxww8n9PMJuol5o>
Cc: Chris <cnd@geek.net.au>, vot@ietf.org
Subject: Re: [VoT] Security Problem with Primary Credential Usage
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Vectors of Trust discussion list <vot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vot>, <mailto:vot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/vot/>
List-Post: <mailto:vot@ietf.org>
List-Help: <mailto:vot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vot>, <mailto:vot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2016 22:39:27 -0000

That seems like a reasonable mechanism, though this is the first it’s been brought up. It was only in the last revision or so that we really tied the vector tightly to the trustmark concept, which itself needs to be more fully defined outside of the VoT concept.

 — Justin

> On May 13, 2016, at 2:52 AM, Julian White <jwhite@nu-d.com>; wrote:
> 
> Justin,
> 
> For my own clarity, can the RP pass a request for a specific trustmark, or list of trustmarks that it will accept? The text seems to imply that they will get whatever trustmark the IdP sends and have to make a decision based on that each time. In reality, since the evaluation of the trustmark is a cumbersome manual process I suspect RP's will whitelist trustmarks that they will accept so then it seems inefficient for and IdP to return a response under a trustmark the RP won't accept.
> 
> Thanks,
> 
> Julian.
> 
> On 12 May 2016 at 19:49, Julian White <jwhite@nu-d.com <mailto:jwhite@nu-d.com>> wrote:
> That makes sense, tho that didn't come across in the description of the trustmark.
> 
> Julian
> 
> On 12 May 2016 19:45, "Justin Richer" <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
> We explicitly left those kinds of things out of the vector as they’d really be related to the IdP itself and not the authentication transaction to which the VoT refers. In other words, the security of the IdP is related to the trust framework and assessment of the IdP and it can be published as part of the IdP’s discovery documents and associated trust marks. This is information that is going to remain the same regardless of the transaction. 
> 
> This is also part of why you need to have a trustmark context to interpret the VoT in.
> 
>  — Justin
> 
>> On May 12, 2016, at 11:11 AM, Julian White <jwhite@nu-d.com <mailto:jwhite@nu-d.com>> wrote:
>> 
>> Hi,
>> 
>> I have a number of comments and questions (see attached), many of which are related to the issues raised by Chris, some maybe my misunderstanding coming in half way through the drafting tho.
>> 
>> I, like Chris, also think there needs to be something more explicit around the "security" of the IdP authentication which includes the measures to try and detect 'odd' things (like MITM). I would also go one step further in that I also want to know about the maturity of the IdP's "security", its of no use to me if they have really good credentials but store all the data in the clear on their website or have a load of administrative back-doors that could let anyone generate a valid authentication response.
>> 
>> It feels like we need to do more work in this area.
>> 
>> Regards,
>> 
>> Julian.
>> 
>> On 8 May 2016 at 13:24, Chris <cnd@geek.net.au <mailto:cnd@geek.net.au>> wrote:
>> Hi All,
>> 
>> I think there is a critical flaw in section 3.2 of https://tools.ietf.org/html/draft-richer-vectors-of-trust-02 <https://tools.ietf.org/html/draft-richer-vectors-of-trust-02> (Primary Credential Usage)
>> 
>> Mutual-authentication is missing.  When no provision is made to prevent man-in-the-middle, credential harvesting, spoof, phishing, malware, or other common threats, this renders all possible vectors C0, Ca, Cb, Cd, Ce, Cf, and others equally untrustworthy.
>> 
>> We should consider inclusion either for the overall strength of the authentication process, or some breakdown of either all the techniques used or the strength of protection employed to thwart at least common attack scenarios.
>> 
>> This problem gets tricky quite fast:
>> 
>> Do we identify the authentication technology vendor? (if yes - who works out their resistance strength to common attacks?  what about different modes?)
>> Do we broadly identify the techniques (whos opinions count as to whether or not the technique is effective and against what threats?)
>> Do we identify or classify the threats and indicate which ones were mitigated (who should be trusted to decide if these really were mitigated?)
>> 
>> For example - tamper-proof hardware digital certificate devices with biometrics unlocks are totally useless, if the user paid no attention to a broken SSL warning, or has malware.  They're also equally useless in most corporate environments that use deep-packet inspection firewalls - and "unexpected certificates" (eg. from DPI or malicious) carry their own privacy problems (eg: passwords are not as "protected" as you think).  Much more common authentication "protection" of course, are two-step or sms one time codes - which are equally useless when an end user can be tricked into revealing them to spoof sites.
>> 
>> 91% of successful break-ins start from phishing.  Right now, every vector is pointing one way - we need at least one "Vector of Trust" to point back the other way!  
>> 
>> How about a 5th vector - "S" for "Security", which somehow allows an RP a level of confidence in the protection afforded to the user's actual authentication process, in terms of (or at least considering) a wide range of (and all common) modern threats.
>> 
>> Chris.
>> 
>> _______________________________________________
>> vot mailing list
>> vot@ietf.org <mailto:vot@ietf.org>
>> https://www.ietf.org/mailman/listinfo/vot <https://www.ietf.org/mailman/listinfo/vot>
>> 
>> 
>> <draft-richer-vectors-of-trust-02.docx>_______________________________________________
>> vot mailing list
>> vot@ietf.org <mailto:vot@ietf.org>
>> https://www.ietf.org/mailman/listinfo/vot <https://www.ietf.org/mailman/listinfo/vot>
> 
>