519 lines
13 KiB
Org Mode
519 lines
13 KiB
Org Mode
|
#+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
|