Re: [VoT] Security Problem with Primary Credential Usage

Julian White <> Fri, 13 May 2016 11:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28BCF12B01C for <>; Fri, 13 May 2016 04:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Y6IBWI7cjOe for <>; Fri, 13 May 2016 04:12:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ECEA812B063 for <>; Fri, 13 May 2016 04:12:35 -0700 (PDT)
Received: by with SMTP id e201so18173262wme.0 for <>; Fri, 13 May 2016 04:12:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=nud; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VAcA0Fa1GtqxwFEDzJpAVRdEV/cXPJi54wxa+vgq5gI=; b=LAlykvajPxYVaAXUPCgFPZWALfkw4B9ir7LdZdxJoeLGVUos6QPa3cH7Tr45HQkQRZ idy9tLYENnMXDHyTfDVEewmKvxGzL+zCun7hYZdw05BMep0F2NVq6WkhgG4DN/Ch3CbJ g1cQrlMyRqaZ6JmUs7kIRg+Bcv4u4YOhipDqU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VAcA0Fa1GtqxwFEDzJpAVRdEV/cXPJi54wxa+vgq5gI=; b=OIynN1BiVGxvrmS76CDIi0jzuQGdLIH6Q3TirksE+SD0gCRNieF9dioG4ag837P0N6 pQlL2s+HmQcdYE+ZKTXg9EhHFveK6XDMT0/ayk0yOLKXQIP06xPmdIsV8X6r3othkSV9 yd/7luIBVANoF5QK+vU6CNSE1OlWSjYFeuLArTb5kJ8foDTpkSN/DvzMbNL6lMs0S5xl Z/W38oMpzU9ncGtWjVFamYvlCTjZcm/r7q2iuA9ofMjr8UIn4d1VGSB7mP8nKShJpYo2 n95U0Xst4Qx3tdjgCkwmKINuc091hXPXb2xosK8pdx7izTOgLRIsMdaWaMKyIYOe47rV Eb7Q==
X-Gm-Message-State: AOPr4FXiHXa5TOpJDqKIHxgJ41Epg4t8nPNYC3Xr+v/MA/0COhqvWn7SRMLK1tOBc8KLxPSMd19ozLvZacECVZW3
X-Received: by with SMTP id s12mr3152036wmb.54.1463137954287; Fri, 13 May 2016 04:12:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 13 May 2016 04:12:14 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Julian White <>
Date: Fri, 13 May 2016 12:12:14 +0100
Message-ID: <>
To: Chris <>
Content-Type: multipart/alternative; boundary=001a11468d3005fe5c0532b75a89
Archived-At: <>
Cc:, Justin Richer <>
Subject: Re: [VoT] Security Problem with Primary Credential Usage
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Vectors of Trust discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 May 2016 11:12:39 -0000


Yes I see your point, so the RP should assert with which trustmarks it
complies too?


On 13 May 2016 at 10:48, Chris <> wrote:

> Hi Julian,
> It is like I said at the start.  The entirety of the trustmark idea
> evaluates to one single strength - everything is equally untrustworthy,
> because it's all only unidirectional.
> You can't solve trust without fixing BOTH ends.  It is a *two-way *street.
> For as long as a user and proxy are indistinguishable, C0 == Ca == Cb == Cd
> == Ce == Cf.
> I know it sounds like a little problem, but so was the debris on that last
> Concorde's runway.  This is the show stopper.
> Chris.
> Friday, May 13, 2016, 5:52:55 PM, you 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 <> 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" <> 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 <> 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 <> wrote:
> Hi All,
> I think there is a critical flaw in section 3.2 of
> (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
> <draft-richer-vectors-of-trust-02.docx>_______________________________________________
> vot mailing list
> _______________________________________________
> vot mailing list