Re: [VoT] Security Problem with Primary Credential Usage

Julian White <> Thu, 12 May 2016 16:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C37D212D1DF for <>; Thu, 12 May 2016 09:12:15 -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 5OEumswzWQmM for <>; Thu, 12 May 2016 09:12:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F049612D1B4 for <>; Thu, 12 May 2016 09:12:11 -0700 (PDT)
Received: by with SMTP id g17so144486027wme.1 for <>; Thu, 12 May 2016 09:12:11 -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=LmN1bQlBrWe3DbKC8SCpVplmIiG6FeoRmnd+UQZs2r4=; b=X34QqQR40ZWn9CAn1A8abFXJ5E+RQXIXlSEtlHeFdyfScdKq6qDYg9ekk9NXZhnP/a ETk3E38eKvwbUhB83hJ5cCCVmMkmLHUIAXknzMHi0A5jmo89pRugmuIDkMZoJrkgOpp0 THeq3Qc7ypeIYRoEGXsOsqWpLlkIbdnufYY+w=
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=LmN1bQlBrWe3DbKC8SCpVplmIiG6FeoRmnd+UQZs2r4=; b=co1ei74FrNvQbWJLbOPqlNVZVxnPUBVN51yS8/yDjk0Gs5U2TLtF0m/L4gVvEJ9gjd xw3YnjBKc7a30fuvnTawD10E0Uo5m498do+30GgJ4n9gkZGJzOotgVATREuzDk84aRVD +B559htxBO7QFQWhB3sbMk6k9p+y1I1y10+SQLknD2jj8+avHCWARhw85U8mglBJwcIH mxFA9TUpbPDunTpTCaOBcTEERITD80NZDWd+TYKipc/IOfmGilPrysoVlmbmhOY1S+YS xr5fGzVtc+ZOqUgO6/AkQC5zsF3NG5JJhFYdgQTqjTlLdUT/IZAXlTeq/tHiySRKoL/h KGVQ==
X-Gm-Message-State: AOPr4FUQnCgNPp2WgCZDUd9iPvcT1u1GhY8SDqGWGF6qkLFk/wcDWU/C6Q1BzEJ1HAm8UUUyGoa4pfq3W8uGjd4q
X-Received: by with SMTP id dm6mr11258692wjb.136.1463069530193; Thu, 12 May 2016 09:12:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 12 May 2016 09:11:50 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Julian White <>
Date: Thu, 12 May 2016 17:11:50 +0100
Message-ID: <>
To: Chris <>
Content-Type: multipart/mixed; boundary=047d7bb03a50a139220532a76b27
Archived-At: <>
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: Thu, 12 May 2016 16:12:16 -0000


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.



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