Re: [OAUTH-WG] DPoP draft-ietf-oauth-dpop-0 Client collaborative attacks

[Benjamin Kaduk]

Hi Denis,

On Fri, May 01, 2020 at 10:47:18AM +0200, Denis wrote:
>Comments on draft-ietf-oauth-dpop-00.
> 
>1) In section 9 (Security considerations), the text states:
> 
>DPoP does not, however, achieve the
>   same level of protection as TLS-based methods such as OAuth Mutual
>   TLS [RFC8705] or OAuth Token Binding [I-D.ietf-oauth-token-binding]
>   (see also Section 9.1 and Section 9.4).
> 
>draft-ietf-oauth-token-binding-08 [i.e. I-D.ietf-oauth-token-binding]
>expired on April 22, 2019,
>thus it does not seem adequate to refer to it.

It can still be useful to refer to technology that ended up not getting
deployed, for comparison against the work in questionn.

>2)  The text states:
> 
>9.1.  DPoP Proof Replay
> 
>   If an adversary is able to get hold of a DPoP proof JWT, the
>   adversary could replay that token at the same endpoint (the HTTP
>   endpoint and method are enforced via the respective claims in the
>   JWTs).
> 
>This is true, but there is a worse case:  if a client legitimately obtains
>a DPoP proof JWT and collaborates
>with another client, then it can provide it to that other client.

Would we not consider one or both such clients to be "an adversary" in that
situation?  They are, after all, behaving contrary to the expected flow.

>3)  The text states:
> 
>   9.4.  Message Integrity
> 
>   DPoP does not ensure the integrity of the payload or headers of
>   requests.  The signature of DPoP proofs only contains the HTTP URI
>   and method, but not, for example, the message body or other request
>   headers.
> 
>   This is an intentional design decision to keep DPoP simple to use,
>   but as described, makes DPoP potentially susceptible to replay
>   attacks where an attacker is able to modify message contents and
>   headers.  In many setups, the message integrity and confidentiality
>   provided by TLS is sufficient to provide a good level of protection.
> 
>DPoP alone or DPoP used in conjunction with TLS does not provide any
>protection in case of collusion attacks
>between collaborative clients.

Do you think that the reader would expect such protection in the absence of
text in the security considerations section?
My personal expectation is that the reader would not expect protection
against a client that colludes with some other (malicious) party, and that
such a client would itself be deemed malicious.

Thanks,

Ben

>Collaborative attacks between clients cannot be countered using
>software-only implementations.
>It should also be noticed that the use of secure elements to only protect
>private keys is insufficient,
>since a collaborative client can still perform all the cryptographic
>computations needed by the other client.
> 
>These considerations about collaborative clients should be added into the
>security considerations section.
> 
>Denis

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Microsoft feedback on DPoP during April 2020 IIW session

[Benjamin Kaduk]

On Fri, May 01, 2020 at 02:29:02AM +, Mike Jones wrote:
>   *   Is the DPoP signature really needed when requesting a bound token?  It 
> seems like the worst that could happen would be to create a token bound to a 
> key you don't control, which you couldn't use.  Daniel expressed concern 
> about this enabling substitution attacks.

Substitution and confused deputy attacks, yes.  I would feel a lot better
if the signature is required when requesting the bound token; a fair bit of
extra analysis would be needed to try to remove it.

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt

[Brian Campbell]

Yes, it potentially could. But I think we *really* want to avoid
adding a challenge/response
round trip to every call. So it wouldn't be a nonce exactly and there'd
need to some guidance or something on what it is and how long it could be
used. And that could introduce new server side state. Also the challenge
doesn't exist for the token endpoint.

On Tue, May 5, 2020 at 1:15 PM Nikos Fotiou  wrote:

> Hi all,
>
> There was some discussion about adding “server contribution” in the DPoP
> proof. I was wondering if the “challenge” server response described in
> section 6 can include such a contribution (e.g., a server generated nonce).
>
>
>
> Best,
>
> Nikos
>
>
>
> *From:* OAuth  *On Behalf Of *Brian Campbell
> *Sent:* Friday, May 1, 2020 10:03 PM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Fwd: New Version Notification for
> draft-ietf-oauth-dpop-01.txt
>
>
>
> I've pushed out a -01 revision of DPoP hopefully allowing folks enough
> time to read it before the interim meeting on Monday (apologies that it
> wasn't sooner but the edits took longer than expected or hoped). For ease
> of reference the changes in this revision are summarized below. There are,
> of course, still outstanding issues and discussion points that I hope to
> make some progress on during the interim meeting on Monday.
>
>
>
>-01
>
>
>*  Editorial updates
>*  Attempt to more formally define the DPoP Authorization header
>   scheme
>*  Define the 401/WWW-Authenticate challenge
>*  Added "invalid_dpop_proof" error code for DPoP errors in token
>   request
>*  Fixed up and added to the IANA section
>*  Added "dpop_signing_alg_values_supported" authorization server
>   metadata
>*  Moved the Acknowledgements into an Appendix and added a bunch of
>   names (best effort)
>
>
>
> -- Forwarded message -
> From: >
> Date: Fri, May 1, 2020 at 12:24 PM
> Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt
> To: Torsten Lodderstedt , David Waite <
> da...@alkaline-solutions.com>, John Bradley , Brian
> Campbell , Daniel Fett ,
> Michael Jones 
>
>
>
>
> A new version of I-D, draft-ietf-oauth-dpop-01.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
>
> Name:   draft-ietf-oauth-dpop
> Revision:   01
> Title:  OAuth 2.0 Demonstration of Proof-of-Possession at the
> Application Layer (DPoP)
> Document date:  2020-05-01
> Group:  oauth
> Pages:  22
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-oauth-dpop-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-01
>
> Abstract:
>This document describes a mechanism for sender-constraining OAuth 2.0
>tokens via a proof-of-possession mechanism on the application level.
>This mechanism allows for the detection of replay attacks with access
>and refresh tokens.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited...
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt

[Brian Campbell]

Thanks Neil.  I do appreciate your review and feedback (even if it takes me
a nontrivial amount of time to reply). I've attempted to respond to things
inline below.

On Mon, May 4, 2020 at 5:51 AM Neil Madden 
wrote:

> Some review comments:
>
> Section 1:
> I think terms like “relatively simple” are subjective and should be left
> out. I don’t think the machinery of JWS signature verification (and
> associated security issues) is necessarily simple at all.
>

That's fair. It was subjectively true to me as I wrote it but I take your
point.


>
> “stronger methods … such as [RFC8705] or [token binding]”
> I would dispute that these are actually stronger methods in the context of
> an SPA, putting aside the usability issues. As has been discussed before,
> TLS is a shared context in a web browser - the same TLS connection will be
> reused for all requests, regardless of the origin they come from. The
> situation is better for cert-bound ATs because you need the CORS
> Access-Control-Allow-Credentials to be set to make a cross-origin request
> with a client certificate, but as I describe below there are also other
> attacks against TLS that don’t apply to DPoP (and would be a good reason to
> adopt DPoP).
>

The “stronger methods" was preceded with "potentially" in hopes of toning
down the strength of the statement about strength somewhat. But yes it
could be reworded to take away any comparative language.



>
> I think this section should also mention mobile use-cases, as IMO the case
> for DPoP is much stronger in those environments. Many of our customers are
> looking for a PoP solution for mobile and have rejected mTLS for various
> reasons (which have previously been discussed on this list, e.g.
> incompatible middleboxes). DPoP is potentially really nice for these
> environments as they often have a nice secure element available to store
> the private key and are much less susceptible to XSS and so on, but may
> still worry about a malicious RS.
>

Agree that mobile/native use-cases deserve a mention.


> IoT applications may also be a use-case as requests are often relayed over
> multiple hops and different transport protocols, so TLS cannot be used for
> end-to-end security (although in that case you probably want a full request
> signing approach).
>
> Section 2:
> I think the “Main Objective” in section 2 could be improved. The vast
> majority of the mechanisms described in the draft do nothing to address
> this main objective, and are in fact intended to prevent DPoP proof replay
> which is relegated to a “secondary objective” in section 9. Only the “htu”
> claim really has anything at all to do with the main objective. I think
> some of these secondary objectives, especially the anti-replay one, should
> be brought forward to section 2 to better justify what follows.
>
> It has been mentioned several times on this list that an audience
> restriction in the AT would also solve this main objective, and the
> response has generally been that adding audience restrictions is hard in
> practice - e.g. due to the AS not knowing where the AT is intended to be
> used. I think it would be useful to explicitly add some discussion of this,
> and perhaps a comparison with things like resource indicators that
> presumably could solve at least some of the issues with audience
> restrictions.
>
> I think there *are* significant advantages of DPoP that address real-world
> attacks that cannot be solved in any other way currently. For example, I
> was reading [1] recently about CRIME/BREACH attacks against CSRF tokens and
> it occurred to me that exactly the same kind of attack is a real threat to
> access tokens in a browser and that DPoP is an effective mitigation against
> it. To summarise, these attacks exploit vulnerabilities in TLS when
> combined with compression (either in TLS itself or HTTP compression) and
> can allow an attacker to steal bearer tokens or cookies after observing
> enough requests with the same token (and being able to influence some other
> content in the same request/response). One recommended mitigation is to
> randomize tokens so that they are different on every request, which thwarts
> the attack. Although DPoP doesn’t directly randomize the AT the AT is
> useless without a DPoP proof and a unique “jti” claim ensures that the DPoP
> proof is randomized and so not recoverable through this attack. Given that
> BREACH is largely unmitigated in practice, due to the usefulness of
> compression, adding a description of this attack to the justification would
> IMO significantly improve the rationale for DPoP.
>

Daniel is way way way more adept than I when it comes to threat and
attacker modeling. He also penned the original text of the draft, much of
which is still present. In trying not to step on his toes and also be
mindful of the disparity in our competency, I'm really hoping that he can
do an overhaul of the threat model, objectives, security considerations,
etc. to address this and 

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-01.txt

[Nikos Fotiou]

Hi all,

There was some discussion about adding “server contribution” in the DPoP proof. 
I was wondering if the “challenge” server response described in section 6 can 
include such a contribution (e.g., a server generated nonce).

 

Best,

Nikos

 

From: OAuth  On Behalf Of Brian Campbell
Sent: Friday, May 1, 2020 10:03 PM
To: oauth 
Subject: [OAUTH-WG] Fwd: New Version Notification for 
draft-ietf-oauth-dpop-01.txt

 

I've pushed out a -01 revision of DPoP hopefully allowing folks enough time to 
read it before the interim meeting on Monday (apologies that it wasn't sooner 
but the edits took longer than expected or hoped). For ease of reference the 
changes in this revision are summarized below. There are, of course, still 
outstanding issues and discussion points that I hope to make some progress on 
during the interim meeting on Monday.

 

   -01


   *  Editorial updates
   *  Attempt to more formally define the DPoP Authorization header
  scheme
   *  Define the 401/WWW-Authenticate challenge
   *  Added "invalid_dpop_proof" error code for DPoP errors in token
  request
   *  Fixed up and added to the IANA section
   *  Added "dpop_signing_alg_values_supported" authorization server
  metadata
   *  Moved the Acknowledgements into an Appendix and added a bunch of
  names (best effort)

 

-- Forwarded message -
From: mailto:internet-dra...@ietf.org> >
Date: Fri, May 1, 2020 at 12:24 PM
Subject: New Version Notification for draft-ietf-oauth-dpop-01.txt
To: Torsten Lodderstedt mailto:tors...@lodderstedt.net> >, David Waite mailto:da...@alkaline-solutions.com> >, John Bradley mailto:ve7...@ve7jtb.com> >, Brian Campbell mailto:bcampb...@pingidentity.com> >, Daniel Fett mailto:m...@danielfett.de> >, Michael Jones mailto:m...@microsoft.com> >




A new version of I-D, draft-ietf-oauth-dpop-01.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:   draft-ietf-oauth-dpop
Revision:   01
Title:  OAuth 2.0 Demonstration of Proof-of-Possession at the 
Application Layer (DPoP)
Document date:  2020-05-01
Group:  oauth
Pages:  22
URL:
https://www.ietf.org/internet-drafts/draft-ietf-oauth-dpop-01.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Htmlized:   https://tools.ietf.org/html/draft-ietf-oauth-dpop-01
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-01

Abstract:
   This document describes a mechanism for sender-constraining OAuth 2.0
   tokens via a proof-of-possession mechanism on the application level.
   This mechanism allows for the detection of replay attacks with access
   and refresh tokens.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org 
 .

The IETF Secretariat




CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited..  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] A *Short* 3rd WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Rifaat Shekh-Yusef]

Hi all,



This is a 3rd working group last call for "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens".



Here is the document:

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07



Please send your comments to the OAuth mailing list by May 12, 2020.



Regards,

 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt

[Denis]

Comments on draft-ietf-oauth-security-topics-15

1) Historically, the acronym RO (Resource Owner) has been used but is 
still used in this document.
    Since a client is not necessarily any more a RO, it would be more 
adequate to use the word "Client"

    instead of "RO"  in this document.

2) The structure of the document is the following:

1.Introduction
2.Recommendations
3.The Updated OAuth 2.0 Attacker Model

It is rather odd to have recommendations placed before the Attacker 
Model. Before providing solutions to some problems,
it is important to understand what the problems are. The Updated OAuth 
2.0 Attacker model should be placed after the introduction.


The "most important recommendations of the OAuth working group for every 
OAuth implementor" should be placed after the "Attacks and Mitigations" 
section.


3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to have been 
"updated to account for the potentially _dynamic relationships involving 
multiple parties_".
However, it still misses to address the case of _dynamic relationships 
between clients_, which include scenarios of _collaborative clients_.


Such a collaboration between clients is possible and should be 
considered in the "updated model". Since the Auth 2.0 protocol may be 
used by clients
which are human beings, it cannot be assumed that all the human beings 
in the world will necessary be honest. Whether or not Auth 2.0 is able 
or not

to counter such an attack is another issue.

The collaborative attack should be added to this "updated" model. It was 
missing in the previous model.


In another section, it should be mentioned that OAuth 2.0 is unable to 
counter such an attack.
Stating that such an attack is "out of the scope" of OAuth 2.0 would not 
be an appropriate statement.


It should not be forgotten, that the purpose of this document is to 
inform the reader about _all_ the relevant security issues.


Denis


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

 Title   : OAuth 2.0 Security Best Current Practice
 Authors : Torsten Lodderstedt
   John Bradley
   Andrey Labunets
   Daniel Fett
Filename: draft-ietf-oauth-security-topics-15.txt
Pages   : 46
Date: 2020-04-05

Abstract:
This document describes best current security practice for OAuth 2.0.
It updates and extends the OAuth 2.0 Security Threat Model to
incorporate practical experiences gathered since OAuth 2.0 was
published and covers new threats relevant due to the broader
application of OAuth 2.0.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Refreshing tokens on the RS

[Jim Schaad]

Over in the ACE working group we are currently having a discussion about
refreshing tokens on an RS.  I want to make sure that this is not something
that this working group has already solved.  The basic scenario is:

1.  Client gets token T1 and posts it to the RS
2.  After some time the RS returns and error to the client about an access
issue
3.  Client gets a new token from the AS T2, possibly using a refresh token.
4. Client posts the token T2 to the RS
5.  The RS somehow needs to associate token T1 and T2 for long term security
sessions.

I do not believe that OAuth has this issue because there is not currently
any concept that a token is used for anything other than a single
request/response between the client and the RS.  There is no idea of the RS
storing tokens long term associated with a TLS session that might need to
have the access rights for that TLS session changed.

Please provide any feedback that you might have.

Thanks
Jim


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP: Threat Model

[Denis]

Hi Daniel,

Rather than answering between the lines, I place a global answer in 
front of your message.


Depending upon the content of the JWT, two different collaborative 
attacks need to be considered,
one of them being an impersonation attack which can indeed be performed 
using Teamviewer.


The other one, i.e. when the JWT does not contain a set of attributes 
that is sufficient to identify an individual,
is not and cannot be performed using Teamviewer because it does not deal 
with impersonation.


Let us consider a scenario to illustrate this second case.

Alice is Client A while Bob is Client B.

Alice and Bob have both opened an account on a web server allowing to 
make reservations on tennis courts managed by the town of Utopia.


Bob is a resident from Utopia, but Alice is not. Residents from Utopia 
are allowed to perform tennis courts reservations two weeks in advance

while other people can only perform them 48 hours in advance.

An Attribute Server (AS) managed by the town of Utopia is able to 
provide a JWT stating that the holder is indeed a resident of Utopia
(there are about 50.000 residents). The holder can use such a JWT for 
different web sites: library, swimming pool, tennis, ... The web servers
trusting the AS from the town of Utopia ask to present such a JWT once a 
year which may allow to get some advantages during one year.


Bob has already presented such a JWT at the beginning of the year, thus 
he can enjoy making tennis courts reservations two weeks in advance.
Alice is annoyed since most of the time 48 hours ahead, most tennis 
courts are already reserved. So she asks Bob whether he would accept
to request a new JWT token stating that the holder is indeed a resident 
of Utopia. Let us assume that Bob accepts.


When Alice connects to the server, she also ask Bob to connect to the AS 
and to provide her with the JWT and to stay online to perform
all the cryptographic computations she will need to present this JWT to 
the tennis courts web server. For doing this, they both use

a specific piece of software developed for this purpose.

When this is done, during one year, Alice will enjoy to make tennis 
reservations two weeks in advance. At this end of these 12 months,

she will ask Bob to collaborate again.

In this scenario, unless the AS and the RS collaborate, nobody will know 
that Alice and Bob collaborated.


You wrote:

We discussed these kinds of collusion attacks at great length previously 
on this list. My views on them have not changed.


You are not saying in this email what your views are. However, I browsed 
through the last exchanged emails.


On November 8, 2019, under the thread "WGLC for "OAuth 2.0 Security Best 
Current Practice", you wrote:


I have the feeling that this attack aims at breaking a security property 
that OAuth does not claim to fulfill (and that nobody expects OAuth to 
fulfill):


 (...)

     And there are good reasons why this is not captured by the 
security property (Hans' screenshot, for example).


    As far as I know, this property is neither achieved by classical 
first-party session-based authentication/authorization nor by any other 
web-based mechanism, or is it?


I responded to this email:
*
Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"
*Denis  Tue, 12 November 2019 09:19 UTC
https://mailarchive.ietf.org/arch/msg/oauth/Gc8T8mRkF5vJT7fV3uSc66B_9Fs/

However, you never responded to it. Up to now, I don't know what "Hans' 
screenshot" was and I don't know the "good reasons

why this is not captured by the security property".

On November 13, I sent an email to the list and to Brian:
*
Re: [OAUTH-WG] Fwd: New Version Notification for 
draft-fett-oauth-dpop-03.txt

*Denis  Wed, 13 November 2019 09:17 UTC
https://mailarchive.ietf.org/arch/msg/oauth/WC8jCC-U3bAhlBHEVRLAdSOuY98/

At the end, I wrote:

    DPoP is not able to counter collusion attacks between clients and 
this should be clearly advertised in the abstract, in the main 
objectives (section 2)

    and in the security considerations (section 9).

You have not participated to this thread. However, DPoP is still silent 
about this kind of attack.


RFC 3552 (Security Considerations Guidelines) states in its Introduction :

    "All RFCs are required by RFC 2223 to contain a Security 
Considerations section.The purpose of this is both
 to encourage document authors to consider security in their 
designs and to _inform the reader of relevant security issues_".


draft-fett-oauth-dpop does not comply with RFC 3552 but it should.

Denis

P.S. It is possible to counter the Alice and Bob collusion attack (ABC 
attack) when specific secure elements are being used.



Hi Denis,

We discussed these kinds of collusion attacks at great length 
previously on this list. My views on them have not changed.


Am 04.05.20 um 20:06 schrieb Denis:
As soon as a software solution would be available to perform this 
collaborative attack, everybody would be able to 

[OAUTH-WG] Fwd: Reminder: Survey on planning for possible online IETF meetings

[Rifaat Shekh-Yusef]

All,

Please take sometime to complete the survey below to help with the planning
for the coming, most likely virtual, IETF meetings.

Regards,
 Rifaat



-- Forwarded message -
From: IETF Executive Director 
Date: Mon, May 4, 2020 at 3:04 AM
Subject: Reminder: Survey on planning for possible online IETF meetings
To: IETF Announcement List 


This is a reminder that we need the IETF community to help us plan for the
possibility that one or more upcoming IETF meetings in 2020 and possibly
2021 may not be able to go ahead in person.  You can help us with this by
filling out the following survey:

https://www.surveymonkey.com/r/5328FFJ

So far we have 114 responses and we would ideally like 500 or more.

The survey contains the following pages and will take 15-20 minutes to
complete:

1. Welcome
2. Online IETF 107 and the subsequent virtual interims
3. Replacing a cancelled in-person meeting
4. Online meeting format and timezone
5. Replicating humming
6. Replicating the hallway environment
7. Fees
8. Thanks and anything else

We run the survey in anonymous mode which means that we only see data that
you explicitly provide.

Thank you in advance for your help.

-- 
Alissa Cooper, IETF Chair
Jay Daley, IETF Executive Director
Colin Perkins, IRTF Chair

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth