518 lines
13 KiB
Org Mode
518 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
|