deft/IETF-106.org

#+Title: IETF 106 Notes
#+Author: Yann Esposito

* [2019-11-18 Mon] 10-12: MathMesh

https://mathmesh.com

** Short overview

Objective: make computer easier to use by making them more secure.
Stop good enough security, make it easy for the user to be secure.

Have private keys on all devices.

Today, silo applications.
Configuration 50min. SSH/OpenPGP S/Mime, Signal, keybase, Anti-virus,
NAT/VPN, etc...

Mesh depends on UDF/DARE/Meta-Cryptography

If you build the Mesh, you can build many app on top of it.
IOT for example.

Example: Password

Proof case.

If you take away the pain of passwords for the user.

Mesh Password Catalog.

Open standard for password vault.

7h video on youtube channel.

*** Questions

Mainly new technology to replace/enhance 1Password, Keychain Access, etc...

Centralized in the sense there is a single Service Provider, but you can
change it any time you want.

** UDF

Cryptography on Rails

BASE-32 encoding of cryptographic data

All mesh key-ids are Content-Digest UDFs
 - SHA-2-512 digest of the key

Encrypted QR Code

- udf://example.com/ECXI-SNKI-GDCM-2DCP-WPBG-KNNQ-Z2NJ-WI

** DARE

Blockchain in JSON

JOSE / Uses KDF (master secret, nonce) to derive, Encryption, MAC key, etc...

*** Questions

- Solve many problems in one. Sync objects, password, etc...
  - no POW
- Encrypted contacts, and thus E2E social network
- you could be your own Mesh service provider

** Cryptography

- key addtion/split
- group encryption, add/delete user from a group is easy from the Service
  Provider perspective

*** Questions

** Questions/Discussion about Solving Problems, how IETF can be helpful, etc...

Service Provider host the data, can add/remove users from groups, but
cannot decrypt.

IOT usage.

- Question about Quantum Cryptography
  - ability to use a quantum resistant algo

* [2019-11-18 Mon] 13h30-16h00 TXAuth (Transactional Auth)

Is it worth on a working group?

New WG vs OAuth WG vs non-IETF vs no interest

** Limitations and Feature Requests

*** Limitations of OAuth - Justin

Justin Richer

RFC6749/RFC6750

Lot of RFCs to get before starting to code.

The Front Channel.

- OAuth's single Resource Owner.
- UMA Requestiong Party

Token Presentation/Token Binding

Scopes are a mess (some structure to that)

- resource / aud / claims

Try to make lot of different things.

*** Limitations of OAuth - Torsten

Rich Authorization Requests

Use of OAuth security sensitive scenarios, like
 - Open Banking
 - Strong identity Attestation

...

Generic solution for transactional, very precise scope (with many meta datas)

*** Feature Requests - Torsten

*** Feature Requests - Justin

Whishlist

- use JSON instead of basic param
- reinventing concepts
- no more necessarily using web browser


*** Non Authorize Features - Annabelle

Some requested are refused, and force the end user to change the context to
fix the situation. Like, paiment refused, lack of product to buy, etc...

So how to redirect the user to change context and potentially redirect him again.

** Proposals

*** OAuth XYZ - Justin

https://bspk.io

Not an OAuth2 extention

Addaption to no more server, but cloud, lambda, mobile apps, etc...

instead of validate with lot of parameters, generate a single usage URL

OAuth3?

*** RAR & PAR - Torsten

PAR: Push Authorization Request

RAR: Rich Authorization Request
 add =authorization_details= parameter, array of JSON objects with fields:
 =type=, =locations= (audience)

Mainly replace =authorization_details= inplace of =scope=.

RS specific access token and token instrospections responses.

** Discussion

- some ok for v3
- some against v3
- some for a v2.1 and simplification

** Next Steps

Further discussion in txauth & OAuth mailing lists
* [2019-11-19 Tue] IRTF - Human Rights Protocols Consideration
** Intro
*** IRTF
long term, no details

*** HRPC Objective

- Freedom of expression
- propose guidelines
- increase awareness

*** HRPC Outputs

- Internet drafts
- policy and academic papers
- film and textual interviews
- data analysis and visualization

*** Work to date

- Nov 2015: film Net of Rights at IETF94

** Presentation: Borders and Gateways

Measuring and analyzing national AS chokepoint

* [2019-11-19 Tue] Quantum Network IRTF

https://datatracker.ietf.org/rg/qirg/about/

** Introduction

*** History/Status/Plans
- Idea 2018
- rdv irtfopen 2018
- 3 face 2 face meetings
- 4 online meetings

*** Agenda
- RG Status
- RG Documents (4 active drafts)
- RG Other businesses
- Propose topics

** Architectural Principles of a Quantum Internet

*** Brief recap
- Prepared in IETF104 in Prague
- Good starting point for people with no quantum background
- lot of comments, or very vague
- organize
- Work on GitHub
  https://github.com/Wojtek242/draft-irtf-qircg-...

*** Overview
- Multiple small editorial changes

*** Pipeline
- mailing list
- still need to work througho- PR to be merged

*** Major updates
- security in quantum networks
- section 4: lifecycle of entanglement
- section 5: relation to classical networks, dual quantum/classical data plane

*** Security
- e2e using quantum channels in conjuction with classical channels
- security of network against network level threats not cnosidered at all
  yet, for example DoS

*** Lifecycle of entanglement (sec 4)
- re-written to clarify the process of creating, distributing, and
  delivering entanglement
- challenges;
  - measurement problem (cannot copy anything)
  - no-cloning theorem
  - fidelity
- Makes direct transmission difficult
- distribute entangled pairs between two endpoints (create Bell pairs)
- entaglement swaps to deliver two qbits to the 2 endpoints

*** Network model
re-written to clarify the challenges involved and the key differences to
the classical Internet
- challenges
  - there is no equivalent of a payload carrying network packet
  - entangle pair is only useful is you know where there both are (who and where)
  - generating entanglement requires temporary state
  - generating entanglement parallelisable operationo
- classical communicationo is necessary
  - be able to communicate your endpoint result via classical
- elements of a quantum network
  - quantum repeaters
  - quantum routers
  - end-nodes
  - non-quantum nodes
  - quantum links
  - classical links

*** Looking forward
- Physical constraints that have implicationos on architecture
- Goals of a quantum Internet
- Principles for a quantum Internet
- Network level security?

*** Questions
- What are the parameters for a good management system if we cannot measure?
  - entanglements pairs have ids
  - get a notification when an etangled pair is generated
  - the only thing impossible/hard to measure is fidelity
- end-nodes and repeaters...
- played with quantum computer and quantum error
  - fidelity enclose potential bit flip
  - error correction is a major concern
- measurement
- we are running too fast with our mental model... We can have further than
  just a pair of entanglement theoretically. Try to avoid excess of analogy.
  - avoid describing Stack and Layers
- Security will be hard comment
  - some work about security network exists (one paper)

** Link Layer for quantum networks

#+begin_src
o ----> o /classical/
o ~~~~~ o /entanglement/
#+end_src

send qbits to teleportation.

*** Link layer service
- task: generate entanglement (adjacent nodes)
- gen an id for this entanglement, and what qubits are entangled

*** Example
1. Create message (what is your required fidelity for example), and
   relation between fidelity and generating rate
   - Type of request, create and keep in memory
   - create and read it immediately
2. Message returned with id on both nodes

*** Changes in headers
CREATE header message (looks like an ip message)
choice the type
random base
TU, time unit (2 bits)

*** Github
https://github.com/SoftwareQuTech/draft-dahlberg-qirg-ll-quantum

*** Questions
- change the name for headers, its more like commands
- how many pairs you want to generate
  - this is already in the command, queue, scheduling, etc...
- what is parallizable
- number of pair generated hard limit?
  - maybe not a good idea to fix the length of the fields

** Connection Setup in a Quantum Network

-00 -> -01 draft, non data teleportation uses of entanglement.

** Integration of OpenSSL

*** Intro
Hackaton tackled various quantum internet challenges

QKD algo

*** OpenSSL challenge
- for now very very low level
- higher level proofs
- being able to "hack" at user level

*** ETSI QKD API
API is very simple, and define 5 functions

Node-1 gen a local key and transport via quant to Node-2
Use the key to open in firefox on Node-2

*** Conclusions
Hacked and hacky, https://brunorijsman.github.io/openssl-qkd

*** Question
- people will work on that in Berlin
- also pubsub in the mailing list

** Proposals
* [2019-11-20 Wed] RAW

** RAW Problem Statement draft status
- Current version 04

* [2019-11-20 Wed] Web Authorization Protocol

https://datatracker.ietf.org/group/oauth/about/

- Chairs Update (15 min)
- Security Topics – Torsten (15 min)
- Browser-based Apps – Aaron (20 min)
- OAuth 2.1 – Aaron (10 min)
- TXAuth update – Dick/Justin (15 min)
- DPoP – Brian (15 min)

** Documents

https://datatracker.ietf.org/wg/oauth/documents

Queue: 3 documents

** OAuth 2.0 Security Best Current Practice

Slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-oauth-sessa-oauth-20-security-best-current-practice-draft-ietf-oauth-security-topics-00

Doc: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/

*** Communities using the OAuth Security BCP

- Financial-grade API (FAPI) working group (OpenID Foundation)
  - Alignment towards BCP ongoing
  - Provides profiles for security sensitive applications with stronger
    requirements on top of BCP
- NextGenPSD2 (aka Berlin Group)
  - Refers to BCP in recently released security bulletin
  - Service providers in Rumania (namely IT Smart Systems) recommend
    Security BCP to banks
  - PBZ (Privredna banka Zagreb d.d.) in Croatia uses Security BCP
- HelseID (eHealth) in Norway uses Security BCP
- Cloud Signature Consortium (CSC) refers to Security BCP
- JS libraries (e.g. angular-oauth2-oidc) now support code+PKCE and vendors
  start to adapt their documentation (e.g. Identity Server)

List far from exhaustive, people asked explicitely.

*** Next Steps

reorg of doc a bit

*** Open

Implicit SHOULD NOT to MUST NOT...
keep SHOULD NOT... WTF...

*** OAuth Security Workshop 2020

Norway 22-24 July

https://osw2020.com

2 days around OAuth

** OAuth 2.0 for Browser Based Apps

Slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-oauth-sessa-oauth-20-for-browser-based-apps-00

*** SPA

- MUST use OAuth2 code with PKCE
- MUST NOT return access tokens in the front channel (implicit)
- MUST use OAuth 2.0 state to carry one-time use CSRF tokens
- AS MUST require an exact match of the domain

*** What's new?

- updates to bring this in line with the Security BCP
- Disallow the password grant even for first-party apps

*** Open Questions

- Should state be used for CSRF protection even if PKCE is used?
  discussion:...
- Refresh Token; OIDC using iframe
- CSP?
  - disable inline scripts in the SPA?
  - comment on how to use origin parameter to select the correct CSP from
    the AS

** OAuth 2.1

Slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-oauth-sessa-oauth-21-00

*** OAuth 2.1

- RFC6749 - OAuth 2.0 Core
- Security BCP
  - MUST support PKCE for all client types No password grant
  - No implicit flow
  - Bring the device grant into 2.1
- Native App & Browser-Based App BCPs
- Token Revocation Authorization Server Metadata

Additional requirements on authorization servers that intend to
interoperate with arbitrary resource servers

- Token Introspection
- JWT Access Tokens
- JWT BCP

* [2019-11-20 Wed] OAuth 2.1 discussion

- minimal effort: RFC6749 + link to BCP + link to PKCE + Device Grant + warn about Implicit
- 2.1 as merging in a single document: RFC6749 + BCP + PKCE + Device Grant - Implicit

* [2019-11-21 Thu] TxAuth discussion

Conclusion, maybe not OAuth 3, the scope of the document must be stated.

Missing a bit of abstractions, examples, etc...

* [2019-11-21 Thu] OAuth 2.0 2nd WG
** TxAuth discussion/resume
** OAuth 2.1 Summary
** DPoP (Proof of possession)
https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/?include_text=1

- personal opinion: modification from access token to JWT access token +
  DPoP JWT which change the API check.
- mostly stuck
** PAR
https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
- Fix Very long URL for /authorize and also immediately provide client auth check.
- very easy to implement
Accepted Draft to be presented.
** RAR
https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/

Rich Authorization Requests

- mostly replace scopes by JSON structure

Too short time to decide if upgrade from draft
** Claims

https://datatracker.ietf.org/doc/draft-spencer-oauth-claims/?include_text=1

Requesting Claims
* [2019-11-22 Fri] 6tish