Internet Engineering Task Force 111, 29 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF111-EMU-20210729-2330

Description

EMU meeting session at IETF111
2021/07/29 2330

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

A

A

B

Okay, so you are in the right spot if you want to be attending the email working group, eap, method updates, um hopefully by now you've all seen the note well uh I'll leave it up here for just a couple minutes seconds, uh but we'll now move on to.

B

The request so again we have minute takers, uh jabber window is uh or our jabber's open and uh people can talk in it or type in it, and we will try to relay those messages um and uh there are no more blue sheets, it's automatic. So when you're speaking, please state your name and always remember to try to keep things professional uh for the agenda. We have uh just to go over this administrivia and then we'll start in with tls based eat methods.

B

uh I'm gonna give a presentation on that and then on and we'll have a brief presentation on edpp and then epls ibs as well. um Does.

A

Anybody have any additions.

B

To this agenda or modifications that they want to make.

B

Excellent then, let's get started alan. Do you want me to run the slides or do you want to run slots?

B

It doesn't cost you much for me to run the slides, but.

C

Alan, are you doing I'm here? Can you get me? Thank you, okay yep, you can run the slides.

C

So if we go ahead, um not a lot aligned it with the tls one. Three draft based on go to the next slide, based on john's comments, use type consistently instead of random variations thereof, um some notes on session tickets uh that they must not be valid until after the inner tunnel off is done.

C

There have been issues with um eat previously, where, if you don't mangle the tls layer appropriately, um you can connect not authenticate with stuff like ttls and then immediately resume, and so you have to work around that. This is not even pls one. Three. um It's just a note that this was not covered in the previous specs, um updated section 5.1, with notes on protected success and failure indicators, the issue there is ttls when you have pap or chap inside, there's no protected success or failure indicators.

C

So the suggestion is, you might want to use eep inside of ttls to get those, and I think, that's actually pretty much it for the slides.

C

um The only other comment I would have on this draft is some text I posted to the list the other day based on random unnamed vendors, who decided that we should use anonymous identifiers inside of the tls tunnel, and perhaps there should be text in the document suggesting that's a bad idea, and so on. That was posted to the list a few days ago and I haven't seen any comments or updates to.

B

What that is bad about uh the uh anonymous cars.

C

Well, the the point is, usually you have an anonymous identifier in the outer layer. You know at example.com and then, when you go inside of that, you have ttls or peep with your real username, joe example.com, um and some vendors decided just to use the anonymous identifier in both places. So your inner identity that you send, along with your password, is at example.com meaning. You cannot meaningfully authenticate.

C

Anyone so yeah it's it's one of these rather surprising things that it got past the most basic qa. um So there's about four or five paragraphs of text in the list which I'm suggesting we add to the document before the next rev explaining we should have an anonymous outer identifier, so it's routed properly.

C

The inner identifier must not be anonymous. Otherwise you don't know who to authenticate, um and the inner identifier probably should not have a realm, because you already have one the outer identifier and there's no point in having it in both places.

D

So uh this is sean I was gonna ask uh if you did that, and you answered my question so uh thank you.

D

B

B

uh Mohit, did you have anything? I guess.

E

um Just the same question, I guess I don't know if we know which vendor is doing this, because how it's like, if you don't, have a username, how do you look up the database to actually do the? What.

C

Exactly exactly um there is this, is I mean if you go look you can find it. It was certain builds of android um and there were lots of people that I ran into complaining and going.

C

Oh god, this is a horrible horrible issue and the solution for their customers was to use the full name, including username and realm as the anonymous outer identity, because that's the only thing you could have you could configure, which would then be copied to the inner identity, um and so it works, for you know mod various versions of works that people can get online. But now you don't have an anonymous header identity, which is arguably.

D

F

Yeah, you mentioned to strip the inner username sorry. This is jan fred speaking to men strip the inner username of the realm, but I can actually think of some rare cases where the routing may have a different realm than the inner username. For example, if different user bases are configured in one server and also I have encountered some operating systems windows, especially which actually uses the realm of the inner username to determine the outer username.

F

If an anonymous identity is used.

C

Yeah um I'd I mean we can take this to the list for the technical discussions.

C

For me, I I have a hard time seeing where those should be different. um I mean, if we're going to call the outer identity, the routing one then yes, routing, should be independent from your actual identity.

C

um I I'd want to know exactly what the use cases for it that, for that would be and probably put something in the document saying hey. You know. This is why you do it, but in general, from my experience most of the time, those two realms should be identical.

C

If you put one in the indirect inner identity or else the inner identity should not have a realm um and stuff like windows, arguably, should configure outer and inner identities as separate items, because they really are.

B

Okay, so it sounds like this is a discussion we should take on on the list. There's a couple. uh I think a few little things to resolve here. um How many folks on the call, have uh read the some recent version of this draft or, if you could, plus one in the.

E

Chat, we have one.

A

B

And we need a couple more folks to to review this draft so that we can uh get it to a place and then we can last call it. So I think uh certainly have the discussion that we need to have. I think it's getting reasonably close, but um I'd feel a lot better if we had more folks on the call, if you haven't, is there anybody who would want to commit to reading this and reviewing this draft in the next month or.

B

B

Silence: okay, oh thanks bernard.

B

All right um I'll try to track down a couple more folks and give me some reviews um anything else. You want to talk about on this subject. uh Alan.

C

No, I think that's it.

A

Okay and then we'll move to uh the next presentation, so we're just taking a.

A

C

So yes, this is a bit of uh a monster draft, um it's just under 60 pages and may get bigger. um So we go to the next slide. The.

C

The problem here, the draft goes into this in in great detail. Beep is horrible and I I don't just mean the protocols and the implementation speaking as an implementator, it's hard to use and there's all kinds of text in the document.

C

Politely and anonymously gotten from a number of people about what people do with their uis apis workflows um and the answer, as we've seen with this with with this anonymous identifier, is people make random changes to everything?

C

This is an indication that nobody knows what's going on. Nobody knows what should be happening and there's a pain point which needs to be addressed.

C

It's all kinds of mdm vendors selling, expensive products for simplification, simplification, um ease of use, these have their own issues and, as the apis are changing and breaking um these mdm products becoming less useful. uh Next slide.

C

So the requirements device has a network connection. Untrusted is fine. Slow is fine root cas for web pki, a username and a password and per dan's comments on the list. That's a good point. It doesn't actually require the username and password all it really needs is the realm, but the initial purpose of this draft is end user devices, so we'll just call it a username and password.

C

So if we go to the next slide, um what the device does is it gets. The nai from the username looks up a cert resource record gets a uri which is https, so you don't need dns sec. um It doesn't matter if someone forges those dns records because you're looking up a uri in the nai domain that you were given.

C

You verify that the websertforexample.com is valid from your web root cas you download, whatever you find there um and then there's stuff inside those certificates, rfc 4304, among others, which can can contain network identification information.

C

And now you have a network you can connect to. You know the ca that sign the server cert. You know your domain, you pick each tls as it says in the document or ttlsp, some tls based eat method and you can authenticate knowing that the eep server you're talking to has a chain of trust going back to the http server and the web pki.

C

So we go to the next slide.

C

um There's a lot of details in the draft about variations of all this there's a lot of questions about what happens in this situation or this situation. That's all covered, there's lots of lots of details in the draft about what doesn't work and why these things don't work initially. The first pass really only needs dns and web configured on the server side and a client space user utility on the client side and no real changes to the supplicant code.

C

C

So it only works for tls based type, so stuff, like pwd, doesn't use this unfortunately, or can't use this. It does require some network access to bootstrap. There are possibilities of using unauthenticated etls to get any network access.

C

And so the goal is, for example, one use case is, you know, 10 000 university students want to get into eduroam, they have a username and a password and they just connect to eduroam with unauthenticated eeptls. Do some lookups for the university get the certificate information and then reconnect with full authentication.

C

There can be more benefits, which means moving some more checks to supplicants, potentially adding some new eku fields.

C

But the document is very long and goes through things in hopefully exhaustive detail and covers a lot of issues next slide.

C

So you can work in captive portals to get your configuration or, if you have lte, you can bootstrap wi-fi minimal, deep server side changes required, no code changes on dns or web servers. Your configuration can be refreshed. The document talks about how configuration refresh works um can follow a process, so the user ui can follow a process similar to web uis, but for network access, hey we're connecting to this network.

C

By the way I've checked the eep server certificate. There is a chain of trust. It is example.com. You are allowed to enter your password of sort, your name and password for alan example.com into this wi-fi pop-up.

C

So the next slide there's running code, a couple of docker images, so you specify a couple of things hey. I want to pretend to be this domain.

C

You can create some fake cas and fake certificates, and it sets up the client and the dns server and the web server and the radio server, and then it runs this 300 line python script, which looks stuff up and spits out configurations for wpa supplicant or for apple and their mobile config, and this is every piece of this configuration- has been trusted and verified.

C

So there's no need for trust on first use anymore.

C

C

um It seems simple enough: there's been a couple: people who've, reviewed it and sort of kicked at it a bit.

C

We could deploy it today with device utilities, as in an extra utility that you run in your client device which configures your supplicant. The first pass does not require code changes in the supplicant or the server side. Just here's a couple magic records in dns.

C

Here's a couple well-known places in the web to put certificates every client runs a small utility and 30 seconds later. Your tls based eat methods are configured comments. That's.

G

G

uh Yeah uh dan harkins uh thanks alan, so in in your example, you had uh alice doing a dns look up for bob's certificate, but doesn't dns require ip connectivity and this is still an eep. So how are you so.

C

Yes, this, this is all very true. um It does require some network connectivity, um so there are two ways to do this. One is, for example, you have a phone and you're trying to connect to eduroam. You still have lte or 4g 5g backhaul.

C

You can do your lookups there or what isn't so much in the current document, but does need to be fleshed out a bit. Is you should be able to just connect to the ssid with unauthenticated eat tls? And this was some of my comments on the list about hey.

C

We need a positive signal that you're trying to do eeptls by using an outer username of something like provisioning at eep.arpa, and now the eep server knows hey, I'm going to put you in a captive portal. You have network connectivity, you can do four dns lookups a couple of web downloads. You get your configuration, you drop the wi-fi connection, you bring it back up again with your new eep configuration and it all should just work.

G

Okay, thank you.

D

Hi alan: um this is sean turner. um Just a quick question. All right are we requiring it to be sorry pinned to the web pki or is this kind of like a simple enough? uh You just load. You need some trust anchor, so you're gonna load, the ones uh that are most available. Yeah.

C

This is just a trust anchor um the current code. That's there in the github repo in fact doesn't verify the web um server certificate. Whatever right, um you can always pass the correct options. The the key thing I'm trying to do here is leverage some pre-existing network connectivity and pre-existing trust to walk a chain of information to get your eep configuration.

C

So the easiest thing is just use the web pki and put stuff on dot well known, but yeah.

D

It could be anything.

C

D

Fair enough, so I mean like because there's multiple places where you can get trust anchors from so it kind of long as long as whatever your client is doing, gets back to its trust. Anchor store. That's enough! It's not like you must use. You know this particular web pi store. So I think that's that makes sense.

D

B

Joe, you are in queue just to clarify you. You use the web pki to authenticate the web server or what, whatever you have some pki. You can authenticate the web server and then from there you get your trust roots for for your eve connections. Is that that's the basis? Yes,.

C

Right, like like est, there's a dot well known, slash, ca, right um or dot when slash est, slash c well, we could have a dot well known, slash, eat ca, and if you trust that web server, you trust it to give you your eepca and then the issue as to whether or not that epca is already known or as a private ca.

C

um It doesn't matter anymore to a large extent, um there's a lot of discussion in in the document too, that I didn't even get at here about specific trust anchors.

C

um The problem with a lot of implementations right now is the ca stores on a device are leave your hands, largely global, which means as soon as one of these mdm vendors puts a new ca on, so that you can issue certificates for your local company.

C

um That city can now issue certificates for google too, and so there's a big discussion in the document of hey either you have to have a different ca store for eep or you have to effectively be able to mark up those cas as saying hey trust this one for web and trust this one for e, but don't cross confuse the issues.

C

um For example, some of the tests that people have done is you know, war driving, you go around a university campus and you create a fake ssid on your laptop. You create your own fake ca.

C

um You sign certificates for your university, which contain all the university addresses, but they're from this unknown ca and you broadcast an eduroam ssid and there are a good chunk of devices which simply never notice or the information they provide to the user is completely useless, and so the devices will go. Oh that's a ca. I've never seen before.

C

Oh, but it's something it's a ssid I've trusted in the past. Here's my name and password. The document suggests that this might be the wrong.

E

E

Could you uh joe go back a couple of slides to slide seven? I I think I had a question, but I don't know if I remember it.

E

E

E

Yeah, I don't remember what was exactly the question. Maybe something to do with this lock is green, so I guess yeah. Okay,.

C

So the reason I put that up there is right now, when you connect to wi-fi on pretty much anything.

C

You have no idea whether or not the server certificate is okay, whether it's from a known ca. It's completely opaque. I have a bunch of screen shots from different devices. Different vendors, where they do things like put up the fingerprint of the server certificate and say: is this? Okay and the user has absolutely no way of telling whether or not that's okay, whereas instead, if there was some way to get trusted configuration and trusted eep ca, then when the user tries to connect you can the supplicant can connect to the server and go hey?

C

It's a server for example.com and it's signed by a ca. I know this is exactly what we do with the web. It works.

C

And therefore, you know show that to the user hey, this is a trusted ssid and that kind of thing can be used for different ssids right. So the draft talks about how to configure ssids, but let's say the user- wants a config wants to connect to an ssid that he doesn't know about right. He should be able to just click an ssid and get told yes. The server see is the server certificate is trusted or not, and if it's trusted, then you can send over your credentials and if it's not trusted, you can't.

C

Anyway, the draft, as long as I said, almost 60 pages, it goes into a lot of detail about a lot of different issues. um What I'm trying to do here is to sort of give the 10 000 foot picture of.

C

If we leverage a pre-existing trust.

C

The examples here are web pki. Then we can get a chain of trust which ends up allowing the supplicant to configure e and the end user. For the user portion of this from the end user side, all they've done is enter, my name is allen. Example.Com and my password is super secret magic happens behind the scenes, and then they get a secure, wi-fi connection that they can trust.

C

That's a little better than what happens today, which is, I think at best. We can describe it as painful. You know. I mean anyone, who's gotten a new device and tried to get wi-fi configured to secure corporate network. um Your choices really are banging your head against the wall or downloading some mdm software, and then what happens right and then this is a question um two, which is, if you download some mdn software with the ca that comes from your corporation onto your personal device effectively, they can pretend to be google.

C

They can pretend to be anyone um and what it. What exactly does that mean for your own security.

E

Okay, yeah thanks. uh I think that answers my question. uh Maybe, while you are stayed at this slide and if the there's time for one more question, how like uh I'm not sure how this or how does eep work with captive portals in general and then like how like, could you expand a little bit more? What does it mean that it works with captive forces.

C

The issue right now is captive portals by and large, don't do. Eep um and you're you're left with some human reading, some webpage trying to figure out what to do and whether or not they have to enter their credit card information, for example, in an airport the nice thing about using unauthenticated etls, especially if we can use uh a realm like eat.arpa.

C

Is you just define this captive portal, walled garden to be the provisioning wild garden and the only things you can do in there are provisioning, and then the user doesn't have to read any web pages right. You just do your provisioning here, dns lookups web server lookups um and go on from there.

C

So the point and then the hope here is to take the person out of this process. You know, having pop-ups to say: is this server certificate valid? This is what I do for a living. I have no idea what to do with those pop-ups um and if, instead, my process is here's, my name and password and I get on, um I have a lot more confidence in that so yeah. Removing the human from the captive portal approach, I think, is beneficial for everyone.

E

Okay thanks, I don't have any other questions.

B

Thanks cool, so I think it would be great to have more discussion of this on the list. um There's definitely things we want to look into here I mean making this experience. Better is a good thing. So, thanks alan.

B

All right next.

B

Up, I think we have uh dpp. Is that going to be dan or owen?

B

Do you guys want to present anymore.

G

uh I'll present I'll try I'll see what happens all.

B

Right, it's an experiment. Maybe I have to stop first, I.

G

G

Request it says no slides available what.

G

Choose a deck to share. You know what joe, why don't you display.

B

Okay, there's a difference between sharing a display and sharing the.

B

B

Or sharing a.

G

Presentation, okay, great, uh can you do full screen there we go. uh So thank you. uh My name is dan harkins owen and I have been working on this for some time now. We got some comments from the tls group and like to bring it back into emu. So next slide.

G

Please so a little bit of background, the the wi-fi alliance has defined this thing: the device provisioning protocol that will take a public key and use it to bootstrap a client into a wi-fi network, and uh what happens then is the the client gets a guarantee that he's connecting to the the right network being defined as the one that knows his his bootstrapping public key and the network has a guarantee that uh it's it's provisioning, the right client, because it's the one that knows the corresponding private key.

G

uh This trust model, of course, assumes that the uh the key databases has is has some strong integrity. The whole security of dpp depends upon that. uh This bootstrapping public key is basically a base64 encoded, asn.1 sequence of a central public key info, and it looks it's transferred any uri that looks like this tpp colon and a bunch of goo.

G

uh The format of that is in the the dpp spec. But uh everything following the k, colon there is uh the base64 encoded key. uh The important thing here is the key is a raw key. That's not required to be in a pki.

G

It could be static and bound to that uh device or it could be dynamic, and if the device is a gui, it could display uh its key in the form of let's say a qr code on the gui or you know the device. The infrastructure could download this uri from from the cloud.

G

If you want to do a kind of you know, true zero touch experience, but uh once the the infrastructure has gotten this this key and authenticated the device uh the device can be given a credential that will allow it to get on any uh possible network. It can get a psk or a password. It can get a certificate if it needs it and it can get a thing called a connector which is sort of like a goldilocks uh credential.

G

It's it's not quite as weak as a psk, but it's not quite as uh as intense as a certificate. It's sort of like right in the middle. So next slide. Please.

G

So here's an overview of dpp, so the infrastructure is getting this uri either scanning a qr code or doing nfc or getting it from the cloud or something and coincident with that or maybe before that this device is is doing what's known as a chirp and uh it's it's chirping out announcing its presence and the infrastructure will then uh use that to discover this this device and use the bootstrapping key that it has downloaded to authenticate the device.

G

Once it's been authenticated, it can provision it with a credential, that's appropriate for the particular network that the device should be connecting to, and then the device uses that credential to connect to the network next slide. Please.

G

So if you're paying attention you're going to say well, that's great dan, but what does this have to do with emu? uh And that is a fantastic question. So dpp solves the the catch-22 problem of where you need a credential to get a credential, but dpp is 4.11 only and it doesn't work for any sort of other uh medium.

G

So what we wanna do is we wanna use the same sort of dpp bootstrapping techniques, either getting the public key from the cloud or from a qr code, that's in a bomb or on the device's back side or using nfc or whatever the the various schemes that dpp has provided. We want to use that to establish trust across both wi-fi networks and wire deployments, so we want to use that public key to solve the the same catch 22 that we have for wired enterprise devices.

G

So what happens is uh we can use so uh dot? One x is gonna. Do uh identity request at linkup, so there's no sorts of discovery. Issues involved, there's no chirping necessary, and so, as I mentioned, dpps.11 only uses these pre-association action frames, but the equivalent for that in wired is uh is eep, so we can use eep to do this sort of uh authentication.

G

So what we then need to do is use that to authenticate a type exchange and then use teeps existing s-like exchange to provision a device, a certificate on the device next slide. Please.

G

So what we need to do, then, is is use this bootstrapping key to authenticate tls. So what we do is we we take the bootstrapping key and we use it to drive two data. One is an identifier that identifies what key to use and the other one is a psk that we use for tls authentication.

G

We can then use that psk with rfc 8773, which defines how to use an external psk with with tls authentication, and we use that derived psk, so that will provide uh uh proof to the client that the server really knows his public key helps proves to the client that the server proves that cert by the server that the client has the public key, but also uh we can use rfc 7250, which is tls with a raw public key where the client can use uh his bootstrapping key to sign his particular share, and that will provide an additional proof to the server that the client has the corresponding private key.

G

We signal all of this with a new name coming out of the extensible psks registry- that's being defined by this draft here, so we're not actually requiring any changes to anything. There's nothing that changes in teep there's nothing that changes in 87 73, nothing changes in 7250 and all we do is ask for a name uh from a registry of names, that's being defined for that purpose.

G

Next slide, please.

G

So here's how it looks in tls, the plain normal font is the existing tls exchange. The boldface stuff is what's being is what's present for uh bootstrapping with with dpp and the red stuff is the new stuff we added so we're just adding. You know this. This bs key identifier uh from the extended psk's uh draft and then we're adding the uh using the cert with external psk from and we're indicating that the client will be using a raw public key from 7250 and other than that, it's straight old tls uh next slide.

G

G

And so how this all hooks into eep then to draw back to that question, you all had uh well we're going to use this to authenticate again with teep. So what happens is at link up? The authenticator is going to say who are you and the client being having? No knowledge of anything whatsoever uh doesn't know what his realm is he's just going to say, tls poke. Now there was a discussion on the list about whether this should be tls, poke, tlspoke.arpa or something like that.

G

Whatever we can, we can decide that later, but the idea is that the client responds with just some static uh identity. Saying uh I'm one of these weird bootstrapping people and the authenticator then will will initiate teep and uh teep will be authenticated with tls dpp, using the bootstrapping key that the authenticator has obtained, using whatever dpv bootstrapping method.

G

Once that's been authenticated, then we just do the regular old, teep uh s-like exchange, where there's a csr attributes tlv followed by pkcs10 tlv, a pkc7 tov, and then the supplicant now has been enrolled in the ca and all of his subsequent uh network connections will use this in the certificate that he's been provisioned with next slide. Please.

G

So where we are is we're on o3 of the spec. I hope everyone has had a chance to read it. We do have some running code for the tls portion of it. uh Owen has implemented this in mint and uh at this point in time we uh owen presented this to tls yesterday and they had uh no real comments about or concerns uh with, our tls approach.

G

So what we're wondering is if this can be adopted as a work item in emu as a solution to this general iot problem, that many of us have.

G

B

B

Okay, are there any uh folks who um want to speak up now about uh their opinions about adopting or not adopting this draft interest in this draft either positive or negative?.

G

Anybody read it.

B

Yeah I mean how many people have read.

B

G

I'll shamelessly do a plus one myself.

B

We have a few folks, I think we're going to need to get a few more interested parties in order to make sure that we have enough folks to do the review. um So, let's kind of work offline to see, if that something we can do so that yeah do we? Can we get some volunteers who are interested in reviewing this draft as well.

B

Okay, so I think that's something we need to work on. Okay um and then uh I think we can have a little more discussion on the list. uh Then we can see if it's uh appropriate to it's late thursday.

G

B

And yeah for some uh locations- it's maybe friday, already all right.

G

Okay, thank you. Let's.

B

Yeah thanks: let's move on to um next.

B

H

B

Okay, whenever you're ready- and I can change the slides for you.

H

H

Six, hello, uh I'm a mailing, transform channel mobile uh in this draft. We propose a method of using identity as raw public key in eaptls.

H

The current idea is is that we use identity-based signatures for authentication instead of just relying on a ca certificate.

H

Let's next slide, please.

H

We already gave our presentation at the ietf 109. Also some commerce were received. We can review it together. Our first question is what scenario it is for. The scenario are: is for internet of things, devices especially for passive wrong life device and other scenarios is also suitable is. Is it related to ibe?

H

We just use ibs signature to slow the identities authentication program, not use the identity based encryption here, any any running code. We are making implementation in our local network, recording efts ibs, based on their own efts 1.2 and using uh ecce and another question is any cross scope of iot obs. I have checked uh charter of the work group. I think they have no class scope.

H

Next slide, space.

H

And pres and the present, the version is, have been updated to version 02. Detailed modifications can be seen in the draft by the two tiers, so the slides just give a summary. We have two updates and two new a's. The first update is in object, which a a reference of draft itfts details. 13. The second update is in the introduction. We ate a text description in the draft uh draft itef e-m-u-e-a-p-t-s.

H

uh Certain race certificates can be of any type separated by tls in including raw public kings and in fc, uh 13, 32 and 15 it. Assuming that an out-of-band mechanism is used to bind them public into the entity, pre is ending their kin. These two uh tips is suitable for our jet.

H

It is sure that we haven't take the king d distribution into our javascript.

H

And the two new ace is the first one is in ia consideration part. So this document registers the following items in the merchant types registry under is tangible authentication, protocol registry heading and the second. The new is in uh use cases of the eats ibs. In section three, the one is used for authentication of uh iot and the other is used for system that do not support ca uh certificates.

H

Maybe uh it can just aid as an optional choice. If there are any other use case requirements we received from the comments, we will also increase this part of the use case next slide. The price.

H

We update the process in uh in figure 7 figure, 8 and figure 9.. We ate a round trip interaction based on the draft item: emu e apts certainty version 18 after tls finished the message sent from eap server, no more commitment message sent and after tia has finished. The message sent from us indicating peer will return an ap, requester message: waste tls application date, zero exerto, then authenticating peer. Give a response. Finally, is uh is aap success which flagged end of the procedure.

H

Next slide thinks.

H

Thanks to ras kellnes, when I want to give up this draft, he filed me by email and express economies.

H

He would do the asn.1 structures for uh person, one modules when it becomes an ifc and will reveal the part asn.1 portion of the specification to make sure they are clear. So we will continue with this draft for update what we'll do. Next, we will devise the king derivation based on eaps ibs.

H

If this draft become a what group draft one thing need to do is that uh eft space, the type needs to enter new type for apts ibs in the work group item, draft ietf, emuts, eap types and the next step. We want to try to call for adoption thanks and commerce.

B

um Do you have anybody who wants to comment on this particular draft and whether it's uh something the working group should take on or not, um and also how many folks have uh read? Has anybody read this draft and plus.

D

I'll be real, quick, um I'm not a lover of the identity-based encryption or than any signature stuff at all, but also I'm okay, with people exploring and doing whatever they want. So I'm, okay with progressing, whether it's in the working group, where you'd be sponsored or whatever I have no problem with that. um I don't really have an opinion whether it should be, it must be in whether it must be in the working group or not. So that's all. I really want to say thanks.

H

B

Okay, right now, it doesn't show that we have uh anybody who's kind of read the draft on the.

B

Whole call today, so I think what we need to do is make sure that we have people who are interested in working on this draft in order to kind of bring it into the working group it's possible to to take drafts, also through individual various individual mechanisms, if they don't have sufficient interest in them.

B

But I think the next steps are trying to get some.

A

More uh people interested in this use case.

H

Yes, I I I didn't know uh how many people have read their job, so uh maybe after the discussion, we can uh send the mail list and ask for artists for comments and have a red harris. A quick, quick look at my draft and I do not sure it is enough to ask for adoption.

B

Yeah, I don't yeah, so I think we need to. I don't think we have enough right now, um at least not based on this. This particular call.

B

So I think you know additional discussion on the list would be good for this graph.

H

H

B

All right, I think, we've reached the end close to the end of this session. Are there any other topics? People would want to bring.

B

B

All right well see if there are no other topics, uh thanks everybody for uh participating and we'll see on the list.

E

Good night.