Re: [VoT] vot Digest, Vol 14, Issue 5

Peter Alterman <palterman@safe-biopharma.org> Fri, 13 May 2016 11:07 UTC

Return-Path: <palterman@safe-biopharma.org>
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 ED33B12D146 for <vot@ietfa.amsl.com>; Fri, 13 May 2016 04:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=safe-biopharma-org.20150623.gappssmtp.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 hahtNrzPPsDx for <vot@ietfa.amsl.com>; Fri, 13 May 2016 04:07:18 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 4623B12D0A6 for <vot@ietf.org>; Fri, 13 May 2016 04:07:18 -0700 (PDT)
Received: by mail-pa0-x22e.google.com with SMTP id xk12so40250235pac.0 for <vot@ietf.org>; Fri, 13 May 2016 04:07:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=safe-biopharma-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=SsbAzC5nMGBqjYlX0kKNdTuMGBkJdX714ySqaaj3IHQ=; b=p3szX983yug694BUxwDf6/H7RUa6e+7squZoAjGLTY+PvqLb24TqFwQGqY2rY6LuEO shY1TMCrjuvXPNouMWTJh6ZqRdPSGw8KFwS3ihmcg/dwN7/AkNa0tjDRWZTHz3xxmCht K0Skf2EzVl1qRd6+IDbVROdECV8BlkSU8z/kUUMJfHOUg6jnTjqjbvn9HTepotUJR+ea 3YeITrbn2hneRzB3UHJI5P2E9ywkzgighodY1L4WXBfSV2VKWgPzK1c6OWmTU0EBfeiq HF67uIaumUBfPNULU35lKg1RBAtqicGI2bkOLuAlPsbZT74HV1VaY30tAto+6U/G2aBb +r3A==
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; bh=SsbAzC5nMGBqjYlX0kKNdTuMGBkJdX714ySqaaj3IHQ=; b=Q7TZurBv2vGP9XRGeh633seUDUwX8hgZYzgQYO0bBnDNfHDCdhnUarnyzwMw22jEsu 2i0k0q7xpUQEXY7Fl31hDrEojQisEZVE/h/vMvUHQ90luoC9AmnEmvbrkN1q4+yDnX53 qeQcWBo1HXVR/BMcJi7/7nwef1KaVGb9AMUv1SCkojL8Zv5Vcz9dHKi2LiUihKyqRYay pJxjaEWY+FKVapq9EWpjLdmxdZkXhIho2BG6pUNz+0UPdewIANkQS5VE5fObhR16OJgW FWpd4w1Bm43GDbnvztlyCcaXUapI9p3U7orCSJqZ0xbCq3Jz0AwuRkVNqtV67R5t3bgC //6g==
X-Gm-Message-State: AOPr4FX/ZnhJIoc/nBVzS2YWKk/sJDWbvtXOdsUkc7V3r1/XhLigxex7c+6JQqsBrdnJyw6jLPk4+ov1/yeqm/YD
MIME-Version: 1.0
X-Received: by 10.66.160.133 with SMTP id xk5mr21902482pab.71.1463137637652; Fri, 13 May 2016 04:07:17 -0700 (PDT)
Received: by 10.66.12.202 with HTTP; Fri, 13 May 2016 04:07:17 -0700 (PDT)
Received: by 10.66.12.202 with HTTP; Fri, 13 May 2016 04:07:17 -0700 (PDT)
In-Reply-To: <mailman.4609.1463132911.3594.vot@ietf.org>
References: <mailman.4609.1463132911.3594.vot@ietf.org>
Date: Fri, 13 May 2016 07:07:17 -0400
Message-ID: <CAAbgyEC-+_zp4pYdtAqMVF-zFh4xmHS_TMAV3=RhvQNXGMjWBw@mail.gmail.com>
From: Peter Alterman <palterman@safe-biopharma.org>
To: vot@ietf.org
Content-Type: multipart/alternative; boundary=047d7b6d96f6267b9a0532b747af
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/_tdJ1gv_gSs85kNzENP0E9-kXGA>
Subject: Re: [VoT] vot Digest, Vol 14, Issue 5
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 11:07:21 -0000

That raises the issue of what kind of machine readable metadata should
represent the trustmark?
Peter
On May 13, 2016 5:48 AM, <vot-request@ietf.org> wrote:

> Send vot mailing list submissions to
>         vot@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/vot
> or, via email, send a message with subject or body 'help' to
>         vot-request@ietf.org
>
> You can reach the person managing the list at
>         vot-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vot digest..."
>
> Today's Topics:
>
>    1. Re: Security Problem with Primary Credential Usage (Julian White)
>    2. Re: Security Problem with Primary Credential Usage (Chris)
>
>
> ---------- Forwarded message ----------
> From: Julian White <jwhite@nu-d.com>
> To: Justin Richer <jricher@mit.edu>
> Cc: Chris <cnd@geek.net.au>au>, vot@ietf.org
> Date: Fri, 13 May 2016 08:52:55 +0100
> Subject: Re: [VoT] Security Problem with Primary Credential Usage
> 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> 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> 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
>>>
>>>
>>>
>
>
> ---------- Forwarded message ----------
> From: Chris <cnd@geek.net.au>
> To: Julian White <jwhite@nu-d.com>
> Cc: vot@ietf.org, Justin Richer <jricher@mit.edu>
> Date: Fri, 13 May 2016 19:48:21 +1000
> Subject: Re: [VoT] Security Problem with Primary Credential Usage
> 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 <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> 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
>
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
>
>