Re: [VoT] Security Problem with Primary Credential Usage

Julian White <jwhite@nu-d.com> Thu, 12 May 2016 18:49 UTC

Return-Path: <jwhite@nu-d.com>
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 DF30A12B04A for <vot@ietfa.amsl.com>; Thu, 12 May 2016 11:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nu-d.com
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 upnDUVFvGMaT for <vot@ietfa.amsl.com>; Thu, 12 May 2016 11:49:19 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC0412D0BE for <vot@ietf.org>; Thu, 12 May 2016 11:49:18 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id e201so270014794wme.0 for <vot@ietf.org>; Thu, 12 May 2016 11:49:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nu-d.com; s=nud; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jkxNcaMrXYhBsovXV9wcTz9g8239yrDmdgm2lqEJ4/Y=; b=DzEljVDhDR1+55iAjNYJrSIhNHzUuaObGPt205hdTNnjK8WEXtVqml3adaIFXar4ng fTT9qE4bc+mOLNqDwBdbjxP5FUAEumSwCgRQxTgdZTmMOS/x/XSmVnmwgZUAx77giVcd Gp0U4f5TRTZcpGEwaRJwLo8lQtQrfz4m1gw9Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jkxNcaMrXYhBsovXV9wcTz9g8239yrDmdgm2lqEJ4/Y=; b=MgB0qAJFXYOlKn1vbtzOFu9AfYu3dMRtuSs4heXlunF2GISZ+nbW51NJ5b4Pv5HdAE kxJyGMIJUkH5zUNc/Z1rEXwcfkYWYNjJbpYfbMWh0n8S5u9uviuaMhnaFPYgcTfkFIma mZYFm1p1+7FLjUGpOAPX3LFIGlCLAo676mtTiTnZh6DqgXP8FT8rMh85VRLVfm3I6jPy 5dSD4vAgo8cnbuXaj149KY9ASuyfNJ+Bja/jT23oUonY1UA6X2zj6iDWbcLqjzsF53ZF KuMJR3i4C02Hr/XimYVuC+EOOkK1JeSwaZAdFXOhios3XB7UTFOi39qjCc6XDM/YIH2h ZMaQ==
X-Gm-Message-State: AOPr4FUFUKBq1o8Vc25lRIyYoRcaB8M/wyyP6lPNcaoPfqD/U8NANBetjk2T7omV/AE0RE0L/XQAC35NAJznWm1o
MIME-Version: 1.0
X-Received: by 10.28.150.211 with SMTP id y202mr12388683wmd.41.1463078956903; Thu, 12 May 2016 11:49:16 -0700 (PDT)
Received: by 10.194.202.130 with HTTP; Thu, 12 May 2016 11:49:16 -0700 (PDT)
Received: by 10.194.202.130 with HTTP; Thu, 12 May 2016 11:49:16 -0700 (PDT)
In-Reply-To: <753DBE1F-3891-4BB6-811B-5B8682A81A28@mit.edu>
References: <1523279479.20160508222427@CryptoPhoto.com> <CAL4gWiJDg4CDFpwGm-AAJXig9f8HXYNyCRUrm+yirs5ntSfiNw@mail.gmail.com> <753DBE1F-3891-4BB6-811B-5B8682A81A28@mit.edu>
Date: Thu, 12 May 2016 19:49:16 +0100
Message-ID: <CAL4gWiJJtsEPk=5+vrtQpx4zsV04jjtZPh0CpxZs7cPBJxJa5w@mail.gmail.com>
From: Julian White <jwhite@nu-d.com>
To: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary=001a114b2d188185bf0532a99dd8
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/2kTY0fB1UTuSsFrEmw2oNaNgMjQ>
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: Thu, 12 May 2016 18:49:22 -0000

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> 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> 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> 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 (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
>> https://www.ietf.org/mailman/listinfo/vot
>>
>>
> <draft-richer-vectors-of-trust-02.docx>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
>
>
>