deft/IETF-106.org
2020-01-24 09:59:54 +01:00

13 KiB
Raw Blame History

IETF 106 Notes

[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

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

  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)

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

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)

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

[2019-11-22 Fri] 6tish