Minutes IETF106: emu
minutes-106-emu-00

IETF 106 Minutes for EMU working group
(Eliot, as note taker)

Joe promptly started the meeting.

Note well presented. Agenda bashing.  None.

WG documents

Jari

RFC-5448bis going to IESG.

EAP-AKA
 - two updates
 - no huge change
 - document is now an update.
 - use is RECOMMENDED
 - clarify references ECDSA curve25519; deletes IKEv2 reference.
 - simplified AKA sim card terminology

 One remaining issue:
     - this draft defines one algorithm (25519); carried in an attribute.
     - should we already from day 1 have two?
     - how to handle registration of numbers?
     - can we overload a registry?

Eliot:
     - are there other curves standardized?

John Mattsen:
    - p256 or p384 should be listed but one or two more optional
    - reuse where practical

Jari:
    - one has to customize for this use.

Tero:
    - what if you use someone else's registry and then you want to add a new
    algorithm but they don't want it?

Eliot:
    - Short term: agree that maybe need to create own registry
    - Long term: here we go again with yet another encryption registry.  Matter
    for IAB.

John Mattsen:
    TLS1.3 draft

    Two draft updates.  OpenSSL does not support empty application string. 
    Send \0. Same type of an issue with early data.  Not supported in library.

    some additional references.

    EAP-TLS 1.3 with PSK

Bernard:
    New modes would be viewed as an attack.
    Need a new code point.

Mohit:
    Keep document small
    Have separate

Joe: Anyone opposed to using separate code point?

No.

Joe: Anyone opposed to using separate document?

mixed hum

Owen:
    We need guidance on resumption

John:
    Relationship between EAP identity and NAI
    When using external PSK provide anonymous NAI.

Dan Harkins:
    PAKE selection process.
    Wait for PAKE?
    Offline dictionary attacks something to worry about in the general case.

Tero: PSK != password.

Dan: let's be careful that we can stop abuse with guidance.  Let's come up with
tools that are misuse-resistent.

Tero: you can't idiot-proof this.

Dan: let's not make arguments from an absurd position.

Joe: more discussion to be had.

Joe: identity binding certificates to NAI.

Alan on Identities

 - recommend use of NAI, anonymous @realm
 - common practice is that EAP identity derived from common name.

 - resumption needs to use same identity as original.

 Discussion around derivation of NAI.  Stick with anonymous NAI MTI and SHOULD
 be used.

Alan issue- have a separate identities section.  And then explain what this
means for each use case.

Bernard:
    - there might be more than one anonymous NAI.
    - using anonymous NAI happens before method negotiation.

EAP methods and TLS1.3 and various methods

Alan:  What to do with FAST?
 - TEAP updates belong here.
 - People are holding implementation on all TLS until they can do all methods.

EAP-NOOB

Toumas Aura

Did NOOB review
Two implementations
Formally modelled with mCRL2 and ProVerif
Stable implementation

Abhijan Bhattachrya

Gap in knownlege terms of securing devices.  This kind of solution could help.
Problem: When companies go to market, end customer would not like to use
anything that is non-standard. {Something about IANA} Push for adoption

Roman:
    Charter on review for final ballot in 2 weeks.

Joe: once charter is approved then we can go forward with adoption call.

BRSKI
Eliot Lear

Simplified the proposal. However, because of the many errata, it might be
better to adress TEAP, instead just BRSKI.

Mohit: I would suggest you separate the BRSKI from TEAP. Maybe splitting it up
might make sense. Eliot: I think it the opposite way - I do not want to sift
through different documents. Mohit: No strong feeling, I leave it up to you
expertise to decide.

There are a couple of places in the Errata that do require more discussions
(e.g., derivation). Others are small and we might want to just "Proceed" We
have new TLVs - we might slow-roll this, we might want to separate the
documents. There are some considerations that need to be worked out (i.e.,
802.11 capabilities - DPP or Others) The Next Steps - how do we deal with TLS
1.3 ? Let's focus on BRSKI, let's get some code working, and we deal with this
issue in the TLS document. In March the document should be in better state and
we might be ready for adoption then.

Joe: We should start knocking the Errata off.
Eliot: I will take the action to post the Errata with proposed solution. As we
do this in parallel with other things on TEAP being done.

EAP-CREDS
Max Pala

Focus on draft is to handle on mix of credentials.
This is an encapsulation mechanism.
Three different phases: initialization, management, and validation.

What has changed:
       simplified proposal.
       also added new text!
       defines SPP - simple provisioning protocol
    -
    So MORE simplification by removing SPP
    Many different use cases.

Liang Xia:
    What is the relation between this and what is currently done?

Max:
    this really takes into account appropriate deployment approach.  There are
    multiple input mechanisms and they may not match to output mechanisms.

Eliot:
    Be careful about kitchen sink approach, but possible merge opportunity. 
    Need to avoid fragmentation.  Let's try to reduce.  Why not have included
    SCEP, for instance?  Maybe merge with TEAP-BRSKI proposal.  Can we distill
    down architecturally?

Max: could use DPP through EAP with EAP-CREDS

draft-rieckers-eapparameterextension-00
Jan-Frederik Rieckers

Certificate checks are insecure.

  Questions to user that are meaningless.  Big issue for eduroam.

  EAP-TLS specification lacks information about whether cert is valid for a
  particular use.

Add new cert extension that adds a valid realm for cert.  Validatable by CAs if
realm is a domain name. > Looks a little like RFC 7585

But not the same scope

> Uae a specific prefix in domain name or CN?

Eliot: clarify use case
Jan Frederik: we need a way to bind a cert to a particular realm.

Bernard: this might be dangerous because a cert could get installed that fakes
an NAI realm.

Carsten: really helps to be able production systems such that it rejects broken
and misconfigured systems.

Alan: EAP-TLS certifictea have TLS web server OIDs.  It would help if we could
have a specific purpose cert.  There may be a need for an EAP practices
document.  This is an issue that is worth working on.

Owen Friel:

    ACME Integrations

    ACME needs the extension in the TEAP update.

    What's changed?

    ACME subdomain split into a separate doc. Nice optimization for issuing a
    large number of client certificates.

    BRSKI Cloud Registrar
    this draft only need be informational.
    Where does this go?

Max: how do you handle acct management?
Owen: TEAP server
Liang Xia: What is relation to BRSKI?
Owen: very little relation?