Internet Engineering Task Force 102, 20 Jul 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF102-EMU-20180720-0930

Description

EMU meeting session at IETF102
2018/07/20 0930

https://datatracker.ietf.org/meeting/102/proceedings/

A

All right welcome to the EMU session at IETF, 102.

A

Hey think everything's good.

A

So the big piece of news to announce is we have a co-chair. Mohit has agreed to co-chair with me appreciate that.

A

So has anybody not seen the note well, yeah, just raise your hand, if you haven't seen the note well, you guys are jokers. I can tell so. Hopefully you have actually seen this so we'll move on. So we have minute takers and jabber scribes. The blue sheets are going around remember to always state your name at the mic, and we haven't had too much problems with people being non-professional in this group. So I don't think that's too much of a problem, but just remember we're all working for the same thing.

A

So for the agenda. We have a couple topics that have to do with the TLS, then a couple topics that have to do with aka and then I believe we'll have some time at the end, to kind of get an update on some using teep with anima and brewski. So we'll see if we have time for that at the end, I think we probably will, but we want to spend more time on the working group documents and documents that we're going to be taking into you know, hopefully a part that our part of our charter.

A

So right now we have EPA using eto s with TLS 1.3 and we have.

A

Improvements to Ebay ka prime, are both working group documents. So is anybody have any other agenda items or anything else? They want to discuss all right. So, first up we have John Metz and you want the control. Let me just get this. Thank.

B

You yeah, so this is now working groups adopted the draft using epls with TLS 103.

B

So quite small changes and since the non-working group adopted some editorial changes been checking, it was one sentence that was rewritten on resumption based on a comment. I, don't remember exactly who comment on that and then I notice is that the new labels for the key derivation did not follow the recommendation. 5,000 or FC 5 7:05.

B

They added the exporter birds and what had happened since then is also that joni Malinin has implemented the previous Maxon draft and yes on implementation, comments and some suggestions, and that will be the main topic of this presentation so Jim its first issue that he commented on when he implemented was that in TLS epls with TLS, 102, you're, quite sure the client knows what will come in the next step in TLS 1.3. That's not the case anymore.

B

If the observer is not supporting resumption, then after the clients and still has finished the service and if success, if the server is supporting resumption of the dead finished, the observer will continue to eat method and send the TLS new session tik it which is used for resumption, and the success comes in a later stage.

B

So you miss analysis of this is that the appear does not know whether the new session ticket will be delivered or not, and this leads to different handling. If you follow the herbs for one three, seven state machine, deep state machine in TLS previous versions, you can set it methods day to down and decision on Kong success until s monetary unit says that you need to set this to make. Hunt and decision common success and uni describes this as a bit inconvenient.

B

And yes, if there's ways to avoid this uncertainty and also latency, very introducing and you, the latencies. With the new session ticket, you get less latency equal to the old versions.

B

So I would be great with feedback. Is this something we need to address, and also comment from me on youngness comment is that new session ticket is not the only same the TL thing, the TLS 103 server cancer? Theoretically, it could send several new session tickets and it can also send up their post handshake messages. How likely that is to happen or not, I, don't know, but we I think at least the ETLs monetary dot should be clear on that.

B

What the client can expect, and if you want to do the things that you me suggest and we would basically restrict it TLS to a subset of epls, know: TLS 103.

B

If you have any comments, please.

C

There should travel CableLabs, so I think the point is well-taken right, but I guess, which probably shouldn't try to completely restrict it right. What we may probably be able to do is or if possible, is somehow actually in EEP right here. Eep responds have a signal where certainly indicate that it may send other things where the client can be aware of it, and that would be an e plural thing rather than.

D

E

Got some problems that are resulting from this? You have to have it be very, very clear, because you can spoof ep success if you're very, very clear about the state. The success state of ETLs at every turn- and you know allowing things to happen in different orders is is. Is it gonna be a problem for you? So you know it's. Basically, the reception of it and a properly encrypted message should probably take precedence over a success, but you don't want to be in a situation where you, you know.

E

Basically, a spoof success can actually change state and like a spoof, success can happen at any time, and the transition to a success state has to be driven by the e. The TLS state machine can't be driven by by spoof of old messages, so I think you're, potentially getting yourself into trouble here. If you, if it's not clear because in the originally TLS document, is very very clear when the state transitions so.

B

If I understand you correctly, you would like to have it under some additional information or restricted messages that can be send yeah.

E

I mean that the clear thing in your mind is to understand it. Every point: you must know whether you, whether you're in a continuing state or a successful state or a failed state that has nothing to do with EEP. It has to do with your math, your method and, if you're, if you're unsure you can't, you cannot allow the success to determine that success may not be delivered. It could be spoofed right. It's not that's not the thing that determines whether that the tls exchange is successful or failed.

F

Would a reasonable response to this, be that you're always going to want to spend. Unfortunately, it is used to do some additional agency, but would you always want to actually have this? The server send out one encrypted content message which says I'm finished because then you actually then in the TLS machine. You know when you're done.

E

That's kind of how we a PT LS works today is you're dependent on a finished message, and that's that makes the determination of the transition to success.

C

So so would that be like? Are you talking about a TLS message on an EP message? Okay,.

B

So what was to say, wait until you get something encrypted with TLS yeah, but that would be done TLS what just encrypt nothing and send it in requests. That was to see you soon.

C

So so so what I think is if this is so, the finished message is supposed to indicate that, after that, the TLS will not send any more session tickets or any new messages. Is that what it's supposed to indicate?

C

So the problem here is that the the TLS near it may send new session ticket messages after supposedly the TLS handshake is complete right and if it doesn't deal with, doesn't know what to do with it now sending a finished message like an indication that, from now onwards, the TLS server should never send a new session, because if it sends it then you're still in the same problem.

F

I'm not saying okay I'm, not suggesting the use in Athey LS finished message. What I'm saying is written the TLS server is going to send and in a Content message, a record which says I hate. You are now finished with all of the handshaking, because then you know exactly when the server says you're done and then you can make the transition so that takes the place in of the TLS finished message for EEP 1.2.

G

And this is honest, so I I think I'm. One of the the difference is to earlier or to other EAP messages that initially you had this very clear distinction between the EAB method and then, when it's finished versus ndls 1.3. There are these post handshake, authentication messages and that didn't exist in us doesn't exist in one or two.

G

So that's the question of what is actually finished really well that the the new session, the new session, because it is still a handshake after all, so of course you can say- maybe you definitely want that feature and use the session ticket functionality is a it's a very useful feature after all, so you probably you could actually cram it in earlier into the exchange and then only do the finish afterwards. You, you know what I mean EAP finish afterwards, strictly speaking,.

C

When you send the TLS ever allowed to send the TLS session even afterwards like so something is there any criteria and where you're, restricting when the DNS server cans isn't, is allowed to send into your intel as it's allowed to send the new session ticket message, but in EP you would have to restrict it somehow. It's.

B

Also allowed to send other things.

H

So they're workers well I'm. So sorry, I'm not like super familiar, the MU I'm lemare tell us um so is the situation is that you would like to not to know there's knocking that won't be anymore, kill us messages after a certain point.

B

It's pointed out as a inconvenient thing by the implementer Jimny and also not seems to think that that's not good. You shouldn't know this date right.

H

Me so so I'm surprises inconvenient actually because most of my express taxes absorb this information as it comes in I mean if you know, reapplication your messages. You'll just you'll just consume them, um but um it's hard not to, but in any case I, don't there's a technical problem, obviously, which is profile as to say. Don't don't do this I feel like there's a I mean like like none of the post in check messages are needed. uh You know as a practical matter.

B

We probably need one new certainty, but you're saying we don't need it, probably not nothing more. It's not something expected come in the future that so, if we restrict it, it will break in the future.

H

One thing, I would say, is I get again from a staff perspective. um The way the most hellish tasks I'm familiar with work um is that you're on once the handshakes complete you just like basically I mean depend on their interface. You basically just like read off the stack and you're like give me more get you pass in dating you're like giving me more data, and because you can't see from the content-type what that data is. You like don't know what's happening, and so like the NST I, don't even know like I.

H

Don't take NSS like even has a callback for like NST was delivered, and so, if, if you want to have state machine, that light continues to read off the stack until like the anaesthesia laverda, then it's like now I'm done with I'm like done with that. For the context, that's like not super easy to do so. In that case, you might wish to have I mean you might wish to have an application, a message just for like just like speed that process along right.

B

I think this is something we need to discuss more on the list in detail its own suggestion from universe. Can we inform the client somehow about whether the killer service intending to send more information? We have four five reserve beat in the heat TLS frames, which could potentially be used, but it's not secure and I. Don't know how much if the TLS server itself knows whether it's going to send the information and even if the TLS layer knows I, don't know it, ETLs layer would know. Yeah I see people shaking their heads.

B

E

You use this and if it determines cryptographic, state you've just introduced a vulnerability young today.

B

Then next years, showing from also from yoni, he did not like the additional latency for the sending the resumption new session ticket, and you need wonders if the new session ticket could be something if success is, as this would remove and search engine latency, but would require an update of our see three seven. Four, eight.

E

You start changing the EEP success. Measures cannot break NASA's, you just your bust everything, don't don't even think, don't even go. There. Yeah seems to.

B

Seems to be agreement in the room not to look into this, then you miss last comment is about the key derivation, so the key duration in RFC 51 six looks like this in the TLS 103 drove. This is changed to to use the TLS exporter, and this recently it could support from Alan on the list. The key duration is one of the things that has previously most interoperability problems for ETLs. So this something that really should be.

B

Spent on proton yeah Germany states that having some a different key derivation for ETLs is, with the same words of before a little a bit inconvenient, and he as if this is really necessary.

B

The new. This is basically what, if you would design it today. This is probably how you do. This is how quick must export from from TLS, so the previous. Basically, the key material is I think compliant with the TLS exporter. The IV derivation is not, and you basically needs to have the TLS implementation some way then or you at least you need to implement the TLS PRF yourself, the session ID either you need to do this out of TLS, so you need to look at the TLS messages.

B

So yeah is there I, don't know how big inconvenient is it to have a new key derivation? What's best trade off here.

B

No matter what I think it's need to be dropped should discuss what kind of interface we expect between TLS and ETLs. Okay,.

I

So I guess Yanni's concern is that ideally I should be able to update my open SSL from TLS 1.2 to TLS 1.3 and II magically uses 1.3, but in practice it's it's not that easy to do so, then, if you have to make the e player aware of which TLS portion you are using, a lot of these problems will be simplified. So then, then you use one or the other based on the TLS version. That's yeah.

B

My my understand is that we will need to make the TLS client implementation aware of the version anyway, because of the different message, loops, I. Think there's.

E

A problem with the session ID because, if I recall correctly- and this is something you need to think about where you're doing this a bunch of the TLS based methods, I, think use a similar session ID with a different prefix, I'm, correct they yeah so and I. Trying to remember why I think it was that tag was meant to differentiate like TLS from TTLs from.

I

E

It's a method, ID.

I

E

So eliminating that is I'm and I think the reason was that they wanted to have a unique space for the session ID within each method. So eliminating that is probably a gonna cause, a problem because it'll it'll bust the uniqueness of the session IDs okay, so you said that should yeah you should have a prefix I. Think, okay,.

B

Yeah, the preface okay yeah.

G

um The Sun is I wonder how easy it is in general to get access to the random values in different stacks. Did you look into that? No.

B

Of course I did you have access to the source code? All you can dig it out from the TLS packet looking at by 6, but that also it then you need to know that randoms have a fixed length if that changed in the future or something and you might get into problems again, but this is something you can dig out from the from the package. What what PRF you're using you.

G

Probably cannot yeah.

B

G

You may have most likely have access to the source code for the EAP for that specific EAP method, but the API is typically don't make that information about him and you may actually want to reuse the implementation for now across multiple different layers, so wondering um what are that's such a great idea.

A

B

You mean that you you're commenting the old thing, and you say that that's not the good right.

A

There I think Jeff's alibi, I think we're the way TLS stacks are moving. Is you you would not necessarily have access to the master secret I mean that's why we have exporters so I think moving forward. We would rather use exporters I, guess the the one thing that I haven't really thought through and I. Don't know if it makes a difference, is that well, the key material is secret, I think the IV and the session ID are perhaps more publicly available values that were deriving from the secret key material directly.

A

I, don't know if that matters. It really shouldn't I think but changed.

B

A bit I think I be now typically our secret in some protocol, for example, TLS yeah, okay,.

J

Allen decock from jabber my implementation already has the code to deal with different TLS versions: open SSL version et Cie, adding one more isn't difficult.

H

Eric rajala yeah. Please do not continue to do the thing that is 5216. It is not awesome. um It's a bit inconvenient.

H

I'm, assuming that the session ID doesn't have any cryptographic properties because like that is that a construction is not taught, is obviously not tied tightly to the connection anyway, so yeah anyway, so I think there's exporters the way to do this now, yeah and so sorry about the inconvenience so.

B

Then the agreement seems to be to use the TLS is portable to add prefix to the session. Id I mean that's. It.

B

Wanted more feedback reduce, of course, implementation that we can do intro in future.

A

Do we know who's working on implementation? It sounded like Alan was in uni was, do we know.

B

We have, we have start our project, but we are currently implementing a que. Ok things it's in the plan, but I don't have a time. Ok, thanks.

K

A

Large ticket chains in ETLs.

B

So this is a very new draft submitted this week, but some of the information is taken from the TLS 1.3 draft, and this is one of the shorter items it was raised on the list. You in the shorter discussion that this is a problem. I will describe so my last meeting. It was agreed that it should be a separate drop. It should not include that in the eat. Till s103 draft says what the shorter says said, and yes, you. This was this week's assume. Nobody has read it, but I will go through.

B

It would like feedback if the working group thinks this is a good start. Is this the kind of information we want in this draw? If we are doing a talk like that in something we see?

B

So what's the problem to begin with certificate change can be quite large in size, individual certificates can be large in the first place, and then you can have quite long. Certificate changed to to six certificate in the chain is not uncommon.

B

This implies that it tell us need to be fragmented for transportation who were they empty. You example yeah. It's a big legacy, but they also caused a lot of connections to actually fail, and this is because quite many had tentacles I. Don't have any numbers on how many that stated by add on another on the list that a lot of implementation actually drops the session if it hasn't finished off their 40 to 50 packets, and if you have a quite large certificate chain, this is bound to happen.

B

So, even if the peer and server have have credential to do mutual authentication, the session might fail because the authenticated shut its down and you don't have any mechanism to easily recover from this.

B

So this the drop describes this and any discusses different ways that you can get your certificates and certificates change smaller one one solution is to use ECC cryptography. Then you get a little bit less public keys. You get smaller signatures. This can be used with all versions of TLS and it's mandatory team.

B

Yeah- and it would be this if somebody used in.

B

So another solution attorney is to omit certificates when that the other endpoint is known to possess, and when you think TLS one or two or earlier it stated that only the self sides that it get that specifies the root certificate authority might be, may be omitted in TLS 103. You can omit any certificate in the certificate chain that the other endpoint is known to possess.

B

So this can make quite a large different. This makes a small difference.

B

New draft is, the solution is to compress.

B

The solution please, yes,.

G

Also because you talked about the chain, so maybe you don't want to have a PKI deployment with endless long sort of hierarchy that would obviously make things easier as well. Furthermore, you can there's also this other work that we did specifically for dealing with with or reducing the transmission overhead, which is a two-fold the cache team for, as well as the certificate, your I trying certificate. You are I, don't know if you have it on the next slide. Yeah.

B

In comes on our.

G

B

One sorry yeah, but not using DKI or reduce the number of certificates. Tortoises. Of course, point that could be making the dropped.

L

Yada yada, that was actually at the point that I also wanted to emphasize so so this document has some really good options in it, but, but it seems more of a like a protocol, discussion I think there's sort of a companion issue of operations like how should you run your thing and obvious advice, of course, is: don't do that if it's, you know problematic, but maybe that that's too simplistic and that there might be people in the room who have experience about systems where they've had to do this deeper hierarchies for some reason and and be interesting to hear from them and and see, if that's the case, and if there's other technical of other issues that that forced that, then what we could do about that.

L

E

We're not above a Microsoft apt TLS is very commonly deployed in large organizations which and the certificate authority structure parallels the organization structure, so you'll have a large company with multiple subsidiary companies with organized engineer organizations blah blah blah, which is what yields you know, yields these enormous chains, your you've, not gonna, reorganize the economy. Basically, you know give that advice, reorganize the economy and make everybody knows a tional flat, not gonna happen, but you know things like not sending. Certs is a good idea.

E

B

So, third thing that it's mentioning the draft is to compress the certificates. This is a working group draft in the TLS working group and I. Think it's compressed quite well, but it's only possible for TLS one of three.

B

But this this draft is describing certificate in all versions. Yes,.

B

So this is another drop. Now it's not that yeah.

B

That was what the working group wanted. It's a problem mean it's not likely that all will immediately change to TLS 103.

B

So the fourth solution, alternatives as Thomas mention, is the cache of the server certificate, or rather the service that if you get Shane, it's the whole certificate message that cached.

B

So if you have a full successful, TLS handshake, the client can cache the server, so they get chained and then the next time you connect to that server. You include this extension and you have a fingerprint of the certificate Shane.

C

Well, isn't would isn't this result in sort of a chicken-and-egg problem if your first handshake itself doesn't succeed because of the problem.

E

Yeah go to harnesses point. You have an opportunity here because of the benefits of one three to actually fix a lot of things going back and telling people to change code, which is polite and billions of endpoints I. Don't think! Is that likely to succeed and probably may not? It's I mean I I, don't think necessarily can do harm, but I would more focus on your opportunity here.

E

To tell you know, it is weird that this is a separate draft, because in some ways you have this opportunity with 1/3 to improve a lot of things and I. Don't know if you're gonna reference this draft from the 1/3 stuff and say that you should implement this as well, but it is, it is a.

E

It would be a really good idea to clean this up at the same time, because it's you know the point of if the point of 1 3 is to actually significantly shorten a handshake and you've got these huge chains which generate 40 to 50. You know message, exchanges, it's kind of pointless right might as well do both.

H

So I mean: can you? Can you scroll back I, think to the yeah good thanks? um So I think um is I understand this charter item. It was primarily about guidance which I think is like val, very valuable. um You know what so I mean I. Guess it seems to me: is there there are? You know three settings right there.

H

People will already have you deployed and presumably they've bang that whatever their certificates into a foot shape that, like you know, will fit their people who would like to deploy them to play me further, but aren't like gonna change code and for those people. The guidance in these first two guys in bullet points are valuable guidance right, um namely you know you you see, or you know, and typically you do get to control the trust. So often you just basically, if it like you know, provides the stiff against that.

H

You want handed outs like is pretty straightforward to shorten their list. um Mike the this next bullet point and then, of course, are also on three and then the next slide. Cached info are good techniques, but they require changing code and those people, I think might as well just like poised over to one three right, I mean if these guys have to obviously so I think I think what I would try to focus on. If, for me, um would be the techniques which require which require code changes.

H

um You know somehow our intern messed with the one three stuff, and they say these, which are just like here- are some good practices. You've already used those like same totally in scope and really useful, so that maybe I'm not sure how to start the document, but I useful way to think about it.

B

And the last thing here that, if you use this, as pointed out already, you need to wait for a full handshake, em, otherwise, and so this is the chicken and egg problem it doesn't help.

B

It state the zoo in the drawers right now, but it stated that it could lead to man-in-the-middle problems. I cannot see that directly. Would it be a possibility to use this even from a failed handshake when the authenticator cut it down so I.

G

Think like it's not that, so they at least from what, how I understood the situation with these longer certificate chains and the success rate- is that yes, sometimes it doesn't work, sometimes the exchange doesn't complete and there may be retransmissions and all sorts of hassle, but we are not talking about like never works, it's just crappy experience, but once you've got three legs chained because otherwise you cannot use the whole thing to begin with. So once you get through the exchange, you cash them in. Presumably it specifically.

G

So this is not the web environment where you randomly talk to some server on the internet, but instead, once you manage to get that exchange, which is most likely when you are in your enterprise environment, where the hops are short, where you don't have to deal with all sorts of annoyances. But then, when you go off and travel somewhere where you can suddenly have to roam around then there's a complicated, multi-hop, algebra infrastructure, then that's where things break and then that's the time when you actually should have the stuff cashed already.

C

All right, I, think, okay, I, think that's probably a fair point and I think one of the from the experiments or tests that we were done. The last rain drop I think the it was also the fact that a lot of this happens also based on the size of the eat package right. So sometimes you actually have shorter size, D packets, and that's why this is more likely to happen so, but maybe we can probably give that guidance if you want to give this guidance as Hannes right.

C

You can probably include that also and in in the in the guidance.

I

So wit, as lerczak mentioned at the last hackathon, we were running some some tests and this this Chara item was brought in by others in the group, so MOOC many access partner, actually I, have tested with two and one was enterprise access point they as a denial-of-service protection drop if the obsession doesn't complete within forty round trips.

I

So if it doesn't complete between forty round trips, that you will never get a leap success and then, even if you have this the right certs on both the ends, you wouldn't you would never be able to use this cash information exchange. So that's where we experienced from from the hackathon. We don't have deployment experience. This is what Alan and and some others on the list protein on.

G

This is honest, again, I think then the recommendation should be of in addition to the stuff that you said earlier is there may be also a need to change your access points to reconfigure your access points, because you are essentially you made deployment considerations like deep certificate hierarchy, RSA keys with a key size that would resist both quantum crypto issues and then you expect it to work smoothly in your environment. So there's just you cannot have all the things that you want. It's not Christmas right.

B

Would the best security problem to cash certificate changed from non successful, handshake.

B

Personal quick analysis should that it be would be okay, but it definitely need more analysis, and what doing that would go again? Is that you get chain Kashuk.

H

Yeah exactly um so I'm assuming that in this environment I'm this is like white because it cuz this is EEP I, don't have any other network connectivity than this like in this thing. Right now, it's like we can't just like you can say out port them this web server somewhere. That's what I figured okay I, don't know. I'm like pretty I mean, maybe you could do it's like I mean III III I.

H

Take your point that, like it's like no obvious reason why this wouldn't be okay, but like it's like not how we roll and like someone would really need to put some analysis about why I was okay.

B

Depends on if somebody some implementer wants to do this this then we could analyze it otherwise, not, and that's all like feedback on this draft. If you have any recommendation, anybody has any experiences about what was mentioned was that we should should write a little bit about how organization and structure affects it. But it's not like anybody is going to change the organizational structure to solve this problem.

M

Hi Sean Turner um PGI provides many foot guns. We can maybe provide some examples for ways not to shoot yourself like in the draft. You have like long names like don't put 150. Subject: alternative names in your shirts.

M

You know all kinds of things like that pick shorter oil IDs if you can get away with it, don't put your CPS URI and there are a bunch of text files and crap that a lot of people do just don't do that so for each context, if you can get away with avoiding all those yeah the cat pictures, maybe maybe your logo can be omitted from this particular certificate. Thank you.

M

I can I can volunteer to help you in a little bit of sense, so that'd.

H

M

um Thank you just so that we can do things better thanks.

A

A

Okay, re you're up.

L

Okay good morning so talking about two drafts today. First one is the EAP, a k-prime, 5448 update and so for background. If people have forgotten so ei bak was defined some years ago on the 2000 something, and we also later revised it slightly. The revision had to do with ability to bind authentication context to the actual application process, and these RFC's have been fairly widely implemented, probably in the in the billions and somewhat widely used, not not nothing.

L

The billions, maybe more in the millions or tens of millions rains and the context for for this work previously was that you could use SIM card infrastructure while you're doing wireless LAN access and and when you're doing the mobile network access. Then you wouldn't use EAP directly, but 5g changes this, because they allow both the old native approached authentication as well as EAP and and different methods, with the EAP, a K Prime being the default method in fudgey.

L

Okay and of course, when it's an old old spec, maybe some Croft has accumulated over the years and also in a new context. Maybe there's some some things that we actually have to specify. So so, there's some some number of bugs some missed items that should have been in the original RFC's. Maybe some additions in the security consideration, section things that we learned and then we need to specify the behavior for 5g and for 5g. The that's basically two two issues here. One is that you had this.

L

You know previously had this network name binding and- and there was a table in a three cpp specification that specify like you know these are some. You know. The structure of different network names begins with the string called followed by colon and then possibly some other parameters, and that table has been updated and so now we're pointing to the new table.

L

So that's relatively easy, but still important, because otherwise the authentication doesn't work. The other important piece is that there's some some changes to how 5g deals with identify there actually affects here. I'll talk about that in a sec. We also include the definition of exported parameters in come in a complete fashion. We missed in the original RFC's and that we were writing the original artists. There was some other RC 52-47 that was progressing in parallel on that got missed and we update the references, so the identifier thing so previously.

L

This was clear for all cases that that existed, use, essentially than the the identifier that was was sent like no matter wait was sent where that was send an EAP I, didn't the request response pair or somewhere else later to use that identity, identity and, and they it's it's important that both sides actually agree on. What I did it is used because I did these directly use this input in the KDF?

L

So if you get it wrong, Keystone maths, patent and and v v, 5g, there's a couple of things that that change, or primarily one thing. But the context is that, typically, you would run EAP inside the the authentication process or the network attachment process in 5g and it doesn't use the identity request and response that they added is communicated in layer two and and secondly, in 5g. There's two distinct identifiers for subscribers.

L

There's one the permanent one subscriber permanent identifier or supey- and this is I'm saying here- it's never sent over the wire. There's some exceptions where it actually appears to be sent like an emergency call and no no authentication available. Something like that, but but in any normal circumstances, that is never sent to hide that permanent identity identity for whoever might be listening and then there's a temporary privacy friendly identifier, subscriber concealed identifier and and the 5c network that attachment process.

L

It's complicated protocol exchange where some of this information is is conveyed, and the question now is: if we do EAP right after which of the ident possible identifies we should be referring to, and while one might actually have different opinions about this, what what this? What the answer should be?

L

What I'm trying to do with this draft is that the 3gpp is progressing their specifications and- and they have said some things- made some decisions and I'm trying to align the RFC updates to to those decisions and their decision in the SI 3 group, which is the security architecture group. There was to use the permanent identifier as us a basis for four key generation.

L

So this is what what the draft says so and we can detect when we were doing the 5g thing, because again, the net out indication context is communicated, so we're gonna say tell the other party that now we're doing 5g and and that that's has a particular string associated with that um in the network name field. So so we can do the switch. It's not the cleanest way to do things personal opinion, but trying to align people on the same same approach as opposed to you mentee. Something else.

L

Persons you've seen two versions fly by the person: zero zero is simply the same as the previous one, but doesn't working document and then zero one which had bunch of updates. We realized that we need to update the relationship to our see if 4187 as well. We clarified language or the exact word that we used to say about what we doing with 54:48.

L

We update the references, as mentioned. We specified the network name and the identifier construction, which is the technical content of this. This thing next steps and what remains so at the moment. I think this is in sync with what 3gpp is doing. They haven't actually replaced their their text with a pointer to this draft and you need the working group version of the draft is fairly recent, but I think they could do that and I have already Requested that to happen.

L

There may be some things that we still need to work on I heard from John some comments around the security consideration section. Maybe you want to come to the mic and explain.

B

Yeah John Watson, Ericsson I have I reviewed it's quite thoroughly and I think it's quite obviously. Quite it should be not be any changes to the old technical section. So I think this is very much ready. I will do a second review and try to review the alignment with the 3d PP specification that I am not done, can promise to do that in coming months.

B

What struck me when I was reading the security conservation is that the demands on security considerations concerning privacy and privacy monitoring has it's much higher now and then, when 5448 was written, so I would suggest that this security consideration is that text on privacy and pervasive monitoring is added to security consideration, for example, for privacy. What happens if the encrypted Sookie is not used?

B

The hope from that industry is that it will basically used everywhere, but it's up to the operator to deploy the public keys on the same culture. I think the draft should go through their threats with MC capture sazon. If the encryption Sookie is not used and also I, think it should discuss there. What happens within when the long term keys on the SIM card is, somebody gets holds on on them and use them for, for example, for passive, pervasive monitoring.

B

It can also be used for attacks on different on specific users, and this is something that has allegedly been happening in reality in quite large scale.

L

Yeah, thank you for the for the review in the comments. I certainly agree that those those are things that need to be added to the security considerations piece and and in the sooky sooky thing is. He said it is a new technology development that affects this so clearly needs discussion and, and of course, in the meantime, we've learned about this massive key leak. It's attacks going on so that that definitely needs to be explained anything else either in security considerations or otherwise it.

L

This would be a really good moment to add stuff that we've not realized so far.

L

So, while nobody's coming to the mic yet I also say that this is sort of designed to be part of the first release of 5g so and I've taken a sort of a rather relaxed approach to exactly what, where the reference is go with such or when they reference this. But but 3gpp traditionally has had an ability to replace their temporary thing in atius with a reference to RFC when that obviously comes out. But I do think that this should go forward as soon as possible.

L

And so I would actually suggest that we're close to working your blast call, and we should initiate that after the security considerations, update and and then.

M

Get it done so shunter to that particular point about timing like fast is like six months a year for because usually like it takes three years to get anything done in the ITF, so you're hoping I, don't agree.

L

M

Don't have as much pixie dust as you've had in the past. Oh yeah I mean that the.

L

Question is I mean probably that's a long time to do completely new things right, and so this is abyss and yeah.

M

And yeah I don't know, but it we should definitely try. I want to help. So does anything I can do. Let me know we'll review.

L

It now and and then you know, we'll update it today.

A

L

Tomorrow, still, ok.

A

I, don't see any reason why we couldn't if, if when we get an updated security, consideration section- and you know- and if there are any other remaining comments when we get those addressed, we can last call it so I I mean and I guess. My question is: what's the timeline is what I guess there's a little bit of risk potential risk? If, if 3gpp decides okay we're gonna make changes, then we have to go back and change this.

A

How how stable.

L

Are they or I think they are ahead of us and then we're trying trying to match what what they have so I think the risk of that is is less than the risk of them feeling that their thing is to to ready to be even even made make a reference to new orbs, but.

H

L

You know even that wouldn't be the end of the world, because we can always make that in the next release, but but I mean I would really like this to get to the like this one. One reference for this yeah and one thing that I forgot to say, is that we are running a project to to implement some of this. And then there was some discussion on the list and, and it seems like we were not the only one.

L

So we don't have something yet that where we can actually test with others, but we will soon so yeah. If.

A

You forward to that, if we can both for the ETLs and for the ebay ka prime, if we can, you know kind of identify implementations that would be good.

L

Yeah I think that's it. Then we know what to do so. Thank you and what's our next awesome? Yes, okay, so so this is more of a new thing. This is not for the current release of 5g. Also- and this is more of a I'd say my personal problem- some organizations attacked infrastructure that hold keys for my protocol and, as a result, my protocol is broken, obviously, because the key, if the keys are broken they the protocol is, is suffering and I want to do something about that.

L

Like a me, an email from a sort of personal perspective- and the background for this, of course, is the like. Maybe everybody already know knows this, but but the there's been reported attacks on like the manufacturers of SIM card, so you get like that all the secrets of everybody's cards and which is really bad. However, if it's perfect forward, secrecy would help defend against it's, not a and all concerns so loose on the body.

L

It does does make this less of an issue because against passive attackers, your actual own communications in on your phone will still be secure and you forcing active attacks if they actually want to use the the acquired secret information that they stole. So can we do something so I won't go into the details of the protocol. You can probably have already read, read the draft, but it's essentially a backwards compatible. Extension, that's diffie-hellman exchange to atak in in a particular way.

L

So so there's uh indeed you can like you we're not adding any round trips, and if the other site doesn't recognize this, then then you can. Actually, you know just keep going and do the useful thing and.

L

And the resulting keys from when you have this feature enabled on both sides and then the resulting keys will will provide PFS and the main exchange is that it's just embedded as part of the at the aka Prime- and you just add some attributes, one attribute for signaling- that you want to do at particular new way of key generation, and then you carry the the public keys for both sides and and then you keep going on internal right.

L

The keys there's couple more details, so that was not shown in this this previous picture in the draft. It explains like how how it's possible to do this without touching the SIM card, so it will be the phone at the SIM card, that's running the diffie-hellman feeds and also on the other side, it's the API indication server, not HSS or the one that stores that the keys which helps add this feature, because you don't have to change everybody's SIM cards and so on.

L

This is good and, of course, if you do this on on EAP level, so anything that this based off EAP keys will will benefit from from the higher quality key material produced by keys. That also include the diffie-hellman parameters, so you could potentially imagine using this, for whatever is on the access link security and, if there's anything that you need to discuss with the whole network in some fashion based on the key is provided by this, then you can you. Can you can do that a little bit of motivation still so.

L

The first motivation, of course, is that since I feel that my protocol has some issues I'd like to fix it, we also have RC 7258. Obviously that um seem to be demanding that we look at pervasive monitoring attacks, and this is certainly one of them and take them into account one way or the other motor encrypted traffic protocols generally try to do DFS.

L

So this seems like bringing the protocol to that level, and also there is no technical work yet on this, but in in 3gpp, in their next release and phase 2 of 5g they will. They have agreed that they will look at providing perfect forward secrecy in some fashion, and this would be obviously one way of doing it.

L

They might be others and I think that that timeline for that is 2019, and the question is that if we were to provide a specification now or at least make it go forward enough that it can can be used by others, then that might actually have an impact.

L

We have an ongoing implementation effort of this, as well as the previous presentation.

L

G

Eager to get this in the working honest, yeah I was I was when you show they exchange and you added the diffie-hellman exchange. So typically.

G

Whenever there was public key operations, there was always the concern that there would be some denial of service attack. You can basically flood the server with requests and make him do a lot of work without the client actually conscious. Anything to this and II see that as a non-issue here, because it done like you know what I mean. Yes,.

L

And that that's it, that's a really good question and one that hasn't perhaps being discussed enough in the draft, but but I think the situation is that in this particular case, so it's kind of initiated from the network side and and you in order for this whole thing to begin to at all, you have to be a phone that connects to the network and starts the connection process involving multiple exchanges with the network, and then you get the first request for for the authentication from the network, including the diffie-hellman thing.

L

So you as you, we cannot toast the network site or the server that's point one and secondly, for somebody else to dost the ue, of course, the damage zone, one you we may be smaller than the whole network, but but also you know that they would have to I mean at that point. You don't have security on yet obviously, because you're you're still out indicating its generating keys. So you can, in theory, get to that process by somebody monitoring and doing an active attack on the radio.

L

But that means actively attack on a radio on a particular point with relatively small cell size. So it's doable but but the damage is may be constrained. But.

G

It we've seen that these EAB mess- it's also not just used for the classical network access on syndication, but also then for cases where you have PPN accessing this type of things where it's actually initiated that a client also in some of the wireless LAN deployments, it's quite possible at the last.

L

Before before you go go there, so you said that it's initiated by the client but like that this protocol always runs the the server side of EAP, initiates this this particular enhanced extension or enhanced exchange, and so do you have cases where, like the all the cases that I'm aware of where you use like VPN access or whatever, it's still like the client, initiates the fact that that I'm trying to connect to this VPN, but it's the VPN box. That tells me okay. Now, please authenticate mm-hmm, look.

G

L

Non-Applicable mmm yeah I mean I'm, not saying that there wouldn't be another case, but but that it's still still the same same ECU.

B

You're, not some Ericsson. Yes, additional comment about this with a symmetrical crypto EP eat aka in 5g all the way right now with encrypted the suki. The server will always use a symmetrical crypto to unencrypted the identity.

B

If you don't know how suki works, it's works extremely similar to the encrypted sni proposal in the TLS working group, but the client gets the public keys from the sim card instead from your DNS in the asinine case, so I think adding this would be to asymmetrical operations on the server instead of one. But it's not the order of magnitude higher.

L

Yeah and it seems like the direction actually on this earlier exchange, which is not part of EAP but part of that network attachment in 5g. It's actually reverse from what we just discussed. The problem in EAP may be a little less than that in that, but they feel like they have that under control. That's true remains to be seen, but that's what the spec says. Hi.

N

Ross, how early can you back up to the one that shows the third year so without this additional diffie-hellman?

N

Where is the fennek ation that would be available for aka Prime? And can you validate that before doing the additional diffie-hellman to eliminate the? If, if you're being spoofed, then you that part will fail so I? Don't even do the extra work to get to the PF s if you can strictly order that it would eliminate the the thing that Thomas raised.

L

That's a good point and I'm not sure I, remember exactly what we do in that respect today, but that that seems, doable and and the design is sucks, because we want to have this backwards compatibility. So we actually send everything that is needed for this regular authentication. So it would seem that that's a if it's not done, then it seems doable. I mean you.

N

Can send it all it's the order you process it and that eliminates yeah.

O

Obviously, yes, thank you and there's more question max Potter, cable labs. Is this the public key that is used for the exchange, the same as the one that encrypts the suchi or not.

L

Or is temporary one, so we have our own exchange and say nothing about what the public key I mean. It's just like this. Is our protocol and use public keys from both sides, I see where you're going, but, but we haven't said anything about that at the moment. Okay, thank you.

N

Russ how's day I assumed that you were using ephemeral, diffie-hellman here. Yes, actually I am so yeah yeah. It's.

L

A week we saw that that's right. Sorry.

B

Your Matson Erickson, as I already commented on my security consideration before I think this is a real-world problem. This is something that I'd have better and practice assess which should do, and here we have a protocol that has been in the past, been, is suspected to pervasive monitoring and allegedly have been targeted in massive pervasive monitoring. So I think this is definitely a direction which working group should go and I'm very supporting working group. Adoption of this.

B

How many folks have read the draft? Okay.

P

Not too many is.

A

There, how many folks think this would be a good problem to work on, raise your hand? Is there anybody who's against working on this?

A

Okay, so I think well, we'll do a call for adoption on the list since it's in our Charter and it seems like a reasonable way forward. Probably there'll be some discussion of the details.

L

Yeah yeah, clearly and and I'll work on that. Thank you.

A

So now I think Owens gonna give us a little bit of an update on what they've been looking at with respect to brewski.

Q

Hey guys on frill, and so what we're looking at is how to run brewski animal risky, bootstrapping, mochi infrastructure inside Nick tunnel. There is a related raft that we covered in the Animas section on Wednesday, which is running brewski or a Wi-Fi networks, and it describes a larger problem. Space and one of the solutions to some of the problems is to run risk inside a t-tom, and so what are the problems were trying to solve and so on? These problems are generally two wired networks as well.

Q

What are the problems are trying to solve a quater work support Brisky? How do we avoid advice, onboarding against the wrong Wi-Fi network, our credentials device used before and after it's completed risky flow for authentication against the network and and some of the problems that are probably more specifically T brewski is how long does it take and what signaling is required for the device to determine to the network's entrusted?

Q

How complicated is a device state machine when it's switching between candidate networks and how complicated is device state machine when it's on working against a correct target network?

Q

So the the attitude, the whiskey / attitude at 11, outlined some possible solutions, doesn't make any final recommendations for this draft, the the brewski / tip and it describes some possible solutions to so many problems, so just a refresher for those who aren't familiar with AdMob risky and when you first time power up a device when your first time pair pledge it trusts nothing. Apart from maybe a manufacturer embedded root anchor, you deployed the brace on the device in your local network. It's going to discover some kind of registrar.

Q

It doesn't trust a registrar you can think of the registrar as akin to a smart middle box. So what the registrar does is proxy voucher requests between the pH and the trust manufacturer server, the manufacturer server will return, will return a signed, JSON blob, instructing his advice to trust the registrar. The device now trusts registrar and can continue to bootstrap.

Q

So this is what we could do for device bootstrap with the existing mechanisms we have today so device boots up. It sees multiple Isis IDs, it does an ad 2.11 connect. The network is enforcing a rated one x. Dozen authentication use it using its idea of ID does DTP gets an IP does dns discovery connects to registrar and issues about you request. The value request goes all the way up to a Massa. The mass will respond, saying: don't trust this network.

Q

Typically, what happens with most devices, certainly I needed, like some familiar with after it device's IP diff. It needs to reaiiy pee and connect the different network and needs to reboot. So in step, 4 of the device reboots to repeat that process, I, don't at the next candidate network. This time the master will return a signed voucher to the device in yes trustus network, but the devices are already IP devices done dns. The Bob will typically happened because the device now had been credentials with a different identity search.

Q

It started off at a side of ID. It now is an L divided e. It's been recruit and shield. It needs access to a different network segment. It's probably gonna have to reboot to get a new IP to butter on the correct network segment of the target network. So that's happens that beta device reboots. It does attitude 11 again to zero to the 1x using its L, divided e. It now can connect to the crack character, network and, finally, access services. That's a really really complicated state machine.

Q

This is what we'd like to do: we'd like to run that brewski voucher, request file to respond trust out even flow inside in the eat tunnel.

Q

But what that means is that when the device finishes its edited, the 1x authentication, the device knows whether or not it should connect to that Network or not. If the master instructs device not to connect the network, the device will fail, authentication prior to I paying it will fail. Authentication are there two that makes the state machine on the device fire simpler, that hasn't gotten IP address at this stage it can now go on to the next target network and redo, irritate 1x authentication this time on the masa instructs the device to trust the network.

Q

It can continue to IP dns service discovery and access services. So if you compared the Moschino welcome to do today versus this step machine, if we can do brewski establishment that layer to you inside me, it's far far similar from its vice perspective, so this is just a little bit more detail and I'm Rob risky. We distracted a couple of slides ago, but there's five key steps. The device establishes a provisional TNS connection that registrar. It doesn't trust us the device exchanges factors via the register area with the masa.

Q

The device then verifies UTSA connection with registrar it downloads, trust anchors and an optional scatter Elda by key and eat tip, is really really good fit for this. If you look at these five steps, teep supports server. An authenticated provisioning teep supports definition of new TLDs for transporting application, specific payloads such as battery requestfactory responses, each supports a final verification of the TLS connection. After phase two completes, and tea has already teed the TLD definitions for downloading trusted. Root, anchors and tip already has Tod definitions defined for doing certain elements.

Q

So all of the problems we want to solve for brewski, T, plus solutions for all of them. This is the et risky architecture. This is what it would look like. Your device connects the Authenticator which connects NTP server, the cheap server to connects to a brewski register on its back-end, and the booster extra return will talk to a mass or a CA. The team server and the risk register could be co-located the risk register and to see it could be co-located.

Q

That's a that's deployment, specific and architecture specific, and this is the high level and ETA risky flow like this flow is taken from the from the draft is multiple other flows in the draft as well. Does a few new T TVs defined one factor, requestfactory response factor status, Norman's data, CSR attributes and the risky T of these must be exchanged part to crypt the binding, we're suggesting that we do brewski as new TVs, not as a neat method.

Q

So what that means is there's no need for channel binding, just not on there's not an inner teeth method, and this is the summary running. Riskiest part of edits and 1x really simplifies it device a more except machine. Beep is really good fit for us key to finding new TTL. These seemed like a better fit than defining a new eat method and we're looking for interest feedback, and we would like to get this adoption, and that is last light.

J

Question from Jabbar Allen decock so who implements team IRC, it's almost no one. That does make this more difficult and the other question is: if the masa doesn't trust Network one, why is it doing and eaten or 2.1 x exchange with it? Perhaps this is more. Not the right network then not trusted, though I'm not familiar with Brisky. Well,.

Q

Even even in a wired use case well, I'll take the second question. First and first, question I'll: defer to Nancy who's in the room. Nancy wrote cheaper Nancy's in the correct business unit to ask when Cisco's won't be building keep support.

Q

Q

So the second question first is and even on a wired network, the pledge doesn't know whether to complete at least one X or not. So it's gonna, it's gonna. Do the client kiddo it's gonna get back a server certificate. It doesn't know whether to trust it or not. So it has to do the massive log first to decide whether it needs to trust the arrow to do one X server, it's going to get a server certificate back.

Q

It doesn't know whether to trust it and that's the same problem regardless, whether you know wired or Wi-Fi yeah.

R

I mean more more directly if I can elaborate on that, the masa wouldn't be in the dot 1x path anyway, because it's way deeper in the infrastructure, so the dot 1x is really to establish the communication on the edge. So that answers the second question as to the first one, it is correct, tip right now is not used. Predominantly.

R

The issue is and I know, from the industry side that eat fast is predominantly used, but it's not standard. So we could have chosen to do all of these extensions and eat fast, but we'd rather go towards a standard track piece of work. And so, if you look at the difference between you fast and teeth, they pretty much are the same state machine. Some of the crypto and the prfs have changed.

R

So our preference is to go towards a standard route so that we you get traction.

S

Okay, see where does Kenny go to slide number six.

Q

Which is not this one? No.

S

Go back, go back, go back early on, go back yeah this one, so I was how it is different. Today, if you have a triple-a infrastructure, it will also do the same way right with the say, for example, of the radius it'll tell if this is today. This.

Q

Is what you do today? You have to completely do next. First, get your IP address, then do application or discovery for registrar then do the brewski flow no.

S

Not risky I'm, just talking about just simply Triple A today say radius, so it is done exactly this way that if it is not correct Network, then it will fail today with radius right. So with the backend Triple A with the radius infrastructure, it is done exactly the same way, but what.

Q

This is with the brewski flow. The device is relying but well first to making you something that the network is well behaved in. The network will reject device, it doesn't own and I bought the Brisky flow ads is the mass is going to vouch for the network you're trying to connect to so the device fails.

S

Q

I understand that point.

S

What I'm saying is that the if triple infrastructure is there? This is not adding anything else. Of course, I understand the Brisky has a different purpose and different. You know thing right, but the problem in the previous slide, what you mentioned, and this second slide, which motivates it is my understanding. It is solved today with the triple a back and radius exactly. It will do the same thing, because I will not get IP address with 1x with if oil it will happen and then, if it fells I'll not get IP address, I'll move on so.

Q

Again, your mail again you're, making the assumption that the network is well-behaved and scones no.

S

Q

Assuming that I, you.

S

Say that IP address I, go to a network I go to the Triple A exchange it fells I, move on I'll not get IP address, I not get, it will go to 1x. Unauthenticated port evil fell I'll, move on to another one, so I'm, not wasting anything I understand the purpose of risky and masa is different right and you are trying to bring it here. But exactly this procedure happened today, which I play what.

Q

What the triple-a, but again, the network, the triple-a can accept the device to the network, so the triple-a can accept the device to network and editing. One, X authentication can succeed and then the vow the device will connect you to the Registrar and then connect you to the mass and the mass of reality. Do next authentication has succeeded the Masur network.

G

I think the main issue at this is Hannes I. Think the big issue here is that, under the the kaabah Brisky came up with a new network network attachment procedure, network access, ossification means, because that's I think that's the the thing that you realize and it's also a little bit hidden in the first slide that you mentioned when it says the device doesn't doesn't have anything except that's also what is in a document a Brisky document.

G

It makes this sort of weird wishy-washy claims about what it tries to solve and what it doesn't do and the reason why I am very much understand your question, because I actually ran into that myself. Why can't you just use and then regular, triple a procedures here is because it's trying to change the way how the Triple A works in a back-end by basically not running into the manufacturer, because the claim is that you don't actually need to talk to the manufacturer for privacy reasons it's claimed.

G

But then you need to set up this alternative infrastructure with the Massa, because now you have the problem that the device cannot authenticate to the local network because it doesn't have to trust anchors. And now you need to push these sort of things around and I think that in the IDF so far, because very few people pay attention to anima. We have actually bought into that cept that this is a good idea. What you are trying to set up this alternative approach of I'm, doing, network access, authentication, I. Think that's my problem.

G

When I read the the specification of the the press, Q specification.

Q

So so what you're really saying is you want your device? Do trust and first use I'll trust any of the first Network connect you I'll just trust. It did.

G

You know I know it's known to islets.

Q

The triplet, let's mean I, don't need any pre provision to know anchors what.

G

Is what I've, but I would really like to have as an honest conversation about what we are trying to accomplish with this alternative network access on syndication infrastructure, because when I read, press key I, see problems being stated and then later in the document, I see the same problems being resolved using things that were actually solutions on what you complained about the problems. You complained that it's difficult to manufacture do put manufacture certificates on a device. Later you make use of them.

G

You claim about the privacy implications of running the exchange to the manufacturer to replace server later you actually for security reasons you still have to interact with the manufacturer, and so like. The whole thing is, is just marketing nonsense.

S

So what the one thing I just do with the second I just add that say, for example, I deploy, tipple infrastructure right and then do I need this right. That is one thing right, because my current understanding that, if I, have a typical infrastructure, the motivation, what you say that it is actually doing the same thing, so it will be good to have maybe a section right. Okay, if I have it will infrastructure right what additional benefit. This will add to the you know the system that will be actually good thing too.

S

Q

What you are asking for us was to benefit the risk in the first place, not not what's the benefit of doing brisk inside inside each no.

S

In this particular environment, because the in this particular example what you said that oh I, don't trust that I don't know what the network is right and I just try to connect, and this gives the benefit that okay I know they. This is a trusted network, so point I'm making is that with the backend ripple infrastructure exactly that is what happens today. I know I don't yeah, I try to connect.

S

I fell a potent occasion and then I move on because I'm not given any IP address or anything or any resource to the network and the one I succeed. I connect right.

T

Brian, why is it I'm just trying to clarify the brewski is actually in this step, allowing you to Seneca get to the point where you could have fun: okay, the network. Instead of moving on you could move on all day all the networks you want to. Nobody authenticate you with the normal back-end today. If they have a provision you with any credentials, this is trying to get you the point of provision you credentials, because it's up with that initial trust. Okay,.

S

So Brian, then maybe I, misunderstood, say, for example, if network B is not trusted, the masa says that okay, you don't trust this network that will fail right. So.

T

So so that is kind of a little weirdness here in the slide. Okay, normally the its it is gonna always be. The enterprises decision, whether to trust the network NASA is helping it determine. There are cases, though, where then a price might help might might use the masa for a little more information about whether they should trust this, but normally the masa is used to give you information about the device and the enterprise are gonna, decide whether it wants to trust this device or not. I.

S

Just need to read a little bit more because.

T

The motivation.

S

Here is basically I didn't understand. You know the motivation that this network is not trusted and it's helping me to test this network. But if the network B a is not trusted, even the master cannot help.

R

Ryan Mike sorry.

K

R

Short, okay, very CLE talent, so the other part in brewski is and part of the voucher request is to help the end point. No, and that's why I say it's beyond tested that that network infrastructure is be trusted, that's what the voucher request is for and that's the brewski aspect right, and so you talk about the triple-eight infrastructure.

R

The difference here is is that Triple A infrastructure doesn't have the right identity, which is what Bruce key is trying to help it's trying to help provision the right identity, so that eventually, not only can the end point trust that network, but that it also has that credential, okay, one.

S

Last point I'll then sit Nancy. You know that there are likes, for example, there are other ways to know that right, for example, the network discovery at 11:00. You write so that it's other point to know that if the network is tested or not.

R

That's the chicken and egg problem that we were. We are attempting to solve, with brewski, right and so 11. You is the other aspect of how we do the signaling, and so that's the thing that Owen presented at anima. We could. There are different ways in which we could we could use DPP. We could use 11 you, we could use extensions in the Association request in 911. That's the separate piece. This is the piece of you know.

R

Do we want to have multiple conversations right, because today brewski is at a higher layer or we could actually embed it, especially on the Wi-Fi and just have all of that signaling happen, while you're still in that dot, 1x channel? That's what we're proposing sorry, Owen hi.

O

Max para, cable ads, so I think that this composition was very useful in sense that it clarifies that this is a provisioning mechanism, is not the authentication. I mean that comes that comes as a good benefit afterwards, but it's a provisioning mechanism and totally support that tip already supports EST and one of the things, and maybe is something that you know as a group, we might consider to maybe have a generic method for provisioning through EEP, which can plug in different methods.

O

Brusquely could be one yes, it could be another, and maybe there might be some easier, even easier provisioning ways that could be plugged in into a generic method. This is something that might be a different discussion. One of the consideration I wanted to bring out about what you said. Implementing with TLV is instead of its own method.

O

It seems like it's an easier approach right to do tlvs, because you take what exists already and justify new TLDs. However, this brings up. The problem of tip is not really implemented today, and you could potentially do an another method and combine that with any existing tunneling methods so that you know the security properties could be provided. You know through other already deployed methods, and you can use an inner method. Maybe this could help the deployment and I'm not sure about that.

O

But you know especially because that you don't have to implement the whole heap, but only the provisioning part, and that could be easier in existing implementations. Yeah.

Q

We had considered a new ich method and we have. We had assess the pros and cons of a new each method and we decided that theory is probably simpler. Working on the assumption that we're going to ship T pretty quickly right.

R

So so, if I can elaborate on that and we were mentioning well while we were on the queue so so, as Owen said we debated, it could absolutely be its own EAP method. But again it's that chicken and egg problem. So by establishing that TLS tunnel we've now taken care of effectively. Now you know with previous conversations of whether we support perfect anyway, establishing a secure tunnel, so I think the issue and why we went this route, and you can blame me because it makes the security considerations and potentially the privacy considerations.

R

If it were to be a standalone method, would be more complex. There would be a lot of requirements of how that EAP method would have to run I.

O

Totally and this max pala CableLabs thought I understand your point. I'm just trying to say maybe there's an opportunity here to have a more generic approach to provisioning than just extending tlvs in one existing method that that's what I'm saying sure.

R

Sorry I'm just helping you and since I'm one of the authors right so uh that's certainly fine and I would say. If that's the way the group would prefer for us to go, we can update the draft to go that route right. We just again. We took the path because the security is improved when you're running it under protected tunnel.

R

J

There quite a few questions from jabber. First one is from Henry Hart's, 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 or should trust. How does it work as in how does it properly fail if network a is evil? So this is the first question from Marriott's another one is from Alan decock. If 802 dot 1x succeeds, then the network is trusted.

J

If the masa later rejects the network, it means that the network is known and trusted, but not the right network. If network 1 is not trusted, why does a 22.1 X succeed? Why would device trust broski data sent over and untrusted it 22.1 X configuration?

J

Then we have another question from Henry, Hertz, suppose network e and mais masa that network it connects the device to are both are evil. Suppose network e and the master that network a connects. The device to are both evil.

I

Q

R

Many read the first question again.

J

Maybe not possible to improve this is from Henry Hertz, 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 or should trust. How does it work that is it properly fails if Network a is evil.

Q

So how does fill in this flow of not rookie is evil, so it it ok, it completes a treaty to an X and for whatever reason, mas'r hasn't issued the vouchers. So masa hasn't done. An audit log.

Q

It'll be device ID logic, so when it gets to voucher from the masa it'll then have to go back and say: ok, well, I, guess: I'll return everything 1 X connection to this teep server I had to trust and first use for the teacher ever because I had no credential information or see information to trust the team server. It then completes to Brisky flows. Risky flow isn't gonna voucher that Network and we see so risky, is not an audit log.

Q

The fact that the network has that's the device is successfully connected network, so it's going to be application or logic on the device to reject that Network black. This dish Mohan then go on to the next one go on to the next candidate network. So, even though attitude 1x authentication failed after it is to do an extent, occation succeeded, brueski hasn't badgered. The network briskly hasn't thought audit logged a success for that networks. The device is going to have to fail. Reboot try connects candidate network.

Q

I

Head no, how so what what I think he's asking and I have this same question is: why did they do to 1x authentication succeed in the first place? Why so, why do you get DHCP? You you shouldn't get DHCP on delay. 2 to 1. Xor is successful. That's how we do 2 1 X works unless you are authenticated, unless you trust and not work, why, in the first place, did it even try to connect with this SSID that it doesn't know so you haven't solved the problem of connecting to the right SSID.

I

You just assume that oh, this could be this SSID I want to connect to which is fine, which is fine, but but now you connect I succeed. That's.

Q

Exactly the problem we're trying to solve the one point: if you want, he wants a device. You unbox you power up the first time at those a traitor when youõre queue or whatever, and it sees 20 count, addresses IDs and it does not know which one to trust right. So so it tries surprise.

I

Q

Which is fine but then.

I

Why, in this this, it succeeds with a row to one X using I device.

A

I I think we we want to try to get through through some through the mic line here, because we we have some. This is not something that's in our current charger, so could.

I

You also go to the slide with the flying boxes that you had like five or six boxes in in line yeah this one. So how do I know, which manufacturer to send it to right? I have.

Q

You know friggin right, MIG I'll, be inside in the information in the.

I

Q

I

Telling you right.

Q

I

Now I mean 802. One x anyways requires, like all your authenticators access points, know which server to talk to, which is I not specific to any Eve method. This is how a to do one X work, but now my deep server should also know which Bruce QR is short to talk to and I guess. There is different different Bruschi registrar's for different manufacturers, so I have to set up security associations with different manufacturers. Will.

Q

Do these the Registrar will be on Prem generally, the Registrar will be part of your infrastructure and the masses in the crowd and.

I

The ID ID, the ID body, will.

Q

Tell you where to go.

I

But someone has to set up the security associations with different manufacturers. So that's and that's an additional configuration step that I have to do in addition to setting up the access points, the server and then there's over two different master servers and that's yep.

M

I'm having a lot of flashbacks from when I was in the area director long ago about eat fast and deep and then whatever the other one was called um TT Ella I mean t. P-- is a protocol that is standardized by the IETF and went through the working group process. It was bloody as hell, but we did it um at the end of the day. It does sound, like the proponents are trying to do the right thing by you anything standardized there.

M

The other thing brewski is a working group item for another working group and they're asking for like how could this maybe be done? I think that's a lot different than phrasing of like Cisco wants to do this, there's more than just Cisco people in that room, so I think we should consider that you can, maybe you know, say whether it's used or not, but at least it's it's being developed in the IETF. So it's not an out of the blue, so I think we should probably consider that as well.

G

Shawn I think that the the tricky issue is that and that's something I have complained about in in the past, because there were various different provisioning protocols being worked on in the IDF concurrently in that was not just anime.

G

I was also Netcom from if the serie lots of fancy names like what it gives, the impression that you magically solve really hard problem, a serie touch and and no configuration everything works out of the box where in reality, we just moved problems around instead of running the trip, regular authentication, triply exchanged all the way to the to the credential II have in this case they only credential II have is the manufacturer.

G

We are now setting up that back-end infrastructure with vouchers and everything else to get this working and I think since he was done in anima, we've all sort of looked like more like research efforts with whatever the other animal dynamic network bootstrapping provisioning was nobody really paid attention to that and I think now we're getting closer to people like looking into this, including myself figuring out? What is this actually and in you, as you read through it?

G

The document you wanna, like, oh my god, all these claims at the beginning on what it does and what the problems are and then later repeating the same issues. I I, get I, feel um I feel a mislead to be honest, seriously and I'm going to write this up, because so you can be a little bit more specific about what I'm yeah.

A

And I think that that's a issue with brewski or yeah I mean I. Think those things need to be taken up there with anima or brewski or whatever I. Don't think that's a topic well so.

H

Go on so I'm wearing my ID hat. So um you tell me what you want. Oh.

Q

H

Or yes represents presentation, the.

Q

First presentation is to define how to do brewski inside of a deep tunnel. Okay,.

H

So you see you would like you would like adoption as this work in this working group. Yes, good! Okay! So um as I recall, this is, it would be out of charter so to require every charter. Is that is that correct chairs, yeah.

L

H

I guess my first question would be on the chairs. We now we've kind of money reach over my first question. The chairs would be like I, said, a bunch of presentations. You like a bunch of work going on here already, so would you be able to take on this work if you'll wanted to do it?

H

I'm just writing to scope out like this, like seems like it was like a pretty colorful tactical discussion here, but like it may just be the case that, like this is like not even like viable receptive, so I'm trying to sort of sort out like this ratio right.

A

So it's a little difficult to tell right now because we're just bringing on right. We just charters, you I just heard you're, like you know, like.

H

I'm one thing go to do.

A

This right, I mean the much of the work we have to do. I think is is fairly straightforward. When we get to aka PFS, that's probably a little bit more work, because there's more, you know, analysis that will need to be done.

A

I think my concern here is just making sure that you know we clearly don't have a common idea of what Bruschi is or.

H

A

These other things are and- and that's that's going to be difficult until we get that shirt for doing this yeah.

H

I'm just trying to move forward in a way that you know that it's awful um so um I mean it's. Why it's I'm at you! How many more gems you have here.

A

H

Just like blasting or is it okay, yeah? Well, I, guess you people can like yell each other for a while longer then bed.

L

Yeah yeah, so I've been reading the documents and flowing this discussion a little bit. They're, not sure I fully understand everything yet, but I went first if, if there's mental model that I had building my head is useful to understand this stuff or or even correct.

L

So the way that I think of this is that you have a very particular way of doing things, but what you essentially are doing is that you have trying to bootstrap a device and- and the way to do that- is that yes, entually talk to infrastructure and the infrastructure puts you in a in a sandbox of sorts.

L

Where you can you can you can do enrollment using various kinds of different mechanisms and then once you've completed that, then you can get it out of your sandbox and possibly do it like the proper thing, and that seems a fine thing on those sort of architects for a level to to do. I mean lots of people.

L

Do that sort of thing I mean many kind of networks, but of course you have still many questions like exactly what's the right level of doing this, do you need that at the method level or doing inside a tunnel? Are you just you know simply? You know letting somebody on on a network and then they can do a manual or automated.

L

You know regular internet exchange with somebody lots of choices and and and they would have some some impacts on like you know what protocols need to be changed and such and the other observation is I. Guess following up with ohana said earlier, is that, like you, I mean you, you there's an issue here of moving like if you have a problem, but you you have to solve the problem.

L

Even if you sort of move it into this sandbox stage, the the sandbox is and and your device still need to have an association of sorts indirectly or otherwise, and and that should be just recognize that that that's a necessary thing, but but it is this sandbox concept is that is that am I am I. Getting this right or getting wrong.

Q

Yeah, so the idea would be when a device for time bootstraps, but it's I have ID it's put in some kind of sandbox network segment work and continue provisioning and continue across establishments, and then one once it's been properly credentialed, then the triple-a can put her in the correct network segment. Yeah.

L

And and so in theory, if we ignore sort of efficiency or some other considerations, then you you, you might just do like you know. Regular network attachment on you know: open open net, open, open, sandbox networks, SSID and and then then you just do IP with a web exchange with somebody, and you wouldn't have to touch EAP at all, I mean that that in theory seems equivalent. So.

Q

But, like you briskly covers exactly the kind of flow right. When you put on an open network segment, you can connect to a fallback xandred default registrar in the cloud and the Registrar in the cloud, and then we direct you to the correct place or tell you to trust the correct network.

L

Okay, thank you and.

Q

Brewski briskly fill order also supports multiple different types of flows. So when you, even if your unit in 1x to a network and the risky flow can has two modes of are multiple different modes of operation, one of them is where whisky will just automatically voucher. Whatever information right, sir, gives it and just auto log. The factor in factor this when you connect to any network and the network registrar, is going to present its information to brewski are sorry to the masa. That's will get signed up in a factory straight away in this audit log.

Q

The fact that this device is connects this network there's one mode of operation, another mode of operation which is a bit more complicated, and it's a it's out of scope or brewskie. How exactly this integration works, or why is some kind of sales channel integration if the master knows exactly where the device should go to the masa will not fire up the incorrect network so that the brewski spec is pretty flexible? How this works and it allows deploying into our predators different options at how it wants to deploy it.

O

So max pala CableLabs again I wanted to bring up a couple of points that we mean so I think that it's to me, according to me, it's clear that you know this is a provisioning thing. Yeah for mm m, dot, 1, X or in other environments can be used, could be used.

O

Potentially I have several use cases that we're actually going to work on, possibly for cellular network applications, etc that where we deployed it and I think a provisioning protocol, it could be in the scope of the working group, but, as Acker said, we might do each other in case we're each other, and we accept this type of work.

O

You know this could be initial work and I can you know, be changing to what the workgroup Direction wants months ago, but I would really like to see a reach are during that includes the acceptance of provisioning through EEP. It could be done in this way. It could be with the generic method that might support different provisioning or it could be the acceptance of maybe other proposals that support different provisioning protocol. That may and I said you know. Brisky has some assumptions that they don't respect, etc. We could address that.

O

You know by supporting others as well methods, but I think it's important work I would support the discussion on this work because I think it's something that is important for devices to be able to get on networks or having some form of provisioning. There's many different different networks, many different environments, WB, a CB RS modifier that all I have tried to solve the problem with adding, for example, OSU. So on board signing you servers, something like that and they all try to say. The onset boxing in a second network segment try to do some exchange.

O

That complicates network management. A lot and you know miss configuration of that- could cause the clients to access the resources that they should not access. So the deployment of this type of solution, the sandbox solution- is always been very difficult and not really well deployed so far, because we're very complicated, if going through it, would resolve many of the deployment issues and I would say that would help a lot of provision in secure credentials to devices so I support the work and I would like to see a recharging that includes this type of work.

O

If the group approves.

O

So we've been working in so this different 3gb piece currently is still not there. They support it, but they exclude anything else that is not aka.

O

However, in other environment multi fire CBS Alliance CBS Alliance, we just add the extended indication document approved, and that means that we can use eeep, TLS and TTLs for now to do authentication for seller net. For this it goes in the direction of addressing the problem of single sim devices that we have today. So you can have multiple subscriptions or devices that do not support SIM cards because of licenses fees. That would raise the cost of the device too much. But you see we want to use, for example, 4G LTE networks.

O

To do you know, exchange data etc. So we there's other environment where this work could really be deployed and could really help the provisioning of these devices. That is a biggest problem today to use other authentication method than other than sim because seems of the deployment problem with the hardware. However, that's very costly so trying to address that I think I think it's a good thing.

T

Primus Cisco, so I just want to reflect back on the fact that the main contribution is this draft is removing the sandbox as we've been discussing. It's it's handling at all within that a deterrent one X and C through a success or a fail.

T

If it's been provisioned or not the the slide, that Owen showed with the really complex device side workflow, it's really complicated and it really the main contribution. This is not about brewski as much as it is, bringing the provisioning and then and enrollment into the method. So that's a simple process on both sides.

P

Since how and the minis take her I think it's pretty hard for me yeah to take them all the things for this discussion, but I think it has definitely necessary for use case trouble you if we really want to push this forward within this scope or are aware or elsewhere right, because I think or have described. Maybe there are some scenarios, but please pretty tell us the use case so that I can do a job. My job easy.

Q

Sure we can make edits to the we can make edits to the draft or not some concrete use cases, as opposed just diving deeply into the technical situation. First right so.

J

Okay, there's nothing related to this draft, so Alan decock from from jammer. He says that I owe the working group a draft to a bit such an ID for faster authentication. Oh yes, thank you.

A

So, with with this particular working group item I think right now, it's it's not in our Charter and I think the chairs need to go off and we probably need to talk, is brewskis in anima. Is that the correct work? We need to talk with that that working group to see where they're at and because this is it's not the thing here and looking at this particular slide. It's not just it's an eat method, but it's more than that. This is kind of an architecture. So it's it's!

A

It's a bit beyond kind of what the original sort of Charter is in here. But if, if there's a you know if this is the way, if there's some movement or consensus in the IETF, to kind of move towards an architecture or support an architecture like this, then that could be within our scope. I'm.

O

Just max para CableLabs, this is more consideration. I, don't think it's related to an architecture here. The question for the this is, you know, changing the eat method underlines in architecture, but the architecture is not in scope for the work they work. The scope for the work is changing a neat method to add provisioning through heap and I wanted to ask chairs.

O

If this you know we can, we can actually reach other or getting a sense in the room and maybe in the main list, if they reach are during about adding this type of work, so adding a provision in creation provisioning through EEP, which seems to be solving a lot of different issues that I try to explain before in many environments could be the new reach are during, and that will automatically include this work, because this is not defining an architecture deck that you define elsewhere, they're, not changing anything right there they're trying to transfer messages to for provisioning.

O

If I, can you confirm that or is it well.

A

I can't you know so I think there is a there is an architectural change. It's not necessarily for this group to decide that change or not right, and so we need to make sure that you know I, don't want to go through and spend a lot of time and and argue a long time about what we're gonna do here and then find out. Well, you know, anima is, is not pursuing this direction, or you know that this is not something that there's consensus in the IETF to do so.

A

This way I was trying to propose.

O

You know not looking into the architecture of change, but just the messages yeah, but these things are kind of linked together. This.

G

Is honest just to elaborate and the architectural changes as far as I understand them so previously in using the CRS sandboxing terminology? Previously, the sandboxing was yet at the application layer of this co-op, etc, HTTP proxy and that was used locally, and we instead moving that Louis Laius deeper, as you can see also on this slide at the EAP layer to make it more optimal or optimized in terms of the message exchanges. So this is an optimization to was defined previously.

G

I also just check the IPR situation, so that's also maybe was why to consider this in in all the excitement. um There's several ideas filed on on the breast case stuff, so.

L

Yeah yeah, so I mean on the topic of like this working group. Working on on the bootstrapping issue through through EAP I, think that's potentially interesting, although a person who would like to complete all the other work first and not maybe not surprising but hey I, have a couple of comments around like. If we were to do that, then then, like I, think this working group like the cannot be responsible for for the architects.

L

We have to be somebody else, but but we would still have to be convinced that, like we actually need the sandbox on our layer and and and that that's a sensible architecture, I mean even if somebody else works on it, but we have to I. Think would have to believe that for for us to mate for for this to make sense for us and then max was commenting on on the like mobile networks and other other systems that could benefit from more generally from bootstrapping mechanisms in inside EAP and I.

L

Just want to highlight that there are obviously you know, lots of different solutions in this space. I mean- and you know, outsid hippie also, for instance, in mobile networks. You have this hardware, less SIM cards of various sorts and in some some deployment I understood also, so it's not a nother space where nothing has been done in the past, so that should be kept in mind. Thank you.

A

So I think we can have some discussion of this on the list, although we really need to make our other workouts a priority. So if this becomes a distraction, then then we'll have to you know, take it off, but I think the next steps I think that chairs need to kind of. We need to sync up with anima and see where they're at and then maybe talk with RIT and amongst ourselves and then come back to the list and see.

O

Where we're at sorry just one one question: what is the criteria to define if this is a distraction or not, because there might be some people that want to work on this and start that much about this other stuff and that might not be a competition. So.

A

You mean where to take the discussion, if we can't have it in emu, is that the question no.

O

No I'm just saying like what is your you just said: if this is a distraction from our work today, we have to you know, not accept this work, but what is the critic criteria? They have to say? This is a distraction, so I.

A

Mean right now this is not in our Charter, so it it's a distraction. If we have discussion on the list that takes away if it becomes a contentious discussion and causes, you know problems within the working group. If it's people are spending more time on this than our chartered items, then that becomes a problem so.

O

Are you considering a recharging work to be in scope right now or you're saying we are not? Reach are during so we're not going to deal with these problems so.

A

Right now we are not reach are during we're. Gonna look at you know what what would be involved in returning and why we would return so we're looking at evaluating that. Okay.

O

U

Thank you yeah, so um typically uh you'll repeat, setup side.

U