[Openid-specs-heart] HEART WG AGENDA Monday April 20, 2020

[Debbie Bucci]

Daniel

Thank you so much for this.    Noem had suggested we reach out for you to
brief the working group on FAPI.   We would greatly appreciate it if you
have the time.   We have tentatively scheduled our next meeting for
May  4th at 4 PM EST but willing to work with you (off list) to find a time
that works.    I am certain that those that actively participate and
monitor the HEART list would find it beneficial.


Thanks in advance for both the background and consideration.


On Wed, Apr 22, 2020 at 3:14 AM Daniel Fett <fett at danielfett.de> wrote:

> Hi Debbie,
>
> Am 21.04.20 um 22:15 schrieb Debbie Bucci:
>
> Tom,
>
> Given you raised the concern in the first place - is there a specific
> document  - section of FAPI 2.0 spec you are referring to?  This article
> seem rather broad. Its up to the organization to do their own risk
> assessment - preferably based on recognized frameworks NIST/ISO etc.
> Given many of us have experience with this type of analysis - what are you
> comparing it too?
>
> I'm not Tom, but maybe I can help to clarify this.
>
> He is referring to the FAPI 2.0 Attacker Model draft that has been adopted
> by the FAPI working group [1].
>
> One of the "lessons learned" from FAPI 1.0 was that there is a need for a
> clear definition of which attacks the protocol aims to defend against (and
> which not). More specifically, that was one of the takeaways from an
> detailed security analysis of FAPI 1.0 [2]. In this paper, of which I am a
> coauthor, we used formal methods that enable a very comprehensive and
> in-depth analysis of the security properties of web protocols. We
> previously used the same methods to find the mix-up and code injection
> attacks on OAuth [3], to verify the security of OpenID Connect [4], and
> other protocols [5,6,7].
>
> Formal analysis of web protocols is a relatively young field with a lot of
> pioneering work still to do. In general, however, formal methods are a very
> well-established standard tool in network protocol security. For example,
> formal models were very successfully used to develop and secure TLS 1.3.
> Formal analysis requires a defined attacker model to verify the protocol's
> security against. Within the bounds of the model, formal methods can the
> provide very strong security guarantees. But it is not the purpose of the
> attacker model to hide other potential attacks. The attacker model itself
> rather tells us about the boundaries of the formal guarantees where we then
> have to apply other methods.
>
> For FAPI 2.0 I wrote down the attacker model to inform decisions in the
> protocol design, to enable a formal analysis of FAPI 2.0, and to tell
> readers where the boundaries of the guaranteed security are.
>
> To address Tom's concerns: Neither the attacker model itself nor a formal
> analysis obsoletes a thorough risk analysis and all the other methods we
> have to secure deployments, but they complement each other. Formal methods
> provide guarantees on protocols - in isolation! - whereas organizational
> risk analyses and other security measures are needed to secure deployed
> systems. (You can't pentest a piece of paper.)
>
> - Daniel
>
> [1]
> https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Attacker_Model.md
>
> [2] https://arxiv.org/abs/1901.11520
>
> [3] https://arxiv.org/abs/1601.01229
>
> [4] https://arxiv.org/abs/1704.08539
>
> [5] https://arxiv.org/abs/1403.1866
>
> [6] https://arxiv.org/abs/1411.7210
>
> [7] https://arxiv.org/abs/1508.01719
>
>
> On Tue, Apr 21, 2020 at 2:01 PM Tom Jones <thomasclinganjones at gmail.com>
> wrote:
>
>> not in this forum - it is not appropriate.
>> Peace ..tom
>>
>>
>> On Tue, Apr 21, 2020 at 10:51 AM Daniel Fett <fett at danielfett.de> wrote:
>>
>>>
>>> https://cacm.acm.org/magazines/2020/4/243625-why-is-cybersecurity-not-a-human-scale-problem-anymore/fulltext
>>>
>>> Could you please elaborate in which way this article critizes the
>>> attacker model used in formal protocol security analyses? This critique
>>> must then apply equally for the way in which TLS 1.3 was designed and
>>> evaluated (see, e.g., https://tools.ietf.org/html/rfc8446#appendix-E).
>>>
>>> -Daniel
>>>
>>> Am 21.04.20 um 19:41 schrieb Tom Jones:
>>>
>>> DOI:10.1145/3347144.  CACM 63 no 4 p 30ff
>>> Peace ..tom
>>>
>>>
>>> On Tue, Apr 21, 2020 at 10:38 AM Daniel Fett <fett at danielfett.de> wrote:
>>>
>>>> Am 21.04.20 um 18:30 schrieb Tom Jones:
>>>>
>>>> Well, I am a member of the FAPI wg and do not like their current
>>>> direction. Specifically I strongly disagree with Fett's attack model which
>>>> has come under increasing attack in, for example the current issue of the
>>>> CACM.
>>>>
>>>> Which article?
>>>> _______________________________________________
>>>> Openid-specs-heart mailing list
>>>> Openid-specs-heart at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>>
>>>
>>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20200422/58595116/attachment.html>