Skip to main content

Minutes IETF104: emu
minutes-104-emu-00

Meeting Minutes EAP Method Update (emu) WG
Title Minutes IETF104: emu
State Active
Other versions plain text
Last updated 2019-04-02

minutes-104-emu-00
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:

--------------

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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.