Skip to main content

Minutes IETF102: emu
minutes-102-emu-00

Meeting Minutes EAP Method Update (emu) WG
Title Minutes IETF102: emu
State Active
Other versions plain text
Last updated 2018-08-03

minutes-102-emu-00
IETF 102 - EMU Working group Agenda
Friday, 20 July 2018
Morning Session I 0930-1130

Minutes taker: Zhen Cao
Jabber: Rahul Jadhav

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

1. Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-00

John: Jouni implemented this draft and found the NewSessionTicket was
inconvenient

Darshak:  Point is well taken. We should not restrict NewSessionTicket. The
server could signal with EAP that it will send other things.

Bernard: You are not changing EAP. EAP-Success can be spoofed. Understand
exactly which state it is, not an EAP task but method specific. Reception of
properly encrypted message should take precedence over EAP-Success. At every
point, important to know if you are in continuing, success or failed state. It
has nothing to do with EAP.

Jim Schaad: Have the server send an encrypted content message. Will add latency.

Bernard: That's how EAP-TLS does currently with Finish message.

Darshak: Does sending this encrypted content message indicate that no more TLS
messages will be sent.

Jim: TLS content message (a record) to know when you are done and make
transition. That takes the place of the TLS Finish message.

Hannes: Differenced to other EAP messages. Before there were clear definitions.
What is finished actually? NewSessionTicket is still a handshake. Cram it in
earlier in the exchange.

Darshak: Isn't the TLS server allowed to send NewSessionTicket later. Are you
restricting it in EAP?

Eric: You want to know that there will be no more TLS messages? Profile TLS to
say don't do this. None of the Post-Handshake messages are needed.

John: Need more discussion on the mailing list. Could we use FLAG in EAP-TLS.
Bernard: If you use this and it determines cryptographic state, then you have
just introduced a vulnerability. Don't do that.

John: Piggyback Newsessionticket on the EAP-SUCCESS
Bernard: Not a good idea.

John: Key derivation with exporter : what's the best tradeoff ?

Mohit: I should be able to update openssl and EAP should magically update to
the new TLS version. But if the EAP is aware of the TLS version, then a lot of
these problems will be simplified.

Bernard: Problem with sessionid. Bunch of EAP methods use different prefixes.
Missing prefix.

Mohit: Its MethodId.

Bernard: Uniqueness of sessionid. You should have prefix in sessionid.

Hannes: how easy it is to get the randoms in diff TLS stacks, have access to
source code of EAP method, and reuse the implementation.

Joe: Moving forward we won't have access to master secret. We are moving
towards using exporters. IV and sessionID perhaps more publicly available
values.

John: IVs are now secret in protocols.

JABBER QUESTION: from Alan.

Eric: Not do old version. Please use exporter.
John: Use exporter. Will add prefix to sessionID.

Joe: Do we know who is working on implementations. Alan/Jouni?
John: We have a project but we are currently doing EAP-AKA. Don't have EAP-TLS
timeline yet.

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

2. Large Certificates in EAP protocols

Eric: ECC public key size compressed vs. uncompressed.

Hannes: May be you don't want to have endlessly long hierarchy. Reduce the
transmission inf overhead by use of cache info and client certificate URI.

John: Not using PKI or reducing number of CAs could be a point that could be
made in the draft.

Jari: Document has good options. Seems of protocol discussion. There is also
operational issues. Don't do deep hierarchy if its problematic.

Bernard: EAP-TLS1.2 very commonly deployed in large organization, you cannot
reorganize the organizational hierarchy.

Darshak: Using TLS cached information exchange still is a chicken and egg
problem.

Bernard: Opportunity to fix a lot of things with TLS 1.3. Going back and
telling people to change code is not likely to succeed. I don't think it can do
harm. It is weird that it is very draft.

Eric: Charter item is primarily about guidance, which is valuable. There 3
settings: people who already have deployed not change anything, the people who
are not going to change code. But those that are changing code should already
move TLS 1.3.

Hannes: Sometime the exchange does not work. We are not talking about this
never works. Once you get through the exchange and cache them. This is not web
environment where you randomly to talk to server. complicated multihop AAA is
when things break. And that is when you should have things cached.

Darshak: Fair guidance. A lot of this happen based on the size of the EAP
packet. Probably include that in guidance as well.

Mohit: If it does complete because of DoS protection in AP. Not able to use the
cache (experience from Hackathon)

Hannes: Then the recommendation should also be to reconfigure/change the APs.
RSA key sized that resist post-quantum etc. You can't have everything.

John: Would there be a security issue from caching cert chain from
non-successful handshakes.

Eric: Maybe you could do. I take your point why this would not be a problem.
But this is not how we rool and not sure if really need this. Some analysis on
why its okay.

Sean: PKI provides footguns. We can provide example of what not to do. Pick
shorter OIDs. I can volunteer to help you with that.

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

3. Improved Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA') draft-ietf-emu-rfc5448bis-01

Identifier usage: 5G has two distinct identifiers SUPI and SUCI. When network
begins in 5G use SUPI for key generation, otherwise behave as RFC5448. Ongoing
coordination with 3GPP R15 Specs

John: Have done a thorough review and no technical changes needed. Very much
ready but will do the review again. Security considerations section: demands on
privacy and eavesdropping issues higher. More text needed. What happens from
SUPI is not used.

Jari: Thanks. Will add to security consideration. This is planned to be part of
1st release of 5G. I think this should go forward as soon as possible. We
should initiate last call after update to the security considerations.

Sean: About timing. Fast months: 6 months, year. Usually it takes 3 years to
get anything done.

Jari: Takes longer time for new things. This is a bis.

Sean: I want to help. Let me know.

Joe: When we get an updated security considerations section. We could last call
it. There is little risk if 3GPP decides we are going to make changes. Then
there is problem.

Jari: I think 3GPP is ahead of us. I would like them to reference this 3GPP. We
are running project to implement this.

Joe: If we can identify implementations for EAP-TLS and EAP-AKA', that would be
good.

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

3. EAP-AKA’ PFS
draft-arkko-eap-aka-pfs-02

Planned for 5G Phrase 2

Hannes: DH Exchange, a concern of DOS attack. Can get server to do work.
Jari: Initiated from the network side. First request from server with DH key.
So attack is constrained. Hannes: EAP methods are not only used for classical
network authentication but also fro VPN access. Where it is initiated by the
client. Jari: All cases where I am aware, the client initiates connection but
it is the VPN box that asks for authentication. John: EAP-AKA in 5G with
encrypted SUCI the server will always use asymmetric crypto. Adding this is 2
PK operations instead of one and not an order of magnitude more. Russ: Without
this DH, where is the auth available for AKA'. Can you validate before doing
additional DH. If you are spoofed, then no point of DH. If you can order that,
it would eliminate thing that Hannes. Jari: Seems doable. Want to have
backwards compatibility. If not done. Russ: Send all but the order in which you
validate.

Max: is the public key is the same that encrypts the SUCI.
jari: We have our own exchange. And use public keys.

Russ: I assumed that you were using ephemeral DH
Jari : right

John: This is real-world problem. IETF BCP says we should do. Support to go
forward.

Joe: poll the support in the room, and clear for support. Against working on
this? No one. Will call for adoption on the list. Is on our charter. There will
be discussion of the details.

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

5. ANIMA and BRSKI topics (if there is time)

Jabber (Alan DeKok): Who implements TEAP? IIRC, it's almost no one . that does
make this more difficult. The other question is if the MASA doesn't trust
network 1, why is it doing an 802.1X exchange with it? Perhaps this is more
"not the right network" than "not trusted". I'm not familiar with BRSKI

Owen: Even on wired network. Pledge does not know whether to trust 802.1x
server certificate or not.

Nancy: MASA would not be in 802.1x path. TEAP is not used predominantly. Not
used because EAP-FAST is not standard. They are pretty much the same state
machine.

Subir: How is it different today when you have AAA infrastructure.
Owen: You are expecting that the network is well-behaved and reject the device.
Subir: If AAA is there. This is not adding. I understand BRSKI is not adding
anything. It is already solved with AAA. I will not get IP address if not right
network. Owen: Making assumption that network well-behaved.

Hannes: Big issue. Under cover of BRSKI came up with a new network attachment
procedure. The device does not have except. Wishy washy claims. Same issue as
Subir. Trying to change the way AAA works. The claim is that you need to talk
to the manufacturer for privacy reasons. Instead talk to MASA. Very few people
pay attention to ANIMA. We have bought into that concept that this is a good
idea of the alternative approach of network attachment.

Owen: You want to trust on first use. I don't need any pre-provisioned trust
anchors? Hannes: I want to have an honest conversation about what we are trying
to accomplish with this alternative network access authentication
infrastructure. When I read BRSKI I see problems being state. Later the same
problems being resolved using things that are solutions you complained about
and found problems in. You complain that it is difficult to put manufacturer
certificates on the device. Later you use them. You claim about privacy
implications of running exchange to the manufacturing AAA server. Later for
security reasons you still have to interact with the manufacturer. Whole thing
is marketing nonsense.

Subir: If I deploy AAA infra? Do I need this? Good to have a section if I
already have AAA infra, what is the benefit? Owen: You are asking what is the
benefit of BRSKI and not what is the benefit of putting it here. Subir: I don't
know the trust network. This gives benefit. With backend AAA infra it already
happens today. I am not given IP address or any resource. Brian: BRSKI is
allowing you to the point where you could authenticate the network instead of
moving on. You could move on all day. This is getting you to the point where
you are provisioned with credentials. Subir: If MASA says network B is network.
That will fail right? Brian: Little weirdness here in slide. Alway enterprises
decision whether to trust a device or not. MASA is helping it determine. There
are cases where enterprise use MASA for something more. Enterprise can decide.
Nancy: BRSKI. Help endpoint know that that network infrastructure is to be
trusted. You talk about AAA infra. The diff here is that the AAA infra does not
have the right identity which is what BRSKI is trying to help. It is trying to
provision the right identity. Subir: There are other ways to do that. NEtwork
discovery with 802.11u. Nancy: Chicken and egg problem we are attempting to
solve with BRSKI. 11u is the other aspect of how to do signaling. WE could use
DPP 11u. We could use extensions. That's separate piece. Can embed on WiFI
while you are in that 802.1x channel.

Max: This is provisioning mechanism. This is not. That comes as a good benefit
afterward. Totally support that. TEAP already supports. Maybe have more general
approach for provisioning method. Maybe a generic EAP method for provisioning.
Using TLVs rather than own method. Seems easier method. However, problem that
TEAP is not implemented. However you could do a separate method and combine
that with any existing tunneling method. Through other already deployed
methods. Then you don't have to implement a new EAP method. Owen: TLVs are
simpler. Working assumption that we are going to ship EAP-TEAP quickly. Nancy:
Could be its own EAP method. by establishing that TLS tunnel. It makes security
and privacy considerations would be more complex if it is was a standalone
method. Max: Understand your point. There is an opportunity to have generic
provisioning. Nancy: That is fine. If that is what group wants, we could update
the draft. Security is improved when you run.

--- From Jabber ---
Henry B Hotz
Maybe not possible to improve, but it seems like there are steps where the
device is trusting things it doesn't yet know it can/should trust. How does it
work (properly fail) if Network A is evil?

Alan DeKok
but if 802.1X succeeds, then the network is trusted. If the MASA later rejects
the network, it means that the network is known and trusted, but not the right
network if network 1 isn't trusted, why does 802.1X succeed? Why would the
device trust BSRKI data sent over an untrusted 802.1X configuration?

Henry B Hotz
Suppose Network A and the MASA that Network A connects the device to are both
evil?

Henry B Hotz
Of course the device may not have any value to an attacker if it knows that
little. Simplifying: suppose the attack target is the device, not the network?

Alan DeKok
Hmm... I guess this presumes TEAP provisioning, which wasn't clear from the
slides. I'll withdraw my questions...

--- END From Jabber ---

Owen: Completes 802.1x. MASA has not issued voucher. It will be device side
logic. I had to trust on first use.

Mohit: No hat. I have the same question. Why did 802.1x succeeds if it is not
the right network. Nancy: It doesn't. Mohit: Why does it get DHCP, IP address.
That is how 802.1x. You haven't solved the problem to connect to the right
SSID. You assume that this could be the right SSID. Which is fine. And now you
connect and you succeed. Owen: That is the problem we are trying to solve. You
unbox a device and it sees 20 network and it does not know which one to
connect. Mohit: So it tries. So why does it succeed? Joe: Not in charter and
cut the mic line; Mohit: How do I know which manufacturer to send it. Owen:
Based on IdevID. Mohit: Now 802.1x all Authenticator/AP which server to talk.
Now TEAP server should know which BRSKI registrar to talk to. Setup security
association to registrar of different manufacturer. Owen: Registrar will be on
prem. IdevID will tell Mohit: Additional configuration to associate with
different manufacturers. Setup AP, server and then server to different MASA
server. Sean: Having lots of flashbacks from when I was an AD with all EAP Fast
and TEAP and TTLS. TEAP is a protocol that is standardized by the IETF that
went through the working group process. It was bloody as hell. At the end of
the day, the proponents are doing the right thing. BRSKI is a working group
item for another working group. And they are asking how this could be done.
This is more than Cisco wants to do this. There is more than Cisco people in
that room so I think we should consider that. You can question if it is used or
not but at least it is being worked on at the IETF.

Hannes: Sean tricky issue. I have complained about in the past. There were
several different provisioning protocols being worked upon in the IETF
concurrently. It was not just ANIMA but Netconf with 0 touch. Lots of fancy
names. It gives the impression that you magically solve some really hard
problem. No configuration and everything just works out of the box. Whereas in
reality we just move the problems around. Instead of regular authentication
exchange to the AAA all the way to the manufacturer we are now setting up the
backend infra with vouchers etc. which looked like research efforts with
whatever the other ANIMA dynamic network bootstrapping was. Nobody paid
attention to that. Now we are looking into this. What is this actually. Oh My
God. All these claims at the beginning and what it does and what the problems
are. I feel that I mislead. I am going to write this up.

Joe: Issue with BRSKI and those need to be taken up with.

Eric: purpose of the presentation?  What is the purpose the presentation. You
want adoption. As I recall it would be out-of-charter so does this require
re-charter. My question: bunch of work going on already. Would you be able to
take on this work? May not even viable for WG discussion??

Joe: Difficult to tell right now. We are just bring on.
Eric: Just chartered a month ago.
Joe: Most of the work in charter is straight foward. With AKA PFS more work and
analysis is needed. My concern here is just making sure that we don't have a
common idea of what BRSKI is, or what these other things are. That's going to
be difficult until we get that.

Eric: Figuring out what is the sensible way to move forward. People can yell
each other a lot longer then. Jari: Not sure fully understand. Checking my
mental model. You have a very particular way of doing things. Bootstrap a
device. Talk to infrastructure and infra puts you in sandbox and you can do
enrollment and after completion you can do the proper thing. That seems a fine
thing at the architecture level. You still have many question. What level is
right. Doing it at the EAP level. Doing in a tunnel. Lots of choices. Following
up what Hannes. You have a problem. You still have to solve the problem even if
you move it to this sandbox stage. The sandbox and device still needs to have
an association. That should be recognized that is a necessary step.

Owen: When device bootstraps with IdevID it is put in some kind of sandbox
network segment where it can continue provisioning. Jari: In theory, you might
do a regular attachment on open sandbox SSID and then just do regular IP with
web exchange with somebody. you wouldn't have to anything at EAP level. Owen:
BRSKI exactly covers that kind of flow. Connect to fallblack registrar in the
cloud. BRSKI supports multiple types of flow. Max: Provisioning thing for
802.1x. Could be useful in some use cases (cellular network)? We might do
re-charter. This could be initial work. I would like to see re-charter that
looks at provisioning with EAP. Important work. Brain: Reflect the main
contribution is removing the whitebox. It is handling withing 802.1x. The slide
with complex device side workflow. Zhen: Need a use case draft, well documented
first Owen: We can make some edits to the draft. Alan: I owe a draft for fast
re-auth. Joe: not in charter right now; BRSKI is ANIMA. need to talk to ANIMA
chairs. See where they are at. Not just an EAP method. It is more than that. It
is an architecture. Beyond the original charter. If there is or consensus in
the IETF to move towards this architecture then that could be withing our
scope. Max: I don't think it is related to architecture. Underlines an
architecture but the architecture is not in scope of the work. Ask chairs if we
can recharter adding this type of work. Joe: I think there is an architectural
change. It is not for this group to decide that change or not. We need to make
sure. I don't want to spend a lot of time and argue a long time about what we
are going to do here and then find out that ANIMA is not pursuing this
direction. Or find out that there is not consensus in the IETF to do this.
Hannes: Elaborate on architectural change. Previously sandbox was at
application layer with CoAP/HTTP proxy. That was used locally. That is moving
to lower layers. We are trying to make an optimization. Also checked IPR
situation. Worthwhile to consider. Several IPR filed on the BRSKI stuff. Jari:
Bootstrapping is interesting after finishing the current work; If we were to
do. This WG cannot be responsible for the architecture. We would still have to
be convinced that we need a sandbox at our layer and that is a sensible
architecture. And about mobile networks can benefit from more generic
bootstrapping. There are many solutions outside EAP. You have hardwareless SIM
cards and also some deployment. And not a space where nothing has been done in
the past. That should be kept in mind. Joe: Can have some discussion on the
list although we really need to make our other work items a priority. But if
this becomes a distraction then we will have to take it off. Next steps is for
chairs to sync up with ANIMA and see where they are at and then talk with our
AD and amongst ourselves and come back to the list. Max: What is criteria to
define whether distraction or not not and don't care about other things. Joe:
Right now it is not in charter. If it becomes a contentions discussion and if
people are spending more time on this than chartered items then that become a
problem. Max: IS re-charter right now. Joe: Right now we are not re-charting.
We are going to look at what will be involved in re-charting and why we would
re-charter.

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