Internet Engineering Task Force 103, 5 Nov 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF103-EMU-20181105-1610

Description

EMU meeting session at IETF103
2018/11/05 1610

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

A

If you would like to contribute to the notes on the session where we're taking notes and you've taken them an ether pad, so if you guys.

A

Alright I think this session is a time to start so welcome to email.

A

You've, probably all seen the note well multiple times, but since it's Monday, you probably should haven't seen it before. Take a quick look.

A

So we have started a github.

A

Section so that we can work on our drafts there and I think several of the drafts are already up there.

A

So let us know what you think of this. We use this in TLS extensively and I know. A number of other groups have used a lot to help track issues in the status of the document. Still emu WG is what you're looking for on github.

A

Ok for the agenda, I think blue sheets. We should send those around and then we'll talk about, epls and then EEP aka and then a couple of the items that are newer items that aren't quite on the charter. Yet so.

A

Anything anybody else had and the agenda bashing that needs to be done.

A

So we have two working group drafts right now and they're different kind of dress. Then I guess there's an emu beer in Australia so or I think it's Australia and.

A

But are the drafts were working around are different. We have the epls one, two one, two three and the EMU the EBA ka this. So those are the current working group items. I think we'll have a couple more that we'll be bringing into the working group soon and hopefully we can start getting these towards completion as well. So I think this will be a good meeting. I think there's a significant work done on both of these areas, so.

A

Are we up with, which is the yeah.

A

Is this where we want to start? Are you good job, I think so? Okay I think you may need to. Let us know when you want to change, slides, I, don't know if you can do it remotely I.

B

B

Something there yeah I see great, so this is version 2 of the ETL s103 draft. The version that was presented at the last meeting was Cirrus 0, so we have seen to update so his drops and basically the the discussions and conclusions last time was most of the things we discussed at the last meeting. We decided not to change, but what two things that we decided to change and that has been done. So one of the changes are quite straightforward. There's session, hiding out story, serie de as suggested by bernard, a boba.

B

The other discussion resulted in a comment from him suggestion by him short to add md TLS record to the protocol well to lower the uncertainty from the EP r of going into the details of this.

B

But it has been done and there's a new section in the document called EAP state machines that discusses this and then there are some editorial changes, and this was the changes to the between the 0, 0 and 0 1 version turn the changes between the 0 1 and the 0 2 version are only in the privacy considerations and considerations for pervasive monitoring.

B

As well as some additional editorial changes yeah, so the first change is, as I said, quite straightforward, if TLS should start with 0d x value- and this was missing from serie serious pointed out man out. So this is now updated.

B

Instead of deriving the session ID directory from the TLS exporter, value called method. Id is the right, and this is according to some other ear, PT RFC I, don't remember which, and then the session ID is created by concatenating 0d with the method ID, and this makes the session ID 65 bytes long as in RFC 52:16,.

B

Next slide on the streets, any comments.

B

No other change that may resume or the passion is the empty TLS record, and this was brought. The discussion was brought up by Julie at when he implemented this year, maybe not the syriza version, but diversion even before, and he said that with a new session ticket, it's hard for the client to know what will come next and it messes up the EAP state machine a little bit and was comment from ban on that. It should be made cryptographically secure and him short suggested added an empty TLS record.

B

It seems like a good idea, so the mekinese implemented in c1 and c2 is that.

B

Yeah, a piece server commits to not send any handshake messages and handshake messages include the post hajeck messages, including them new sec session ticket, and it does that by sending empty, TLS record and don't know, we should go through first.

B

Let's see empty TLS record, this is just an empty application. Data application data record later with links where the plane takes length is 0, and after doing this, the server does not send any more handshake messages it. But it's still three possible options what it might sends, and after this it's each success, failure or a TLS alert message and, as I I will show you pictures of all of this but yeah.

B

So first here's the case when we have success to the left. We have a the ordinary, successful mutual authentication and, as you can see here, marked with a green rectangle, we have a new field here, the TLS MD record, and by sending this the server commits to not sending any more handshake messages. And here, in the case of a successful client authentication, the server responds with each success.

B

On the right side, we see a mutual attempt, gage successful mutual authentication, where the service sends a new session ticket to enable resumption in the future- and in this case the server does not send a empty record after it's finished because it it will send a post handshake. So it sounds a empty record after the new session ticket and I'm. In this case, everything is successful.

B

B

Here is the message diagrams when you have a failure.

B

In the left page here there is, there is no empty record because we'd never reach that state. The client, the server, reacts, the kind hello in the right side. We have this case where the server authentication fails, or the country exits for some reason, and then this is the case. Without a new session ticket, then the client, the server sends TLS empty record and afterwards it will be a EAP failure.

B

The next slide we will have the most complicated case. So here is the left side. Here is the successful mutual authentication, as described earlier, the server commits to not sending any more handshake messages, and if everything is ok, it was a leap success here, but on the other hand, if everything is not okay here, so the server reacts. The client authentication that the server responds with a request with a TLS alert message.

B

So the commit here with empty record is to not send handshake messages, and this is serving the best we can do at least it. This is as far as I can understand, aligning with RFC Phi 2 1 6, in which this case is what happened. If the client authentication fails during a resumption, then you have the same scenario. This service ends either success or it sends a key, less alert message.

B

B

So the next slide is potential updates to this.

B

One thing was that, when writing this presentation, I noticed that we have error cases, for we have figures illustrating the message flows for basically every error cases, and this was requested on the mailing list to add more error cases, and so now that we don't have an error cases for the eap-tls client reacting the new session ticket I assume the client was under TLS alert message. In that case, do we want such a figure and that could have be edited next word.

B

Them further update a couple of Mia had discussion about privacy, and the peer may reveal its identity in two different ways: it's, firstly, it can send its identity in clear text in the first EAP response called ident. My idea I think Oh my identity in droves, and this is for all TLS version and the second way the peer may reveal its identity is to send its certificate in clear text, and this only happens in previous versions of TLS.

B

What we can do in the privacy for privacy is a little bit restricted with what kind of legacy interrupt a deployment modes, but one thought I had was that? Can we do something more specific about the identity sent in the first message? Can we can be always can be recommend or mandate that appear sends confidential identity, for example anonymous nigh or is there in your key service that will not like this RFC five, two one six is doesn't say very much about this. It says that service may that doesn't support privacy.

B

My may go to failure when the client sends an empty certificate list, but it doesn't say anything involved identities. As far as I see yeah.

C

Question from hidden Jim shot um in point of fact, Ashley radix essentially says you do send just at your domain and in the first in the first, if message and they use ETLs in a lot of places, so that is standard behavior. That's there's no problems with that. Yeah.

B

So should we have come here must yet.

D

B

It's good see the third future potential update that I had been considering when writing now the updated privacy section is that, should a dog give any guidance since rc5 t16 was published.

B

Several attacks on TLS earlier versions of TLS have been published, which is one of the reasons why TLS 103 was developed and published.

B

But in fact most of these attacks don't really apply to EAP TLS, as EAP TLS only do a handshake and that's not Tech application data for long period of time, but some other attacks probably do even if I have not remembering the detail, should a draft give guidance or references how a implementation should mitigate attacks on early version of TLS.

A

So speaking as an individual I write right now- and this is Jo salary I would, I think, certainly we shouldn't really talk about things that aren't actionable to somebody who's implementing it for things that don't apply, I, don't I, don't think we should should include I'm, also a little bit reluctant to include things relevant to earlier versions in this particular update, but I'd like to hear other people.

E

Yeah, yeah and I agree with your advice. What I came up to say here, though, is that I struggled a little bit with the similar issue and the aka draft, like how monster of the aka attacks should I describe and one of the crucial things I I think determines. This is if there is a reasonable reference for, for those other things and I said I assume lean in the case of TLS there there is TLS working group documents past the ls1.

E

One free document actually describes some of those old attacks, so you have a good reference to point two and then you could just handle the things that actually apply to your protocol.

F

The question is: if there are attacks against TLS 1.3 in particular, that would not be mitigated by the advice given and security considerations for one three and our quit or are in any way specific to eat. For instance, then I think those have to be described here in some detail.

B

So it doesn't seem that we should have a long section. I, don't think there are any attacks on TLS, 1.3 I think there is a document in using TLS in application describing attacks.

B

Should we just refer to that or not even referring to that.

F

If this is Elliot again, if you think the attacks are applicable, then you certainly should refer to them. You don't have to read, ascribe it, but adding maybe a at least my advice would be to just add a reference, but not to spend a lot of effort. Recapitulating everything is something that went through a whole. The whole process of an RFC did no.

A

Yeah, it's also not clear to me that we we want to go too much into what the problems are with the old versions and how you may or may not be able to protect against them.

A

A bit I'm a little bit torn because that could be useful information for some implementations, but really, if they're reading this document I think they're more looking to implement the new thing. But if, at the same time they could mitigate all things that I.

B

Had a short reference down to that draft.

F

So just this Elliot again, one thing you can do is you can put it actually something in the front matter of this document which says this I. If the attacks are actually motivation for this work right, at least in part, some of the some of the holes and the earlier versions of TLS or motivations and I think you've done some of that right. But just maybe you could even add a reference up front against that. You know you don't have to go into any detail.

F

I really, wouldn't alright, that any time we muck up these specifications with a lot of you know motivational material if it gets to motivational people or like okay, get on with it. What's the spec, but a line is not too much yeah good.

A

So so maybe the appropriate thing to do would be to figure out what what is applicable or you know what attacks are applicable and if.

A

It's not clear to me that there's going to be a whole lot.

F

Hi, this is Elliott again so that one of the reasons I'm, sorry for speaking so many times with microphone, one of one of the nice things about doing a little bit of that- is that some of the attacks that we've seen on earlier versions of GLS are already like browser specific, or you know very, very much focused on on that on that particular use of TLS and so calling out the non browser risks.

F

You know a line or two in the non browser risks, maybe might might be useful and the reason that I say that is that we've seen- and maybe this is a good thing, but we've seen basically a blanket. You know attempt to just get to the latest version of TLS without actual analysis of what the attacks are and that that that poses a long-term threat in terms of people having spent money on upgrades that they didn't need, and they say: oh you're, just a boy who cried Rolf again see they're.

F

Having actually specific justification does help on that I.

B

Could I could send an email to the use of TLS in application list and the TLS working group and see if asking for advice, what that what of the attacks would specifically apply to ETA EAP TLS when you only use the handshake?

B

These group working groups have the expert in this area sooner. People are probably have these details in their heads. Let's see if we get any advice, I mean.

A

That's that's probably a good approach. I think that there may still be.

A

The people in those groups won't know exactly how he uses it and those particular use cases, so they may not, they may or may not. You may or may not get yeah.

B

I Adam I had a reference and them and then we'll see what feedback I get from the discussion. And but we keep it short and very.

B

Only things applicable to epls.

B

Not spending too much time that ya think mm-hmm. Let's do any more questions next slide, so this was quite short I. Take that as people like the changes, if they have rather I, think this. What is trough needs now is more more reduce and more feedback, also more implementations and possibly interrupt I.

B

Don't know, what's the shares views, how do we move forward? mmm Could we get somebody to commit to review this or.

A

How many folks in the room have read the draft okay yeah? We would in order to kind of move forward on some of these. We need some more reviewers there. A few folks in here could commit to doing a review. Jim shod anybody else. What's your name, please.

A

Make sure you make sure we get that in the notes? Daniel you wanna review as well yeah, so I think we can get some more reviews. Do we have how many implementations do we know of any.

B

Junie had implemented this at least Bertram.

A

So we'll need to find some more implementers to have an interrupt.

A

So I think if we can get a few more reviews and and kind of finalize these last open issues, which is seem pretty pretty minor, we may be able to start working towards a working group. Last call on this sounds good.

E

B

So this presentation will hopefully be very short, so we made an update based on the discussion at the last tight. If you go to the next slide, so it has been updated from 0 0 to 0 1, and it's not that much add added information. It's the drug has been reorganized to distinguish between recommendation requiring change of certificates and recommendation only requiring changing the code. For example, update me to TLS 1.3.

B

So there and there's some new text describing the cached information extension that was discussed that last time stating that it in some cases is not helpful if the handshake phase anyway, but it can be helpful if you have done a notification in your home network and on your roaming and an or full handshake without this would fail. This can make it possible to do a handshake there authentication.

B

Then there is a new text stating a TLS can significantly reduce the number of messages exchanged.

B

There's a new section placeholder for guidelines for certificates more going into the details of different fields and things you should do in the certificates, and then there are some editorial changes can go to the next slide, so the news document structure is basically to split up section 4 into 3 different subsections.

B

Where, for that one looks at things: updating certificates for the two looks at recommendation and guidelines updating code and for the 3 have guidelines for certificates, and here we are waiting for input.

B

Shaun Turner promised to write something eventually here, which we might hopefully have to the next site of meat.

A

What was what sort of things were? Gonna go in the guidelines section.

G

No, so Shawn Turner had some ideas on how you can give guidelines to people issuing certificates like don't put tons of oh I'd ease into the certificate. Don't have like thousands of subject all names in the certificate, so those kind of guidelines specially so using TLS on the web is a little bit different from using TLS on Ani, where you have access points that dropped sessions, if they don't complete in in time.

A

Okay, you can try to find shun in Bochum.

B

All right yeah next slide, so that's it except that planned, update from Shawn I, don't think we have many many many else planned updates. We will need suggestions and review some feedback from the working group and both this and the eat. Eap-Tls 1.3 draft is on github. So if you want to know what we are planning for the next version and any open issues, you should look there and feel free to commit issues there or make a pull request or comment.

A

Okay, any additional questions or comments on this well, we'll need reviewers for this as well, but Vic. We focus on the geo s13, getting those reviews done and if we get that movie we'll be able to get this moving to I think.

A

All right anything else with respect to each GLS.

A

Alright, thank you, John and I. Think we'll move to heap.

G

A

You are you're up.

E

Okay, so I'm just gonna go through the draft and some of the issues there and and if you're, in the room and and and don't know what this is about. This is basically some old or ten plus years old technology that has been very widely implemented.

E

But it's now finding also use in in the upcoming 5g standards and as part of that, we're trying to make sure that everything's, correct and things that we've learned in the past or things that we missed on the first specifications are actually corrected, and the initial thought was that there's three things that we need to do identifiers are a little special in 5c, so I figured. We need to do something for that. The EAP aka prime, does sort of, like a network name binding that you.

E

Both parties agree to what what they're, what they're authenticating for, or what network they're connecting to and that changed a little bit also for 5g, so fix that, and then we knew that exported prime-minister forgotten in the old RFC's that we didn't do that. Even those mother RFC required that so fix those three things, but it turned out that we actually needed to do a bunch of other stuff too in the meantime that IETF demands for what should you talk about in the security constraints?

E

Dissection have increased like talk about privacy, more talk about pervasive monitoring considerations. Of course we learn something about vulnerabilities in the meantime, so document those better.

E

Also, we get some comments actually from John relating to say, denims and fast. We have the gates and identifiers x' and how their spec on the previous version was a little bit weak, didn't specify how to do that securely or didn't set the requirements right. So we did that dated some references.

E

There's been two updates since last IDF, l2 and l3. The general state is just that. We now believe that this well I know I said this before, but now we really believe that this is in sync, with 3gpp specs we've done some 5g related updates. We've done some general updates and we've done a lot of work with the security consideration. Section I'm gonna go through some of the main points here, so, first of all identifiers.

E

This was kind of clear previously used the name that was sent in in this protocol and and it's important to get this right, because the identifiers are not just like things to point to the right record, but it's actually also used as bits inside the key database, and so so, if you get it wrong, it's gonna fail miserably, hmm but in fight see, there's couple of additional considerations.

E

The first of all the EAP session is inside the 5g native attachment procedure, and you don't actually need the EAP I didn't do request in response to sort of a extra round trip for no good reason. Let's take that out in the count. There's also two different identifies.

E

One is the permanent identifier called the soupy and and then as concealed or privacy, friendly I didn't if I call tsuki or Susi and- and the idea is that these are used for different purposes- that the permanent one we can use for keys in a race or no, that's that's what they wanted at 3gpp. So that's what we'll do and then, obviously the privacy friendly one is the one that we used use for any any other passing of identifiers around and there's couple of things in the draft.

E

First of all, you or this additional text to fix this case, where, like the previous RFC said that always ask or should ask I think, was the was the phrasing for identifiers inside the EAP aka method rather than the EAP framework, but in in a case where you are connecting to a 5g network and using the 5g protocols to do the signalling and and man-carrying EAP there. Then you do something slightly different. It's of course. It's also requirement of implementations to be able to do this or detect this kind of situation.

E

But of course, we can't really always guarantee that there's there's never a case where no no identifier czar asked for so one has to build for that situation, that u.s.

E

phone or or some kind of other client will actually get a request for identity. What do you do then? Well um 3gpp had developed a table. What to do in this different case is there and we basically follow that same here just to make sure that specs are aligned. This applies only to 5g case here and I. Don't represent the whole table here that point. Let's just give you an example, so in 5t, because the basically old identifiers that you pass around publicly are privacy friendly identifiers.

E

Now, if they're on the EAP level, somebody asks you for the permanent identifiers. That's that's a warning sign. It's probably not not agreed with that. So that's why the spec said says should respond with an error code. In that case,.

E

Key generation I mentioned that that we use one of these two special identifiers in key key derivation. So there's some language about that like under what condition you do that and then this is what you do, and these are the bits and, regarding the bits, there's a format question: it's not just a conceptual thing, but also a question of exactly how to represent things.

E

There's a reference here to 3gpp specifications where they represent their identifiers in an nai format, so they're identifies can be regular in a eyes, but they can also be MC numbers and and there's two different identifiers, as mentioned earlier.

E

So one one is this permanent one that is in the clear here's the example in the upper or the upper example is like that it's kind of easily readable and then there's a encrypted identifier, where the network part is like you specify what operator you go into, but then you hide the subscriber identity part with public key encryption. That's been specified in in 3gpp, but it still maps to a in AI, and so we don't specify any of that. We just point to that then and provide some examples.

E

So that's identifier, and then we have another thing that we want to make sure that the 3gpp specifications for IG and and the RFC's agree, because the previous RFC declared that in in in these- and this is these situations you use like these strings to determine like this is for wireless LANs. This is the string that you should use and and so on now here in bit, 5g we're introducing a new string.

E

The the actual strings are in the Fiji PP spec, but but it's a different document and different version than the one pointed to by the original RFC, so so we're pointing to both and and then their clients are required to or actually in this case, the server is required to to figure out what what is being done and which, which identity or which network name to use.

E

We export some parameters for citizen IDs for fast reopen for the regular case and some peer, IDs and and server IDs. I should note that we're actually in in sort of the common case.

E

To be the empty string, mmm because they're like well, unless the IDs have been passed in inside the the EAP protocol, which in this case doesn't or at least for 5c, doesn't usually happen, then then you don't have that unless you take the ID that was passed in in the lower layer and we chose to use the empty string, not quite sure if this is a problem or not I, think it's not a problem.

E

If people have comments on that, that'd be useful. My understanding also is that, while, while there is an RFC that requires us to export these parameters from EAP methods, there isn't a lot of implementations or even any implementations that would actually use this infamous all right. People who have EAP experience care to comment if they seen this this information, but depending on the answers this either matters a lot or doesn't matter a lot moving on.

A

Just you might check if it's relevant to you I think the ab fab you looking to like there was this ab fab effort that used dape within gssapi course, and they may have used Kennedy's, I'm, not sure and I'm, not sure, if that's even relevant to your use case. So we.

E

Looked at some common, open source implementations and didn't find any code for this, but.

A

Other than that, the only uses of that type of information I know is for like accounting purposes, which you probably have dealt with in another way.

E

And then the previous RFC's- and this has nothing to do with 5c. This is like a totally general change. The previous RFC's defined this pseudonym approach and fast via indication, identity approach, and they they sort of provided special usernames that can be used in these processes and and the assumption was that these be like totally random, and you know you cannot figure out what the user is from those, but we didn't actually say that in the specs.

E

So now we're trying to say that that you have to generate them in a fashion that doesn't reveal information about the subscriber or the user, and so, for instance, a counter would be a bad idea. Random number will be a good idea. User name counter would be a terrible idea, and so on.

E

We wrote the entirely new section on privacy considerations just going through the basic implications of different identifiers types. We set some limits on what to do in 5g.

E

So if in fight see, you are sort of protected against privacy violation, so looking at identifiers and then then you suddenly use pseudonyms and use the same children in multiple times. Then then you've disclosed that that you're the same entity in these two instances and that's bad, so the purpose of the 5g enhancements would be lost. If, if you did that, so we are prohibiting that we discussed the implications of different protection profiles of 3gpp when they did this encryption of identifiers. They have multiple different profiles, including the new profile.

E

It's surprisingly, it doesn't provide much privacy, discuss that and we discussed that the domain or operator is typically visible in these identifiers. Even if the subscriber identifier is this piece of is hidden.

E

We also added a section on pervasive surveillance considerations discusses in particular the attacks that were claimed to have happened a couple of years ago. 2015, the sim heist look up the reference from that draft and obviously all protocols are vulnerable to compromise of the primary key material. We discuss some specific means to make sure that that doesn't happen when you manufacture these cards. I mean also suggest that some form of perfect forward secrecy protection may be useful.

E

We're not requiring that or pointing to you know must do this spec, even if we have a spec that we'll talk about in a moment, but so we're just providing some advice. Yeah.

E

We did add a fairly extensive section on discovered vulnerabilities, and this is what I was referring to when we were talking about John's draft, how much to talk about general aka, how much talk about aka, prime issues and I didn't have a really good trip. We were unable to find a really good reference for you know here are all the attacks. You know sort of fair and balanced manner reported on on aka, so we try to write our own.

E

We do try to point out which things actually apply to aka or APA ké and which do not so basically, there's no like there's no attacks on the fundamental properties of authentication on the original assumptions, but but you have tons of different attacks.

E

So obviously, if you leak the primary key material, you're you're gonna have some breakage so that that was what we talked about previously on the sim highest case.

E

You can also have the protocol participants misbehave, so in in Triple A systems network access.

E

You typically give some keys to the local network, giving you access and then, like your access point or your 5g network or whatever could potentially claim to be the the user incent in the sense of sending packets, apparently from the user, and and that's how it is I mean it's not that necessarily super concerning, but that that's that's how things things are in in almost all access networks that I can can think of or no altercation schemes that I can think of and and then there's some other stuff.

E

That is not really relevant for this, but I did point to like this. We did. Some of us are c-33 10 that is aka inside HTTP and he turned out to go really badly and we didn't use the crypto keys in the end result, which meant that this is vulnerable to man-in-the-middle attacks and fixed that in later RFC, 41 69.

E

So we're clear, except that that's now what ten years ago and and some people are still using the older one, including some SDS, referring to the older, older spec for some reason.

E

Maybe that's a task for some of us to give and fix, but that's how it is.

E

So that's that's, basically the the bigger issues in in in this draft or issues or things that we had done in the in the previous round and and where we are, would love to get feedback and discussion. There's someone going discussion also with some 3gpp people are being able to at least interact with some some other implementers we're implementing some of this, but there's also others that do this and like going back and forth like what do you put in the identifier fields has been useful.

E

We're also trying to add a reference to this draft to 3gpp specs, we'll see if that happens, hopefully they're having a meeting next week. I think, and we think we understand now the interactions between the 3gpp specs and and this, and maybe this it's worthwhile to note that like. Why do we have to do anything to begin with, like you know, if they just use your your RFC like?

E

What's the problem and- and that would not have been a problem if they just use the RFC, but they actually wanted to use the RFC, but do these and these changes and behave in this slightly different manner. So that's why we have to Tran sync up because the the, if we don't sync up and then the result, is that the RFC will say something and possibly some implementations will fall the RFC and not do the five G thang.

E

For instance, we talked about working group last call I, think if we did one now like after the the meeting that would align nicely with some other things, so so in right.

A

Now the draft is up to date, kind of discussions and things that you've had in 3gpp and elsewhere. Yeah is is any how many people have read this 5448 Biss or any any version or later the better? But okay, would some of you be able to? If we do a working group last call, can you give a review of the latest changes?

A

Okay, progress, so yeah I think we can bring this to.

H

E

Okay, so so this is the other graph. This is some extension to the previous work or the or any APA ké prime protocol could be extended in this fashion. It's not a working group document that, but we do have a work item in the working group charter for this and.

E

We've discussed about this extensively last time also I have taken into account reviews or discussions that we had last time and, for instance, mo its review and and and this person is more detailed. We also renamed the attributes and made the protocol use the e cd8, the 8e terminology and RFC 80 31 terminology, and we clarified the use of the negotiation process. We only send one key if there's like negotiate groups of algorithms and and so on, so we never send like multiple keys.

E

We always send exactly one key that the one that we're trying to do and we clarified the resulting security properties, interesting exercise, trying to understand exactly what does this mean and then last time without being honest, who brought up denial service attacks, try to clarify that as well, and so basically, the protocol is that there's.

B

E

Pair and the server and and they big some some private information and and generate some public keys based on that using elliptic curves send an EAP aka challenge requests with, like the all the usual attributes, but also the attributes relating to the perfect forward secrecy, calculation and now my attribute names may not be actually updated on this slide entirely, but to be updated in the draft and then, if, if the peer appear does not support, this doesn't know anything about this.

E

This protocol, then it will just ignore this and continue us as it does normally, if that's allowed by the the parties. But if it doesn't and and want to do this protocol, then it also picks its private information, generates a public key and there's some calculations and since the public key to the other side, it's also does some calculations based on the private information and and the other side's public information.

E

You calculate the secret and then you feed that state secret into the process that normally in a PA, PA, K Prime would result in the master keys and then used. That would result in the in the keys that are output from from aap aka process or the EAP method.

E

So it's pretty simple at that level.

E

There are some tricky parts, though, so one is backwards, compatibility that I already talked about a little bit how to avoid change this or how to run in in different kinds of environments. Very, not everybody may be supporting this yet and how to minimise changes all over there's some negotiation issues with both like how do you negotiate if you have support multiple algorithms or groups, and and since there's already negotiation processes in in the EAP, a K Prime?

E

How do you fit together with that and then there's those issues so I'm going to go through these briefly, so the first design principle was that, like we don't want to actually want to affect us in cars, because that would mean, like we'd, have to send SIM cards to everybody again: couple of billion SIM cards and coastal at least a couple of billion in the stamps alone.

E

So we tried to do this on the phone and then on the network side. We try to put it on the EAP server code, not not there, not the server. That holds the permanent secrets, so this keeps the interface sim card in the authentication database unchanged and no changes to the minimum, minimal changes to infrastructure and no changes to credentials. But, of course you have to change the port. You have to update the phones, have to update the EAP server.

E

The the other one is that we wanted to make sure that we can do this in a backwards compatible faster and even, if, like we have partial deployment and, like my server supports this already, but not every phone, does it yet and we can't exactly figure out what what phone is on the other end at that point, so we want to avoid situation where would like have to wait until everybody's deployed or cause some penalty in performance when, when expectations don't match, so we wanted to do this so that there's no extra round trips when we use this new feature and if we fail to use the new feature, I have to go back to the old way of doing things.

E

That's also no extra round tips in that case, in terms of we can run the process in parallel, which is through the old thing, and then on top of that we do the new thing in the same messages, and- and if that succeeds, a both parties supported and then the output gates will will take into account the new thing.

A

So in your use cases with 3gpp would it be possible to, instead of because you use a different EAP number different method.

E

A

Different method- type 1 code- yes, because I'm I haven't looked at it enough, but you could try an approach where you had we're able to encrypt more of your messages using the diffie-hellman.

A

It might always add an extra round trip.

E

That that is the costs. Okay,.

A

E

I'm not like we'd have to do the math like what what's the benefit, but that that is exactly the cost. That would add an EAP level negotiation if the other guy doesn't support this new type right and and and that's that's because the way that the EAP was or it's yeah.

A

E

A

You don't have because yeah all right I mean that might be something to have a little bit of a discussion about and CFE I I. Don't know what benefit you would necessarily get from me for encryption either. But I mean you would get the benefit of the encryption, but how important that is in this scheme, but.

E

You don't get like.

A

E

Encryption that you would get like it's actually I think it's not not that like there's other ways of doing this, but I think the benefits always but then like. If you just do like a EAP level, negotiation I, don't think you actually get any benefit from that. It's just do the same thing, but then, but if you reorganize the messages in some other fashion, that you did like a little bit like Ike, v2 or actually one, that's the first.

E

Do this key material generation thing and then on the next set of messages you do the rest and then you can actually encrypt, maybe more and that that might be a like a useful thing to do. But even that has the trade-off of next arounder yeah.

E

So this negotiation or new negotiation in this extension, so it's a simple extension but but you still have to build further possible there'll, be more than one algorithm or more than one more than one group in the future. So so for that that we have this 80 KDF PFS.

E

That indicates the the preferred algorithm is the first one and then the possible other algorithms and server sends this. And if the preferred algorithm acceptable, then the peer just executes this protocol and and proceeds and there's no RTT here. But if, if you do want to do some of the other ones, not the preferred algorithm by the server, then then, then the peer indicates that I want this. This other thing instead and then the server responds and then there's some special rules that you like you. You carry the the old irrelevant information.

E

Still in all the all the messages that you can't actually change anything without causing the max to fail, then you have to check for that, but that's always a round-trip. That is added. If you don't go for the default and only the key for the like.

E

You sent the generated public key on the on the first message from the server, assuming that the guy will will accept the preferred algorithm and if he doesn't, then you have to send another one with with the other key, but you never send more than one exactly one always and then there's a question of how does this negotiation process fit with the previous negotiation that exists for the KDF negotiation in the original RFC and they are actually very similar.

E

They exact exactly the same process just that they're negotiating a different thing and they're currently defined as separate like. If, if you have to do the negotiation, then you do one and then you do the other one after that, in theory, we could probably define this to happen also in parallel, but maybe that's not worth our time seems simpler. This way people have opinions. Otherwise, then talk about that.

E

Denial service and and Hannes had this question last time and Russ I think you were also commenting on that that about the order of computations and that was actually partially in the draft already last ICF I wasn't entirely there and now we have all of that there and and also talked about it in the security considerations and here's the deal. So.

E

The first message in this whole protocol comes from the server and- and it doesn't come unless you like we're already identified that this is this, is the given subscriber or that like we haven't, authenticated the subscriber, but but we've seen a valid user name and you can spoof this, but it requires that attackers at least use specific, real identities. They can't just randomly generate numbers and and try and use them.

E

So that's first level of defense and the second level of defense is that once you get the messages, then all the parties at both on the pier and the server side. They will first do the the old process. They will authenticate using the long term shared secrets and make sure that that that succeeds, and if it doesn't succeed, then the person or the other party doesn't have the right key and therefore this is an attack and you you, you bail out. They never do the expensive computation. It's only after that.

E

Succeeds that that you, you run the expensive computations.

E

So the parties need to show possession of the of the key material before they they do. The heavy calculations Russ.

I

Sorry I just don't remember where the Mac check falls and where the key for the Mac comes from, but it seems that it's important to avoid the downgrade of algorithm attack the Mac right. Yes,.

E

I

It would also I think effect. This.

E

So the Mac I I think the Mac is it's done like it's, it's done. Ask the the the the previews or the original RFC. Does that. So you calculate that the Mac process is done, that that is step. One and step two is generate the keys and then the resulting higher quality key is then that is the output from the EAP process. So now your traffic protection can be protected with this higher quality keys, but your Mac will still run on the original process. So what.

I

I think you said I'm just repeating it back to make sure I understood is that the Mac is dependent on the base. Aka authentication, yes, okay, thanks and.

E

So after all of this like, if you still have somebody who's trying to dos you successfully, then you can take some operations. Actions like blocking that particular subscriber. It seems to be sending millions of requests. For instance, I.

E

Updated the security properties also trying to be accurate here. So basically, what does this give you? It gives you that and like if we have used two SIM card and now somebody at some point learns the key then and and and that somebody has recorded all your previous conversations now. You can't go back and look at those previous conversations and decrypt them, because PFS was was in effect in in those things and also if the attack you're still I mean, has the key but doesn't do active attacks.

E

Then future communications are also secure and then, if the attacker, who has the long term key, is also an active attack, then nothing can be done like they can. They can do anything. They can be pretend to be any of the parties they can. They can be also be a mitten if they need to and they can determine the session keys change. The negotiations yeah.

E

And yeah, so that that's the that's the end of my list of these three key things here that or the updates that that we've we've done and like with the previous one love to get some feedback or even more feedback than we've gotten so far and I.

E

Think this, at least from our aside, would be interesting to see this working group document again. There's this window of thing for some some amount of time into the future. It's not not the next week thing, but for the next half a year or something like that. If we have a solution in this space, we might actually be able to stick this in into the next release and actually have an effect on on people's security.

E

In this sense, protection from the organizations that try and spy on things and and there's some some interests from our side. Certainly and then another manufacturer working on the chipsets may be also interested on this. So we might actually get this actually deployed. If we do do it, so I would love to move forward on this. So that's the end.

A

E

A

Many folks have read at least one version of the ek PFS, not so many, but a couple, that's good, and is anybody well, let's, let's take a does uh I'll ask how many people support adoption and, if anybody's against adoption, so humm.

G

A

You support adoption.

A

Hey hum, if you object to the adoption of this object to the adoption of this document,.

A

A

Alright, well we'll take it to the list, but thanks you're. Thank.

J

J

Okay, so I wanted to tell about this EAP method called EAP, noob and nimble, out-of-band authentication for EAP and what it does is it's a bootstrapping method for smart appliances. Now there are many of those, but this is an EAP method and we have worked on this for quite a couple of years and we had a version 4 of the draft. The specification starts to be pretty complete, but there's still some things to do and then to review and document about the design process.

J

So what problem does EAP noob sole? Well, it is EAP method that is intended for deploying IOT devices or appliances out of the box when they have no identifiers, no credentials and when you don't have professional system administrators doing the deployment. That's just average users and.

J

What method of authentication do we use? Well: user, assisted out-of-band authentication and, for example, in the our implementations, this has been a dynamic QR code or dynamic NFC tag and in addition to to just authenticating the device once this method also registers new devices to the authentication server. So you don't want to let the user every time you want to connect to them.

J

Let's say Wi-Fi network to redo this process, but but once and then we create a permanent association for that device, and that association then authorizes the device in the future for network connectivity and it gives that device an owner and an assigns a network to it. So it's a two-way authentication process and then trust relation that is created.

J

That is different from the current EAP methods, which require pre-registration of the peer devices.

J

So here is the protocol architecture and we have, as usual, in this case a Wi-Fi network and with an access point, and then we have these IOT appliance. That would like to join the network and we have some triple a server like radio server locally on the network. In in our use cases, we have kind of thought that the actual server that does the authentication is a remote Triple, A server, maybe in the cloud maybe on site, but is it's a separate? You know Triple A server that implements this EAP noob.

J

You out-of-band miss it's processing and the user interface for that and okay. So so what what's the point of this? Well, we use the EAP tunnel for in band or the communication with the authentication server. So that way we are actually actually the appliance is able to talk with the authentication server before it is registered on the network or register at authentication server and before it has a full net internet connectivity. So that's the main trick that we are playing here and how do we achieve this?

J

Well, the device initially uses this network access identifier loop at EAP, new dotnet, because it doesn't yet know what identifier it will have and then we're out the those I, though, that really to this special triple-a server that supports our protocol and then the out-of-band communication happens there. That's why we need this kind of special server, because it needs to have a UI or API for delivery of.

B

J

Out of nine messages, so here in the picture, there's a single out-of-band message from the from this appliance through the user to this UI. If it's, if it's manual configuration or api, if the user is using, it's a smartphone with add to a system, and so there's just single message in one single direction that has been our design goal and that message couldn't be could be in also in the server to peer direction. So we wanted to make the protocol as generic as possible and to allow both directions for this out-of-band methods.

J

Actually, the server to peer direction is easier easier to to get security and.

J

Here is then, a quick outline of the security protocol I think it's pretty obvious to now that that it will see that so, first in the band in the EAP channel, there is an this e CD aids keychains, and that is unauthenticated at this point, and then we have the out-of-band communication, which authenticates the key exchange, and we have two ways of authenticating that the first one is a hat, including this outer band message, which is just a hash of this e CD H parameters and prevents many in the middle attacks are impersonation attacks on that.

J

The receiver of that message can verify that part of the of the methods and then, after that, the ski conformation, and for that we have another part in this out-of-band message, which is a secret nonce, and so these are the hoop and noob and there's that secret knowns will be used in the key confirmation step for computing max and, and that gives a second method of authentication.

J

So these are kind of redundant methods about in the case and but but I'll explain soon why we have both- and here it's just the names of the methods is in the spec. So there is the initial exchange. There is the outer pan step and then the completion exchange.

J

Well, this this is the protocol that takes place when you register the device and then in the future there will be the persistent Association that is created here in the key after the key confirmation and then reconnect to the network.

J

Rekeying happens with this reconnect exchange which may use non C's or for forward secrecy, also easy the ID keys, and that means the user assisted step will not be repeated as long as the this device stays stays registered and it will stay until the user, resets the casillas and either at the server or the device end or actually has to do it at both ends.

J

Okay, so wait has to see what kind of security do we get here? Where does the security come from? Well, we had this one. We wanted to have a like minimal assumptions in the protocol on the out-of-band methods, and so it's just one message in either direction from server to pierre-pierre server, and we assume that the autopen channel will provide either integrity or secrecy, but we don't require both.

J

But of course we it's I would say it's better to have both, but if you think of let's say you're scanning a QR code, someone could be spying on that QR code, so it might not be so securely secret and then it's the only the integrity that remains the protector security. So it's kind of for failure fail safety.

J

We want to have these two assumptions: secrecy and integrity of the outer band jungle there's some three key case where, where them so, when there is no secrecy for that mess, it's just one message: it's almost in a flop, but not quite enough, so the user needs to, in some cases, detect the failure of one end to associate and then go and reset the other end in and and so that's a little bit more than just one message.

J

Well, another concern that we have had in the last year. We've spent a lot of time on modeling this protocol and and verifying its properties and then the main concern we had was this denial of service attacks by someone a man-in-the-middle attack, err on the network on the inbound channel like on the wireless network, who could call maybe they could cause persistent failure of the protocol and and I hope. It's not I, feel so powerless.

J

Okay, so that man in the middle attacker, especially it could temper messages or it could drop messages, or maybe it could prove error, messages and use that for causing din our service and and we we can't avoid that. But but we want to avoid persistent in our service. If the attacker then goes away.

J

So here is a use case to get an idea. What is this useful for so secure boot? Stepping of cloud manage displays- and this was our initial use case- that motivated the work. So here is a comic-strip there. There is alice with attaching displays to the wall. Powers are one of those new displays. The display doesn't know where it is it scans. The wireless networks looks for support for EAP noob when he finds that kind of network it connects to that network.

J

There happens to be just one in this case and and the initial exchange for the protocol happens in the background it gets a QR code. They said this is the out of hand message now: the QR code shown to the to Alice and Alice scans, the QR code, with a smartphone which may or may not have an app, so it just needs to be capable of scanning QR codes and a web browser will be then open, but but it's kind of there's all kinds of tricks against the user facing type attacks.

J

So it would be a little bit better if there is an app, but it's not required, and then the user has to either be already logged in on the cloud server or or will enter the login credentials, and that magically attacks is the device to the cloud service and and then enables network access, because the cloud service, now the remote a triple a server and and now the display starts in our implementation. Then start. It's also gets this application layer configuration and starts displaying some content.

J

So so, to recap this use case: there's a new display device with no owner no domain, no credentials for either cloud or Wi-Fi, and in one step of scanning the QR code, we managed to register the display device to the cloud, get Wi-Fi access, link the device to a user account on that cloud server, and we also managed to export URL and key for application layer bootstrapping off of that, whatever the device is supposed to do like display some web content and the display device here was output, the router will be message as a URL encode it into a QR code, but the display device has no input, so that has been kind of our idea that well you have to be able to reset it in some cases if it doesn't start, but but apart from reset button, it doesn't need to have any input.

J

Just just a display obviously has output and the user has the smart smartphone and then what we need to have in the background is that the remote Triple A server is configured with that. Well, the local police trust it for authentication. This EAP noob not met any eyes and and also in this case, the the multiplayer server is integrated with the application level display man, it's been serviced, and here this still shows the same comic. With the protocol steps like the initial exchange with EC the AIDS happens.

J

In the background, then the outer band message is shown, the user scans it it's delivered as through the URL to the cloud server the. If it's a web browser. The user here needs to check that it's the correct cloud server that that she has an account to and then log in, and then there is the final key confirmation that happens and again in the inbound channel without the user noticing anything.

J

So now I have a long list of of some kind of design, details and issues here and selected, some that that might be of interest. So maybe the the obvious thing is to say what is in the outer plan message. Well, there is an identifier for the period.

J

That's a server allocated identifier that just helps the server to to know with which messages it belongs to which peer, and then there is the two two fields noob and hub, and the noob is the secret knowns and Huub is the has of the ECD age parameters they can all. This can be encoded, for example, and any respect week, so an example how to encode it as a URL and that's a important thing to know that is a dynamic URL, so it will change for every after every initial exchange. It will change.

J

So let's say: if it's a display, you configure it might change every minute or so, and so it can't be a printed QR code. It's a dynamic, QR code or dynamic NFC tag and in this noob is the part that requires confidentiality and hope. The part that needs integrity- and one of those is enough to get say, I get security here.

J

Well, when we create, we create this persistent user association. So we don't want to repeat this authentication, and this is kind of one place where the the method differs from typical EAP methods that you have some method of authentication and you keep repeating that. But we can't do that. We can't trouble the user every time the the device gets disconnected from the wireless network. So we must create a persistent Association and then, basically, at all cost avoid returning that out-of-band step and authenticate with this association that was created.

J

We are allocate we need to allocate some identifiers to the peer that is not necessarily visible to the user at all, but within the protocol that Pierre Mars now for this, this persistent Association, it must be given an identifier and when we assign identifiers, we need to think about things like identifier squating.

J

So we can believe any identifier that Pierre gives us, or we shouldn't choose identifier, that the attacker can can somehow steal from us and use and prevent Pierre from associating, and the way this has been sold here is that the Pierre starts initially in the initial exchange as anonymous, and then the server allocates an identifier to that Pierre and allocates one in every initial exchange and then eventually one of those initial exchange.

J

This succeeds and usually the first one, obviously, but but if there's something goes wrong, we may repeat it several times and then that identifier died of this. That leads to the successful hoby step and and completion then remains the peers identifier for that server.

J

The device can additionally send in this protocol as there's a peering fulfill. It can send some other information about its capabilities. Like its brand and type and so on, but that information is something that is authenticated in the sense that it is sent by that specific device. But it's not authenticated in the sense that user has to verify that that the device itself is not lying English. If you don't trust or all your IOT device, it's not to lie. So if the device stays I, don't have a camera, it might still have a camera.

J

Unless you, you really look at it, whether it has a camera and maybe some cryptographic assertions could help in this kind of case, to check what capabilities it has.

J

Well, the Association we obviously in the use case. We used it for bootstrapping application security, so that method can export keys to the application layer, and we also have used it to convey initial application layer configuration to the peer. Although I now realized this during this meeting that that we actually need to clarify how to do that and then maybe make it clear in the spec.

J

And if you compare this with I mean to me it's essential that we bootstrap the application security with the same step, because that was our in this celebrate that when we configure these devices like this place, you often have to first enter wireless credentials, tediously to to a IOT device and then configure some cloud credentials for connecting it to the cloud picture. They have network access and then the cloud connection, and if we skip one step here, then we are kind of only halfway through roaming.

J

Support is something that was in a previous ITF meeting that I attended, suggested by the Eddie Rome people, and- and we certainly can do that, so that device is configured in your home.

B

J

We have added this option for the server to send a list of SSID so that in a distant or instead of the SSID, where you currently configure the device, you know that you're persistent association will be valid also on this other edge society. It's so, for example, if I configure the device on my University Network, then it would store the the association would also be valid for Eddie, and the server's can allocate a real them for this purpose for the device.

J

The wireless network selection here has has kind of troubled us a lot because we thought about the displays that should not have any user interface at all. So we didn't want to select.

J

So if you, if you have a one button on the display that you can use for selecting the SSID to which you connect it, that's that solves the problem, and most implementations probably would do this, but it is actually possible also for the peer device tool to scan the wireless networks for one that implements the AP noob and way the server supports it and then perform the initial exchange and then just whichever server first completes the exchange with that peer.

J

Then winds, ownership of that device and then peer connects to its net to that wireless network.

J

The one thing that we have had to give a lot of thought to is this possibility of multiple out-of-band messages being in flight at the same time, and there are several cases where this may happen, so they could be just at if it's a display that and there's code changes, every minute user may just scan two different codes or if it's a printer that prints those coast codes.

J

That says it's a things like those papers just lie around and there's lots of them around, and one of them eventually gets delivered to the to the server and another case where you have multiple messages in flight. Is that the the we support both directions peer to server and server, appear for the out-of-band methods and and never thought that that anyone would want to support both directions? But then, out with when you think about it, someone might be crazy enough to implement the device that allows both directions, that the protocol allows both directions.

J

Fir'd normally would think like output device, outputs, outputs, a code and an input device inputs, a code, but but sometimes the device might be able to do both. And the protocol supports that case as well.

J

And then, as I mentioned in the previous slide, there could be multiple users delivering other men messages to different servers and and with with behind different wireless networks and and they compete for the device. And we've worked out these different cases of multiple messages in flight and verify this to check that that there is no no deadlocks caused by by these.

J

Another kind of for what has been quite interesting for me as a security researcher to think about is this crypto suit upgrade issue, so that is that is of course, an event that happens very rarely.

J

But since we we decided that we don't want to bother the user to redo them out of pen step again, in any case where we can avoid it. We wouldn't want to bother the user even when the crypto suit needs to be updated and the so the normal solution. When you update, let's say signature, the crypto algorithm for signature, keys for someone's credit and so see also is your new certificate and that's a kind of administrative process and a human.

J

You is involved in that or some some another layer level of credentials for deploying it, but we don't want to do that. So we want that's why, in the reconnect exchange, may negotiate a new crypto suit and update the persistent Association keys, but this leads us to the really interesting stuff where the crypto, so that update might fail, but it might fail so that it fails for one end and succeeds for the other end.

J

So the issue here is still, if the, if you are doing a crypto suit, upgrade in the reconnect exchange and then the last message, which will be the final EAP response that is, dropped. The pier will move to the new crypto suit because it thinks all is ok. But the server will never receive that final message and it will keep the old cryptic and.

J

That is kind of an unavoidable problem in a distributed system that you can never reach this consensus about. Are we in the new crypto suit or not? There is not guarantee can't. You know.

J

We can't design a protocol that is guaranteed to reach such consensus if, if the messages may be lost but but the way we solve, this is kind of make the peer responsible for the upgrade and the server just moves the new one and when, whenever it you know, if it gets the final mess, it's if it doesn't get the final message, it stays in the old one and the peer is willing to roll back to the old one until it receives a confirmation that the up server also has been the upgrade for that association.

J

And when does it get that confirmation? Well, the next time it does rekeying. So if it, if the, if they, if the synchronization failure happens. Obviously the peer cannot connect to the to this network, and then it tries immediately to reconnect and that's when either they will. The peer will discover the servers in the previous crypto, so it or it is in the new one, and then it only keeps that one and there, although all the attacker can do, is it can again drop the final message and then it's the.

J

But if the attacker eventually goes away, then the upgrade will succeed.

J

But this was kind of fun thing to to model how this process works.

J

One note about the isolating the peer devices, so the so, if you think of devices that connect to connect to this wireless network and and you you, let users configure new devices and connect them to the network. Well, they might connect all kinds of devices to it and especially like any out-of-the-box device that supports EAP new band and buy it from the shop and and just that, that's it to your local network.

J

Also, we in some in our use cases we delegate the control over this network access to some cloud server which may be provided by a third party. So if it's not your own own remote authentication server, but but some external service, then yeah kind of trusting access to your wireless network to them and obviously corrupt devices. Iot devices might leak the network credentials I'll.

J

Let anyone on your wireless network, so we think that it's quite quite very important to isolate these devices to a virtual LAN and that so that they don't get in touch with your regular hosts on the network, preferably isolate them from each other as well. But the current access points and and radio servers don't really support that speed source as far as I know, but we've managed to implement it on on open, open source radios and open wrt access points.

J

Well, this is the this is not something we can solve in our protocol and- and it applies to all kinds of IOT stuff, but but I just thought it's something to keep in mind, because it's probably like that one of the big security weaknesses of doing such device associations for software requirements, I just want to point out that the implementation is now on this remote remote, Triple, A server and on the IOT device.

J

We have implemented those in UNIX, hostapd and WPA supplicant, but access points don't need any changes and the local triple-a server only to only need some minor configuration changes that is routing these specific requests to the remote server.

J

Maybe I skip the to-do list, it's just some. What we need to do next and then summary of kind of well. What was the solution? What is it that? What was it that I talked about? Well, why would we all they would use EAP for bootstrapping devices?

J

Well, the trick here is that the EAP allows us to do the inbound communication with the north indication server in the back in the network internet or on your back in network before you have network connectivity, and thanks to that, the autopen communication can be one short message and in any, if you don't use, have this kind of. If you don't use the EAP tunnel, you usually have to communicate much more information and then the out-of-band messages in our protocol is designed so that it should should get either.

J

The outer band channel should provide either secrecy or integrity, but but if one fails we are still ok and then kind of you can ask like we get this magic attachment to the network with with just scanning one QR code. But what's the cost here and of course one thing is that we need EAP and and Triple A, and that means WPA enterprise, so not passphrase networks and then the main thing is that the network had been has to choose ones.

J

That's authentication server, so the network administrator makes this choice for you and in this one network you can attach devices to one authentication, server.

J

There's some comparison to other methods: I won't go through these, but I'll use this slide to answer questions. If someone points out these questions about comparison and there's a link to the draft and then finally, what why am I presenting it at the email working group?

J

Well, the we we don't have a working group that would be suitable for this draft at the moment and I would like hope that if the mo is recharter, then maybe considering included EAP noob in that charter and also it would be nice if we can use the working group kitten and further editing the draft and the issue tracker, so that it would be a little bit more public and we could get external contributions to it.

J

Okay, that's all questions.

F

Hi great presentation, I could almost borrow all of your slides, except for a handful for the next one, but I won't that I think. Actually we have a there's a side. Meeting I told you about tomorrow. 6:00 p.m. it's on the side.

F

Meetings, wiki and I want to look to address like there's a series of IOT onboarding work, that's going on across the organization and and so I want us to get our hands around all of it, but I would definitely support if it's possible to use the EMU working group wiki to track issues here with us and I look forward to working with you to try and find the common architectural components on these. Okay.

A

I don't know if we can use the email working group working at this point- cuz they're not working with group items, but there should be some way to do that somewhere.

K

Eric nor mine yeah- this is very interesting and I. Ain't think I have other use cases from the output devices, just an LED that can blink, but you can have your phone receive that stuff. Somehow one question I had was so, can you do mutual authentication? Can you authenticate to place or wear this as well as long as the device has some credentials? It knows.

K

It's gonna talk to you, whatever ap new, whatever right, if it had, you start something that already exists in the software you have CNA, which connect can the device did be authenticate the Triple A server? Yes,.

J

So it is mutual authentication. The device is authenticated as a physical device. It's the autumn. Identity of the of the device is defined by which device where the user reads or writes the out-of-band mess. It's it's a physical device that the user accesses turn that part, but the tree server as well people a server. So here the user is assumed to have some way or secure channels that he plays, or it could be, of course, physically if it's a home network and some device hub at home.

J

But in my our implementations it is the remote a server in the cloud where the user has a user account or user uses their organizational account. Sure.

B

J

Into that online server and then the device is not only associated with that specific Triple A server, but with the users user name and that's.

K

The exchange between my cell phone or whatever I, used to scan the qr-code understand that part I'm talking about niche EAP exchange, whether that offers mutual authentication.

J

In this case, yes, so this is this fact that the user has this secure channel to the Triple A server. It does authenticate the Triple A server to the device, so basically the device in our use cases they take takes that.

L

To follow up on that because I'm with him, you mentioned on one of your slides that if you don't know which a server to talk to you just talk to them all yeah now that is conserved now what QR code do you present at that point? Because you have you, have three you've got two evil triple a's that you're talking to and the real triple a and just h1.

B

Do you presume you know I, understand fully.

L

That the user is going to go to you know my company, that I trust and and paste in that QR code and that's great because that then the guy, then the peer knows which one of those three it was because, but still, how does he present then?.

J

It'll play well, the display shows them so these three codes and if the user somehow is trick to choosing the wrong one, then it doesn't really do anything. Well, there's no baby, because he because it's the correct server that you're delivering it that's the important thing, but but I mean this will have the the cure code has. But in our case we write the text there. The base URL under the QR code right.

L

J

See the display our display would rotate two or three cure calls with the base URL under it. You choose the one you recognize I.

A

Think we should probably move on to the next is a quick question. I.

M

Have a quick question: I love this idea very much and very fortress process for users, and is there any requirements for like IOT vendors to develop in the device? The device itself like just display the QR code, yeah.

J

So the implementation, it's it's, it would be the sort of like we have implemented the Linux WPA supplicant. So it's the EAP supplicants, I module, but actually you're, pointing out to the tricky part of the implementation.

N

J

Is integrating the EAP by.

N

Layer layer with.

F

But you haven't been abducted, hi Elliot, your last meeting Owen presented on something that we've been tossing around, which is to take the brewski work. That's been done, the bootstrapping key infrastructure work and apply it into eat so problem statement. It was pointed out that maybe we didn't do as good a job on a problem statement as we should have in the previous presentation. So these are basically a couple of reasons why we went there and I'll set this through in just a handful of slides. This is a very short presentation.

F

The the key issue is that we need a trusted introduction between a device and local deployment, absent that trust. An introduction device is going to join the wrong network or they make it they may do so either out of incompetence or malice depending and I. Think everybody in this room understands that problem.

F

Brueski provides for a truss city introduction and it's a certificate based method at this point, and it also relies on a third party, which is to say the manufacturer you go out to the internet. Manufacturer says I, you know, device has got a I'll, explain the flow in a minute. Actually so I'll go through it once you have a trust anchor in brewski, you go and you do an EST transaction. You got yourself a local deployment cert and both of these mechanisms assumes some amount of network on ik TV. Really it's internet kind of really.

F

That's not only network connectivity via never conductivity of the device, but it's also internet connectivity as it turns out in terms of brewski, and you just don't have the network connectivity in 802 11. Obviously it's a you have a chicken-and-egg problem there, and so of course, we looked at eat for the exact same reasons that the new folks looked at eat.

F

We thought was pretty cool and for the exact same reasons- and in fact we thought t p-- was even cooler because it covers a fair amount of this ground already and it just needs a little bit of tweaking keep tweaking. So here's an eye here, here's an eye chart for you. This is actually on the materials page units. Look at this.

F

This is the basic anima flow, where you establish what we called provisional trust, it's directly analogous to what noob does in many respects and what you do is you go through in a transaction in which you go where essentially, the local deployment, which is the switch and the registrar? Really the registrar, goes and asks the manufacturer? Is this one of your devices, the manufacturer would say yeah it is or no it's not, and it's essentially sign a voucher request, which you know then gets returned as a voucher which the pledge can then use to say.

F

Yes, okay, I should join this network and here are the credentials for that network, and then you go through and EST transaction again yeah. This problem, which all that was IP based s--, worked on an anima group, and so we have a little problem there. If you don't have IP connectivity yet so, what's the idea shove the whole thing into each flow?

F

I am NOT going to go through the Holi flow. Today you can read the draft, but the basic idea is that we're you know we're leveraging eat. Teep we've created just a handful of new TLDs that one would use to do this and the differences between this version and last version is that we've created it even a handful less than we thought we needed in this version and so we're trimming down, and so we, the the other.

F

The other difference is that we actually documented out all the tlvs that we think we need and I added a Ayanna considerations to match the the flows themselves have been updated because in the process of defining anity, all these that's how we found out you can piggyback messages and Eve. Isn't that so lovely? So, let's condense here and here here we have, and so obviously, if you look at the security sick, you know consideration section, it says TBD.

G

F

Means we're nowhere near ready for adoption, we're working group adoption we're just we're just not there yet, and we think there are some in the process of doing this draft and there possibly and also the process of looking at new and in the process of looking at DPP as well. Actually, we think we've come across what we see as some architectural questions, and so one of those is that there there seems to be.

F

We see challenges around the sorts of deployments that need to be accommodated in terms of credentials that they're comfortable using versus the capabilities of the device in terms of the credentials that they can support, and so in the process of going through.

F

All of this I've attempted to to identify a few architectural building blocks and I'm only going to tease you by saying that I've done that, but I'm going to present it in office area working group and then I want to talk about it at a side meeting directly afterwards, tomorrow night at six o'clock, it's on the side, meetings, wiki, and so at this point in time.

F

We're not asking for working group adoption for one thing: I would like to look across the five or six different working groups at this organization and then five or six organizations that are looking at this entire problem. We're seeing fragmentation because of this and to just take a step back for a moment, pause, take a breath and say what are the common architectural components?

F

What can we do to to maybe reuse some of those architectural components as we evolved all these mechanisms into the future, so this is more of an advertisement than than than anything else. Please come to the ops area working group tomorrow. Let's have a bit of a discussion there about this.

F

I've got about a half hour to talk about all of this I'll try and speed talk a little bit even in that, so that we have more time for discussion and less time for Elliott blabbing on and then please come to the side meeting tomorrow evening. It's an apartment. Three. On the ninth floor, we only have a 12 person room, but that's okay, I figure. If 100 people show up we'll just switch rooms with someone or have the meeting in the hallway, like we usually do, that's it questions comments.

A

Danny may speak.

A

O

Harkins thanks Elliot I have a few questions after reading this, so does the device need to respond to the eep identity requests with any sort of adornment to route it back to the right teep server, or is it just assumed that there's always one teep server for every Authenticator.

F

We haven't even that's it's an issue that you've just raised, and the draft hasn't even gotten that far okay, but it's a fair question and I see no reason to adopt the exact same. That's the method, for instance, that the new people used. Okay, in fact, I like that idea, can I steal it.

O

Yusef, just provisional TLS connection and that's going to be completely unauthentic ated, so it doesn't provide any security over just sending the the brewski voucher request and getting a voucher response in the clear right. So it why? Don't you just make instead of hacking? Teep just make a brewski and send a voucher request to get a budget response or in Arabic Oh. So.

F

Essentially, brueski does the exact same thing and what the way that the provisional thing works is that you, the the what you have to do, is by the end of the transaction. You have to have been able to authenticate the beginning that you have to have been able to authenticate the credentials that were used in the in the beginning. If you, if at the end of the brewski transaction you could not have you have not received the appropriate trust anchor, then then you throw away.

F

The whole transaction is the is the way that that it was, but.

O

If you're gonna be doing brewski after you get your voucher back anyway, then no.

F

No, that was one of verifying.

O

The your previous provisional.

F

So the way that I I will go through the flow if we have a few moments: okay, so the basic idea here. So the basic idea here is you start with.

B

F

Pointer on the sky, so there is okay, so essentially so here's where you into your provisional trust state right! Yes, okay- and at this point we you at this point. You have no reason to trust, which is why you're in that provisional trust phase. In fact, that's a really good signal that that says, I need more trust. Let me go. Do some brewski or something like that, and so you end up doing a request. Voucher I think we might even be able to nuke that guy, but I'm not sure.

F

You you end up doing this request voucher. Then you get a then you get a response at this point in time. You should be able to have validated the the server hello if you're the client right, at which point you're no longer in provisional trust mode. So I won't claim to be the perfect expert on this trust model. That's the work of Max, Pritikin and and Kent and Michael Richardson, but I'm, essentially, borrowing that model wholesale. So.

O

What would happen if you just did brewski vote request, voucher but request for voucher and then brueski voucher, the bottom, if we just did this part here, no just the bottom, two right, three, four there's three and four: these.

F

These guys three.

O

F

So we're relying we're I think we're lying on the confidentiality properties here, at least in again, in a in a provisional way until we get back the cert and if we don't, if we don't have, if we don't have a confidentiality, we're gonna need some other mechanism for that. Okay,.

O

But you're still systems like a man and middle attack, so you're confidentiality is until and you I.

F

Mean you don't have the proof of the content that that that you haven't been men in the middle until you get the the the the trust anchor once you've got the trust anchor, then you know you haven't been mantled. I've got a couple more questions.

H

N

Was just a clarification, the provisional sanitation part is actually only on the client side, so the server side is actually assuming we brewski assumes. The server side can actually has the trust anchor. He needs to validate the device. So it's just a device ID.

N

F

H

Model is defined by animus.

O

So I some I didn't understand some of these flow diagrams because EEP sort of locks that protocol- and you have sometimes people sending the server sending two messages back like a ah these.

F

Are attributes and I mean so the idea is that those will be in the same eat message. It's.

O

Just additional TVs, yes,.

F

Don't see like TVs.

O

And then so. My final request, then, is that you're overloading like a pkcs, ten TLV and the csr attributes TLV by sending a zero length. I guess so.

O

Instead of that, could you just use the request, action, TLV and and use the action field of it to say you know like begin brewski, instead of sending an empty pkcs ten, which is kind of weird for the service, the PVC is ten in the first place, okay, zero length, it's sort of like the semantics of that are what.

F

Sure we can, we could absolutely adjust that. But let's talk because um there's a lot of room, this draft is is drafty as drafty can be even in its second iteration. So we have you know we want to tighten up some of those flows. Okay, so.

P

Max Paula Kim believes I was actually thinking about, they will trust model etc without rest anchors. It will not work because if you seek secrecy or you know of the parameter you pass in the best, you have a man-in-the-middle, you detect it afterward. The secret is no.

F

P

Confidentiality is already compromised, so so.

F

I'm gonna refer you right back into the anima draft, which goes into great detail about all of the security considerations of the mechanism. Okay,.

G

Well, I think we are almost out of time so I'm asking this question: could the chair as an author? It should be fine to use get even for individual drafts. We don't have any strict policy on that. I.

A

Mean I, don't know we should discuss, I mean I would prefer to keep the archit account for our. You know for official working group items, and then you know I mean it's easy to create a good account weekend hub account right and so.

F

I plan to take this up in you know separate context, so I think there's an it's important, that the new draft have a place to do that, and also this one as well. If it's not with you guys, then we'll sort that, with the you know, I'll talk to some of the iesg members to see if we can find the right place and I'm willing to discuss that too. It's yes, you know this is a solvable problem. I wouldn't worry, I'm, quite certain. We can solve this one, all right, that's it for now!

F

So don't look for adoption any times. You know any time yet, but we want to have this architectural discussion. Please please join it. So it's.

P

Just one more question about you know the adoption we saw they several proposals right going, the same direction. We had some messages from the last meeting, helped.

G

Us ship the existing items, review epls, W, eBay K. Once they are shipped, we will have space for each artery.

I

P

We'll have to wait until those items are. Oh, you.

G

Can be very fast if you review them tomorrow, you know we can move this.