EMU WG
          
          Note Taker: Massimiliano Pala
          Jabber Scribe: Elliot Lear
          
          - Administrative and Agenda Bashing (Chairs, 5 min)
            Note Well, Note Takers, Jabber Scribes, Agenda Bashing
          
          EMU Agenda:
          
          --------------
          
          . draft-ietf-emu-rfc5448bis
             Jari Arkko (10 min)
          
              - Presented comments and updates post-WGLC
              - Two reasons for this draft: new technology has been developed and
              we needed to address some security and other updates
              - Comments and Questions are mostly related to technical clarification
              and editorial changes (i.e., hex vs. dec in the document). Two main
              points were presented
              - Permanent Identifiers fed to the KDF: SUPI and KDF
                      * You have two different identifiers (SUPI and SUCI), usually
                      the SUPI is not sent over the wire, but in our protocol
                      it is used with the KDF - there is an inconsistency with
                      3GPP behavior (TS 23.003 Section 2.2A and Draft Section
                      5.3.1.1). We need to be sure that the format is the same,
                      otherwise keys will not be calculated correctly. Moreover
                      SUPIs can be either IMSIs or free-form NAIs - while the
                      draft represents everything as NAIs.
              - New underlying attacks against AKA. When we do authentication
              protocol using some other protocol as a basis, it is our jobs to use
              those protocols and document when the underlying algorithms needs
              to be updated.
              - The impact of the attacks (eprint.iacr.org/2018/1175.pdf) - the
              specific attach is a replay attack - you can try to authenticate
              three types of messages: ok, sequence number failure, or crypto
              failure. By using the sequence number failure the attacker can
              discover if the replay attack can be achieved by changing some of
              the challenges. The attack is perceived as impractical in 3GPP and
              that is the reason why this attack has not been addressed there yet.
              - Plan to work this week and incorporate this in security
              considerations
          
          Mohit: the attack seems related more to AKA rather than EAP-AKA and uses
          the mechanism to re-synchronize the sequence numbers.
          Jari: what solutions will 3GPP provide? I do not know, we can not predict
          what 3GPP will do,
          Stephan Santesson: Downgrade attacks. Is there any new material coming
          to the draft
          Jari: I think we covered the downgrade attacks and we think we covered
          all we needed to cover
          Joe: We will need a new revision
          
          . draft-ietf-emu-eap-tls13
             draft-ms-emu-eaptlscert
             John Mattsson (30 min)
          
              - Two document updates since the last IETF.
                  * Mandated privacy protection of identities
                  * Differentiate between TLS fatal alerts and warning alerts
              - 04 has some changes following implementation consideration from Alan
                  * Borrows the term privacy-friendly identities from RFC5448bis
                  * Support for Emergency services (EAP-TLS without peer
                  authentication)
                  * Mandatory revocation checking and OCSP stapling
                  * Clarifications on key derivation, use of ‘L’ bit and
                  fragmentation, and security considerations
                      TLS HellopRetryRequest support
                      Key Derivation - other TLS EAP method could use this
                      specifications for key derivation.
                      Extended types support - shall we provide support for other
                      methods?
                  * Early Data. It is clear that EAP-TLS does not have any use of
                  Application Data. Protection of application data
                      Sean - if we do support early data, we need to make sure we
                      say something about it.
                      Mohit - we shall not use application data in EAP-TLS
          
          Mohit: some of the TLS libraries support sending the context but other
          libraries (e.g., WolfSSL) has not implemented - we shall make this a
          requirement and then force libraries to support it (RFC5705).
          Eliot: We might want to have extended types somewhere (Alan’s draft)
          Joe on Protection of application data: We shall focus on this draft -
          there is no point including all other methods - with respect to early
          data, since we have no use for it, maybe we can use something stronger
          than Ignore
          Jari: I agree with Joe - what about cross method resumption
          Mohit: On the list there was some discussion, however I would not want
          to support it
          
          Presentation continues:
          
              - Further feedback from Jim and Alan about caching information
              - Save extended information about the protocol layers below EAP
              - Just cache information from the TLS handshake
          Mohit: EAP method do not have access to extra information, and therefore
          currently we do not have channel binding
          Alan: Realistically EAP is used within another protocol - to certain
          extend EAP implementations is only aware of EAP while the encapsulating
          protocol might be aware of these. Maybe if EAP is aware of these extra
          information, it should use it
          Mohit: I am in favor for providing the information - I was referring to
          the fact that not all implementations have access to this information.
          Alan: Not all implementations provide this data, but I believe that it
          is important to provide it
          
          Roman (AD): Should we have a place to track all these implementations?
          Joe: we will setup a page to track implementations either on the Wiki
          or in GitHub
          
          
          Large Certificates and Long Chains handling:
          
          draft-ms-emu-eaptlscert-02
          
              - New co-author Sean Turner
              - New document structure that addresses considerations about the
              contents of certificates
          Joe: anybody can commit to review ?
          Eliot, Max, Anoop and one more person to review and provide comments.
          Joe: when we have reviews, we can work toward a WG adoption.
          John: Allowing the use of cached certificates from a non-completed
          handshake ?
          Joe: we might want to discuss this on the TLS list and we’ll have to
          see the amount of required work
          
          
          
          . draft-dekok-emu-eap-session-id
             draft-dekok-emu-tls-eap-types
             Alan Dekok (remote) (25 min)
          
              - TLS1.3 and TLS-BASED EAP-TYPES
              - Key derivation has changed - this affects many EAP methods
              - The simple solution
                  * Update EAP-TLS to include Method-Type in key derivation and
                  update other methods to use the similar key derivation
                  * There is no reason for each method to define their own key
                  derivation
                  * In this document we provide guidelines
              - The Harder Solution
                  * FAST and TEAM have complex key derivation
                  * Maybe some external review is needed
                  * PEAP is vendor-defined
                      Can we update vendor specs ?
                      Maybe we can use the code from PEAP ?
                      Discussing with Microsoft
              - Security Considerations
                  * There are many issues related to EAP and TLS
                  * Some are discussed in EAP-TLS - others many need discussing here
                  * Question for the group is: what other considerations should
                  be added
          
          
          Eliot: Am I actually using TEAP correctly in the other draft  - I am a
          bit nervous going too fast on Section 2.2
          Alan: We would like to see more implementation for TEAP so that we get
          this right
          Joe: Only 2 people - non-authors - have read it, however it is very
          important that we get this right.
          Alan: One comment on this document - one reason this came up, during
          implementation we felt we need to address other methods as well when
          updating the EAP-TLS.
          
          
          
          draft-dekok-emu-eap-session-id
          
          Presentation:
              - EAP-Session-ID has not been defined for several methods
              - Vendor-Specific methods are likely to have the same problem too
              - We need this for ERP (RFC 6696) and FILS (IEEE 802.11ai)
              - I do not think there is controversy here and the document should
              proceed quickly
          
          
          Joe: this seems straightforward and we can progress this very quickly
          
          
          
          . draft-aura-eap-noob
             Tuomas Aura (15 min)
          
          Presentation:
          
              - EAP method for bootstrapping devices out-of-the-box without
              professional administration - we do not assume the device has any
              identity
              - Minor changes in -05 and -06.
              - A bigger change is that we add one round trip to each exchange
              to deliver the latest PeerId and peer state to the server without
              updating NAI (to comply with RFC 3648) and better randomization
              - Continued the work on formal models: mCRL2 model (protocol -
              messages and state machines) and ProVerif model (cryptographic key
              exchange and binding/mis-binding)
              - Misbinding attacks are possible - if the UI is compromised on
              a device, then the user might be tricked in pairing with another
              device instead of the compromised one. There are different ways to
              mitigate that problem: device certificates, asset tracking through
              organization, etc. The report is available as a research paper and
              more in SAAG.
              - Output from the Hackaton might have an impact over the
              specifications - can we randomize PerrId ? It is not easy because
              Identifiers update must be synchronized and should not be vulnerable
              to misuse of fall-back identifier
              - Other issues on our TODO list - error handling and timeouts and
              hooks for application layer configuration (URLs)
              - Recovering from dropped messages is important: dropped last message
              in bootstrapping can cause failure. Also dropped last message in
              crypto suite upgrade could cause persistent failure
              - We would not like to introduce the crypto suite update recovery
              method to avoid complexity
              - There seems to be interest - this could be a work item
          
          
          Discussion:
          
          Eduardo:  From Murcia University, interested in working on this
          Dan Harkins: what transport did you use ? .1x - isn’t your method
          vulnerable to MITM attack ?
          Tuomas: No, the dynamic QR code is the OOB that provides the
          authentication
          Mohit: the hash of the keys is sent not over EAP but OOB
          
          
          
          . draft-lear-eap-teap-brski
             Elliot Lear (15 min)
          
          Presentation:
          
              - BRSKI Addresses autonomous on boarding of wired devices (requires
              initial IP configuration)
              - This draft internalizes protocol into a new AEP method
              - Changes since Bangkok
                  * Clearer motivations
                  * All the TLVs now clearly defined down the bits
                  * Added IANA considerations
                  * We borrowed the NAI component from EAP-NOOB
              - One Issue: What if we use an IANA parameter that create a
              parameters.arpa
              - Other Issues: We need to cleanup the text and we need to do a lot
              of coding
              - We need to address offline use case
                  * Adding a “not available now, retry in XXX time period”
                  * Still need to solve the SSID selection problem
              - We shall also provide privacy considerations
          
          Florin B: Can you provide some details about the SSID selection ?
          Eliot: How do I identify the SSID that supports BRSKI ?
          Dan: Maybe you can define a pre-association blob in the advertisement
          Eliot: We might not want to use something protocol-specific
          Florin: What is the use-case that you are trying to address
          Eliot: Even if you use AQNP the selection of SSID is still a problem
          Karen: It seems that you are referring to the Policy
          Eliot: Maybe we need a bloom filter - you might reduce your hunt
          considerably without getting into Policy
          
          
          
          . draft-pala-eap-creds
             Max Pala            (15 min)
          
             - Thinking about this. Presentation to see if WG is interested
             - Not ready for adoption
             - Securing managing credentials is problematic
             - 3 phases of the protocol
             - Simplify the messages
          
          Joe: One thing from the chairs. We are making progress on our work
          items. It may be a good time for us to get together with the AD who is
          coming in and see what the potential is. We have a number of proposals
          that are coming in that are somewhat similar. All trying to address
          slightly different problems but the theme is similar. We should start
          looking at this. We will chat with the AD to see their view
          
          Florin: What type of credentials are you trying to manage
          Max: We want to be generic than just certificates
          Elliot: Side meeting on Wednesday. Lot of back and forth flows in
          particular order. All these sort of conditionals. If you subsume all
          these methods, I am not opposed, but think about whether it is the right
          thing to do. Your document will get very very big.