13 KiB
IETF 106 Notes
- [2019-11-18 Mon] 10-12: MathMesh
- [2019-11-18 Mon] 13h30-16h00 TXAuth (Transactional Auth)
- [2019-11-19 Tue] IRTF - Human Rights Protocols Consideration
- [2019-11-19 Tue] Quantum Network IRTF
- [2019-11-20 Wed] RAW
- [2019-11-20 Wed] Web Authorization Protocol
- [2019-11-20 Wed] OAuth 2.1 discussion
- [2019-11-21 Thu] TxAuth discussion
- [2019-11-21 Thu] OAuth 2.0 2nd WG
- [2019-11-22 Fri] 6tish
[2019-11-18 Mon] 10-12: MathMesh
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
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
o ----> o /classical/
o ~~~~~ o /entanglement/
send qbits to teleportation.
Link layer service
- task: generate entanglement (adjacent nodes)
- gen an id for this entanglement, and what qubits are entangled
Example
-
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
- 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)
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
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
OAuth 2.0 for Browser Based Apps
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