Okay. Since we have a quorum, let's go ahead and I'll call the meeting to order and we'll start with the, is there anything you need to do, Nicole, before we get rocking? No.  We're recording the meeting, so it'll be uploaded as soon as we can within the next couple of days to YouTube and Longmont Public Media. Thank you, Steph, for helping out again tonight. There's Anne, so we'll continue to monitor the waiting room you guys and let people in. So if you need anything, just holler. Okay. All yours. Thank you. Okay. The meeting has been called to order, and is there any public to be heard? No. There is no public to be heard. Thank you. Then let's go ahead and move on to approving the minutes for both the August 13th, 2020 meeting and the September 3rd, 2020 meeting. Is there a motion to approve those minutes? So moved. Thank you, Jake. Second. Anne raises her hand. Anne is seconding. Second. Any questions, corrections, anything like that? Yes, Graham. I had a question about, let's see, what is it? It's the motion that passed at the end of last meeting, where we approved adding a question to the agency applications about equity. That part I recall very vividly and this seems accurate. The part I'm not clear about which I would ask the board to verify for me is the adding equity goal area under the self-sufficiency and resilience priority area. That struck me as maybe a little bit different than what we were talking about. I thought we were saying adding an equity goal under each of the priority areas, not just the self-sufficiency. My recollection is that we were going to add the bolder equity area to self-sufficiency and not one individual. I thought, but that's my recollection. Anne, do you recall what the intention? I thought it was also under each area we were going to ask what they were doing to to support equity. We've got a split decision on the board right now. Anybody else have a recollection? Caitlin and then Jake. I think there were two different things we talked about and I think this is what Graham is thinking of as we talked about adding a separate bucket for equity. We also talked about adding a separate bucket under each of the categories. I think what we ended up deciding was to add that bolder question that Ellie Berto said there were those two areas where we were not allowing people to specify those in their application. We wanted to add a question to the application about how they would deliver it or multiple questions around that staff were going to research the best way to ask them how they were going to do that. That was separate from the question of the different buckets. We talked about that list of 14 areas. I think we did 14 out of 16 and we said we should add the other two that bolder also does. Jake. Yeah, that's roughly my recollection, Mr. Chair, as well, is that we had the long conversation about adding the bucket. We ultimately came to a split decision about that vote failed and what we decided to do was to add the equity issue to each individual bucket to use that term to each individual area and then to take the bolder question as well. But I think the intention of the board was to ensure that equity is measured in each one of our different areas. I think was the intention. Good catch, Graham. Okay. Any other feedback on that? And I noticed you had unmuted and then I spoke over you. No, it's fine. Okay. I don't actually remember, so I'm trusting Jake to be honest. Okay, so it sounds like the intention is different than what was captured in the minutes. I'm not sure. I looked to some direction on how to best reconcile this. We can amend the minutes and then approve them at the next meeting or we could have a motion to approve them with amended language. It's I'd rather not do that because I think it's confusing enough everything that we just walked through that probably the specific language is really going to matter. Ella Berto, do you have a sense of what might work best or Karen? So, I would say that if, when you look at the motion that we think we passed, so maybe we just clarify where there is confusion or so that we can figure out how to change it because I think it's probably best to make the changes to the minutes and adopt the approved amendments. It's probably the easiest way to do that. The longer we wait, the fuzzier we get. So it seems like that in looking at that particular set of minutes that it sounds like the first part of that is correct that we accept Ella Berto's suggestion of adding the equity goal area under self-sufficiency and resiliency priority. So that was, that was the bolder, the bolder option. Does that make sense? Yes. And then adding an equity question to the application which is what we really brought back tonight which we understood would be that instead of just having an area where we address equity that we include that in the application so that that we were looking at how they are providing all of their programs and services in an equitable manner. So I think we are aligned with the intent but maybe we didn't capture it in the minutes in the way that that is clear. Well, I would offer that. Maybe it is clear, I don't know. Perhaps we left, it might be okay that it's not precise because I think we are going to discuss that tonight and tonight we can give more specific direction to which you know that it's included it for instance in all the priority areas and it shall be included in this what you know. I think what we said is that we wanted someone to be able to apply for you know if what their program is doing is about equity that they can apply for that and what we said is this and there's an existing goal in under self-sufficiency and resiliency which is what the city of Boulder uses so that so I think as an example so if El Comite wanted to or Intercombeo or someone because that's kind of their purpose that they would have they would have an area in which to mark and say this is what our program addresses is this particular goal area so I think we said that was already in the application and that made sense and then what we wanted to bring back tonight was what kind of equity questions we want to include in the application so that we so that we're looking at how agencies are addressing equity in a more broad kind of across all aspects of their operation so I think that's really what we're going to bring back and talk about tonight. Okay Caitlin. I would just add I think as I'm reading the minutes and hearing what Karen is saying we said to add those two things from the Boulder area I don't think that I realized from the slides that we were looking at that those fell under self-sufficiency that they were part of that goal area which may be where the confusion is coming because they were it was like 14 goal areas but they weren't necessarily subdivided into our like big buckets I don't really have I mean we can talk about whether we want to change that I don't think I made the connection that it was that those were going to be subdivided and that this would be under that so maybe that is where the so the minutes are actually more precise than what we were talking about versus less precise which is fine I think that's so I'll just add that that was where my confusion oh hearing that helped identify that that's where I would be confused on it. Okay good too. Alberto. So just as a reminder the goal areas are what are the drop-down goals that the agencies can choose from on the program level of the application then the self-sufficiency is really the back end or back office for lack of a better word a bucket where we have categorized these goal areas that that's the relationship that exists between the two. Okay so the question related to the minutes really comes down to is the motion as it's reflected here inaccurate as to the intention of what we were voting on if not then we can just accept the minutes and we can make any modifications going forward to give precision or additional direction to what we voted on last week that's my take on it. Is anybody feeling like that is not a good way to move forward? Okay Jake I think you're like the parliamentary nerd so do you have any any thoughts on that? And I mean nerd in the kindest way most respect. Yeah no I think that that makes sense as a motion Mr. Chair if you wanted to move that that would I mean well I guess you're right we don't necessarily need a motion if we're all comfortable with with that because if the language in the minutes if the goal is that we're going to specifically clarify the language in the minutes tonight then I think we can move forward safely and I think also through this conversation just informally staff has a pretty good understanding of what our intention are is and what what our goals are so yeah I think moving forward would be perfectly in order. Great yeah I don't have any concerns that we're not going to get to our desired outcome if we accept the minutes as presented. And Brian I'm not the Roberts rules nerd but you do have a motion on the floor yes we'd be accepting the minutes and then we've had discussion about that and so it sounds like you would want to move forward and and see if that motion will pass. Yep let's go ahead and vote on the motion to approve the minutes as presented all those in favor please any opposed please raise your hand okay great we can move forward then thank you everybody so Karen or Ella Bertha who's going to take us through the next steps here it is em just to mend those up okay he doesn't look like he knows that it was em no no I was wondering can um um can I share my screen Nicole I just want them to see the the document that I created um and then reference back to it so they understand where this fits all right so I'm going to share the packet um okay so what you're looking at is the minutes that we just discussed and approved then so I want to start here um so I'm going to kind of set set the groundwork and Karen you can jump in whenever and if anyone has questions I can't see everybody so just speak up because I can only see four people on my little strip right now so um so basically I took that you know I went back and I listened to the meeting and I um took that mandate to add a question to the Human Services Funding Application and I will say that it is one of the most difficult things to do because adding a one question around racial equity or equity itself is a very challenging thing to do and after some back and forth with Karen I I did draft some some options and I sent it to Karen and then we had it back and forth the way that we decided to go is um we would like to use the GAIR racial equity tool that's in your packet we want to add that to the resource center of the application and in the instructions we want to ask agencies as they are answering the questions because one of the things I noticed is that in reality a lot of the questions in that racial equity tool are similar to the questions that we ask in the application there are some similarities the biggest difference of course is that the racial equity tool has a lens of racial equity in it um and so we want to share that with the agencies and ask them to consider that to inform their answers and ask them to think beyond just racial equity and think about equity in a broader term as they're answering these questions at the same time I wanted to honor what the board had asked and so as Karen and I discussed where the question around equity in the application directly belonged we came down to adding a question to the number three target population so and unfortunately when I said to so in my when I look at my word document from the word please share that to me is in red because uh that is new that was not in the question before the question ended in the described the specific population served by the program and so I added the please share strategies the program will implement to ensure target populations are served equitably um it like again it it was a challenge to to boil down such a huge topic of equity into one question but I feel comfortable in having the agencies use the racial equity tool to inform their answers on the application as they're writing them to use that tool to help them understand the value of equity and I was going to add that to the instructions as well so that's kind of where we landed and I'd love to have feedback and discussion from the board. Thank you Eloberto. Okay feedback for Eloberto on uh I think there's two elements here one is using the government alliance on racial and equity form including that in the application uh to assist as a tool to assist applicants on evaluating the racial equity question or the equity question in general and then the second part is what do you think about the language of equity included in the application and where it is included on question three why don't we start go ahead Deanna so I was just going to say I like the language in question three that you've added I think it's nicely broad and open-ended and gives them a lot of opportunity to discuss their goals and I think my concept of the equity question was very broad as well and that we weren't limiting it to racial justice issues and that we I was contemplating you know are they equitably applied to you know the lgbtq community are they providing access to seniors people with disabilities so I was I'm happy to see that the question is open that way I think that leaves it um so that the plans or the programs can really develop that and I think providing them some guidance with the GAIR questionnaire is good as long as they don't think that the question is only about racial justice issues which is obviously huge and very important but not exclusive right and that's why my when I write the instructions I want to make sure that I make that very clear thank you yes Sam I don't know I'm just not sure if that's big enough for the question you know equitable I don't know if that can be perceived as financial or I mean I wanted to be more inclusive to other populations like race I don't know it just seems a little it is broad but I'm not sure if everyone is going to get it like if alco mette looked at that what are they going to think thanks Sam we've got Karen and then Caitlin and then councilmember christensen Nicole could you unmute oh I got I got it there you go Karen we need you to define what equitable means I would think we need like a definition what does equity what does it mean so does it mean you know everything or so it's like that's just such a broad word what does it mean exactly so that's what I'm asking okay thank you Caitlin um yeah I agree with Ann and Karen around that and one of the things I'm seeing in the the GAIR questions that might help inform that so right now we're saying the question is please describe how it will be delivered equitably and I wonder if the question in like step two number two what does it tell you about what does data tell you about existing inequities and how are you going to address root causes of that and I wonder if something that's a little more specific rather than making sure this is going to be delivered equitably asking them to talk about how the program may be addressing root causes of inequity and to describe what those inequities are so that it still leaves it open to talk about race, gender, LGBTQ issues, age, any any sort of that but really diving into like addressing the root causes of it because I think that's really what we're getting at is we want to deliver it equitably but we also want to see that folks are thinking about the root causes of some of those inequities and I think that's kind of why we were thinking that it fit under so many different things is that there are inequities in all of our different buckets so I wonder I'm just thinking that we could maybe be more specific there to get to what the inequities are that they're addressing thank you Caitlin councilmember christensen and then Jake and thank you Elevato for including this this document of the Gare document um my question is whether I because I think that having people look at this document and talking among themselves will help them focus on issues maybe that they have considered and haven't considered but at least they'll be able to convey them to us better I was wondering if they will be filling out this document or just using this as a something to inform themselves will they be turning in something like this or just using that to inform will everybody be getting this this two-page document so councilmember christensen um it'll be available to any every application applicant that applies I I didn't so I think I didn't think we were going to ask them to fill it out and send it back in for a couple of reasons one is I mean that would add extra burden to you all to if it was going to become a part of reviewing and then two you know it does add extra effort to the agency to have to fill out another document as along with all the things that we're asking already and then I think the third thing is when you actually look at the questions there are a lot of similarities um I think our questions in the applications are well thought through um and I think that they the while the Gare document definitely has some nuances around equity I think there there's still a lot of similarities that look at how well have your research how well for example there's a piece on engagement I will have you engage the clients in implementation or participants in implementation so I just think that that that the Gare document is a good tool but not necessarily a a requirement okay I understand that because you know we we're already giving them a lot of paperwork they don't need more paperwork but rather than have it available to them I would do the you know where they have to pull it out of us I would have a push thing where we give it to them so that everybody's got this so they can consider this I think Karen hit the nail on the head with the what do we how do we define equity and I think this helps people get that and and get that they don't have to go to this we're going to give it to them because we're really serious about it so I my suggestion would be to just send this along as a PDF to everybody so they get that we're not kidding we we mean it so Karen do you have a clarification on on council member Christian for this question not necessarily clarification but I think just to add so um so so Polly we did we did go back and forth about whether to um to have this be a required um to have them fill out the form you know so that we so it's ellie burton I we glad I went back and forth because we think that that gare document is probably the best one that we've seen that really helps um I mean it's it's a document that we are to be using a city of online employees for programs that we are offering to the community it's to be a guiding framework for as we are thinking about all the things that we offer in the city um how do we begin to think about you know is can everyone have access is the way that we're providing the service is how we're communicating about the service is it something is is are we doing that a way that everyone can access the service are we leaving anybody out by the way we are delivering the particular program our service so so we did go back and forth about whether we would make whether we would make this a requirement to complete that or or put that in and reference it and maybe we can reference it more strongly uh as as far as the the document itself because it it will be on the it will be in the resource center but we certainly can reference it or even send it out as a pdf if that would be helpful so we end up landing on it being a framework um and to give folks ideas because we do think that because we get we often get general answers to these the questions that we've asked in the past and and i think we do want more specific answers we do want to see evidence that folks really looked at the data and the data is informing how they are providing their service um in an equitable fashion so we went back and forth all way around as about the you know the best way to do this so we didn't rest so we are really interested in other in your feedback and what you think we really should be doing i i really don't think that we should require everybody to fill this out i've been saying just send it to them so they have it available so they don't have to hunt around for it more in their face yeah so so that they they have that everybody has it available and um they can use that to answer question number three and uh it'll be helpful to them and it'll be helpful for them to analyze things because you know not every agency some agencies are very very targeted on the people that they are going to help so inherently they are not uh broadly equitable maybe i mean they are not making sure they have got 50 things checked off they are a targeted uh they're taking care of a targeted group so they don't necessarily deal with transportation i mean all the things on this list so it doesn't make sense for everybody to have to fill out all this paperwork and in in addition it's more work for uh you and elberto and everybody else to fill out something that's not really necessary to be filled out in the first place thanks thank you jake thanks for your patience go ahead i appreciate it mr chair um i just want to circle back a little bit to katlyn's point because i think it's a great one and i really appreciate her her thoughts on this this was some of my concern in our conversation last week about the need for a separate bucket and all that and i won't re-litigate that conversation but but my concern was generally that by not doing that we make the issue a little small and we make the the way our process handles the issue a little bit small so i think that katlyn did a really good job of of getting to the point that i was going to make and i was going to ask somebody if they had wording um they could tackle kind of that specific issue that we aren't necessarily just at least for me i'm not just necessarily concerned about equitable delivery of services i want these agencies to be thinking about how their operation and how the service they provide generally impacts the equity issue so i think katlyn really got to the crux of what i was was going to mention and i would hope that she can can think about some specific wording changes uh to bring into the the question that she'd be willing to potentially move that i might be all over that so thanks mr. cure thanks jay graham um i would support that string of thought um and suggest the um step four question be slightly modified and ask what are your strategies for advancing equity in all its forms um to make it broader more inclusive um and then it has teeth in virtue of the answers uh resulting in scores which result in in the distribution of funds my concern with the question three is as worded now is it qualifies it with target population which in and of itself sort of presents this backdoor so if we say well how are you equitably serving your target population well maybe the whole issue of target population in and of itself is an expression of inequity um in that particular case and so that that language worries me um a little bit but maybe i have an overly suspicious mind i mean what what if my target population was white anglo-sex and you know heterosexual males so like then yeah we're equitably distributing services to those people like i i'm not gonna want to give you points for that even if you're really doing a good job of equitably delivering content to that target population so i i think just make it super broad uh and you know how what are your strategies for um improving equity in all its ways and in everything you do something just really broad so thanks graham go ahead albert so i like that graham um i i i think the target population though the reason that we have that is because we understand that remember this is a pretty this is a pretty broad funding base right we're funding all sorts of things so for example boulder valley women's health and who they're funding is not going to be the same that um somebody else may be funding um for example hope right they may it's a it may be a very different population and so we understand that and what we want to know is that given what the program is intended to do and who is it intended to help how is the program ensuring that within that population for example let's say that it is intended to to to work with immigrants that are learning english how is that program being equitable that it's not only spanish-speaking immigrants but how are immigrants from nipal or germany or you know so it really is about ensuring that it's a target of it is people learning english how does everyone who is learning english get served in a way that that that changes their their situation thank you alberto and and then katelyn so i think that's good but are we going to be able to ask agencies questions during this funding round so you know i think we could say to that agency do you also serve people from other countries other than just spanish-speaking population i guess i don't even know how we're going to go forward with the funding stuff are we going to do it virtually like how is all that going to work maybe i just missed out on it but if we could ask questions then it would be better thank you and katelyn um yeah so i wanted to make a suggestion i don't think i'm ready to make a motion for this but um a suggestion for a way that we can incorporate some of the some of what we're talking about so for question two it currently says program description describe the specific activities that the program will provide and the anticipated benefits that will result for the program i was thinking something along the lines of please identify what if any historical or current inequities are being addressed and how the program addresses the root causes of these inequities and then to complement that in the program evaluation adding a sentence at the end so this is number seven please also include how you will measure or evaluate the impact on the inequities identified in the program description so we tie it both into describing the program but also in a value how they will evaluate that they are meeting that objective of the program um so i mostly wanted to throw that out there to see if others have thoughts on other ways we might incorporate it or if that maybe gets a little closer to what we're trying to get folks to answer um here yeah i just know from the past that's going to be complicated for agencies especially small agencies i think it's going to be difficult for them especially agencies that don't have a lot of money which part do you mean um the second part that you were talking about the how are they going to measure that i don't know elli bevto do you have a answer to that no not necessarily but i i i think the to your point and actually what i was going to add is so a couple of things one this will probably this will be the first time that we do this and so we'll we'll probably have to extend some grace um because folks mean they may be confused and i may be answering tons of questions from agencies during that time um and then two evaluation um i think that i that it is a good question to add and so i'll give you an example i've had some great conversations with second wind fund um that does and one and i had a meeting with them and their and their board chair um and um they showed me they they're doing a good job of tracking who's using their services and um you know they had a large latino population of youth that were contemplating suicide right i think it it was a large percentage and so when i asked them i said so what when you see this what are you thinking about as far as how you deliver services as where where do you recruit therapists what does it mean for for um your thoughts on how do you support these children these youth beyond the the the sessions and so i think that that made them think i i'm not sure if they're measuring it well but we didn't we didn't go into that deep of but i hope that what these will do it is make agencies think i think there will be confusion any way you look at it this is a new topic for a lot of folks not that they haven't been working on equity issues for a long time but to put it into words is going to be new for many of the agencies um so i think we'll have to have some grace and at the same time you know i don't know who said it but yeah we do mean business about this and we want you to think about it uh even if we do extend grace and thank you for that alberto and i i share your uh your recognition that this is a new track and we're going to learn a lot you know we're probably going to learn 60 of what we wish we would have known in the first year and then have incremental improvements over the rest of the time um so we i we know that perfection is not what we're going to get no matter how much we want it uh i do just want to say i share grams thought on the idea of the semantics of target population and so i wonder if in question three target population where we say describe the specific population served by the program if maybe that's not a place to say somehow tease out the question of um how did you know how do you evaluate your target through the lens of equity so for instance if if grams program came back with i'm targeting a 56 year old uh white angle sacks and mail that lives on carolina street in longmont uh which if there's a big check you know we can talk about uh might apply but that that would not he'd have a hard time answering through the lens of equity how he defined his population so that's just i don't have a solution to the thought but councilmember christensen um i do think it's important i i think maybe the the term target population is kind of weird and implies that i mean i i see what graham is saying here it's sort of implies that um i think it's an odd term to be using but i i do but it is true that um maybe we could use a different term um we fund as eleberto said we fund such a variety of groups and they do have a population that they're going to serve that is not necessarily um well these are agencies they are not businesses they don't go out and drum up services they don't go out and drum up business because you know people come to them because they need help they don't go out and try to find people who need help and different groups different cultures different groups have very different ways of asking for help most people don't ask for help we know this from surveys that have been done about one out of people one out of eight people we did a survey um with housing and human services a few years ago that's that uh or caron did a survey i'm not sure what was through this um one out of eight people who are eligible for services applies the rest don't apply because most americans of all groups have been taught that it's weak to ask for help that it's shameful to ask for help it's shameful to need help so in many ways um you're not getting it an overview of the culture of of america anyway you're asking getting people who really are i think quite desperate for help or they wouldn't be asking for help in the first place and so to try to put a layer of um expecting it to be equally distributed is a little odd if you see what i mean in that um i come from a long line of farmers we never ask for help no matter how far down we get there are a lot of cultures where for instance um a lot of very traditional cultures would never ask for help with their elderly because they would feel ashamed that they couldn't take care of their parents and yet there are elderly people who need care and uh their their kids can't take care of them the way they need to be taken care of and yet they won't ask for help so i do think it's important for us to keep in mind that um these are agencies that are not businesses they're not going out and drumming up business so to expect them to have an absolutely equal distribution of um different races different cultures different genders different religions is a lot but we want them to try we want them to really think about this and be sure that they are trying that they're not discriminating against anybody and that they are actually trying to find people who need help and um it is difficult to figure out how uh how to do this and be fair to them and be you know given that not everybody asks for help even though they desperately need it sorry thank you paulie ann and then katelyn karen did you raise your hand okay and i think we just need to move on on this because i think we can get bogged down a lot on this and i think i really trust ali berto to come up with a question that will make sense and i think his question is good but just a little bit more teeth in it um if you can just do something with a little bit more ali berto but i trust that you can do that and then i think we should just move on okay thank you and katelyn i definitely hear the need to to move on i want to i think something that councilwoman christianson said there at the end is that these organizations um they're not businesses they're not going out and recruiting but these types of questions point to things that are structural inequities in terms of how services are delivered so if for example um you know i just think about the large spanish-speaking population in longmont and if an organization is targeting for example um low income or children but they are way out of whack comparatively to longmont's population in terms of spanish speakers that are served by it that points to a potential issue and how they are delivering that program if they're not providing spanish translation services they're not provide you know and i don't necessarily expect that every organization is going to do everything but if you know if we have a whole bunch of agencies that are primarily serving um you know the white anglo-saxon you know population because they don't have the structural pieces to support a large percentage of our population then that's a problem and so i think the idea of these questions is really to get folks thinking about you know is is your target population or are the demographics of who you're serving really the full demographics of who could be served based on what you say your program goals are um you know if you say your program goals are to serve you know low-income children but then the only low-income children you're hitting is you know such a small percentage and it's very racially or ethnically or language you know skewed compared to the population there might be something that needs to be improved in terms of that program delivery to make sure it's getting to the folks who need it even you know there's cultural things there may be ways that they're thinking about it so um i think that it's really important to ask the questions to get folks thinking about it this is the first year no one's going to get a perfect i don't think anyone is expecting perfection i think it's really just to start these conversations and to get folks thinking about how both the agencies and we and the city can be thinking about these um deeper questions of how how we make sure that the right folks are getting access to services thank you kaitlyn karen so um in the spirit of and's urging um you know it seems like what what i have heard is that um generally there has been a suggestion to modify questions two four and seven um so kaitlyn had some specific language for questions two and seven i think graham threw out some general question general suggestion for item number four question number four um and that we not try to just have in that we actually keep the target population question as it as it was as and and not put the share the strategies for equitable equity serving the target population so it sounded like we want to have more equity questions or equity follow-up in questions two four and seven and that we also take a stab at defining what we mean by equity in kind of in that overview and that we have the the GAIR framework documents available for agencies to really reference and get some more ideas about the the framework so that's kind of what i heard people i heard your board members really um you know talk about thank you um one comment and then a question the only thing that occurred to me is on question three you know i think what's challenging with target population is it is a relatively accurate term because we think of it in terms of needs agencies target populations of specific needs and so typically we don't think about it in terms of race ethnicity gender so i was almost wondering if really that second part of that question wouldn't be something more like please share strategies the program will implement to ensure target populations are served regardless of race ethnicity and gender or something like that right really just calling it out okay i that is not a point for discussion i just wanted to throw that out there um is in terms of what you Karen and Ella Berto are wanting from us in this meeting is the guidance Karen that you're hearing adequate do you need a decision or what do you need so i'll go first and all that Karen so what i would need i mean i actually agree with with Karen i think um the suggested verbiage that was suggested by Graham and Caitlin are is helpful um i would just need that verbiage so that i could put it into the application i think those questions with the understanding that folks are not going to get it perfect um i'm fine adding those questions to you know to the to or adding those additions to those questions i just need the verbiage um and i would imagine um so either we could have well i think we've captured it in the recording you know so Nicole can weigh in on whether so so i think we're recording this we have that we could certainly ask Caitlin to um and Graham to um and probably has written down her comments i i don't know whether Graham has or or not but we certainly have that in the um you know in the recordings that we can just take that information um and and make the revisions to those three questions um you know based on the input that you provided and and because i think because i think it does get to because we talked about the importance of you know having whatever those strategies be more data informed and then you know you know because and program evaluation is something that we're paying more attention to and um and you know how are they continuing to look at um program evaluation as it relates to equity so i think we've captured it um in the notes i'm going to say and Nicole has captured that i'm sure she has and um and if if you are all good with us taking that and moving forward then i think we just want to make sure that we are asking what will be helpful for the advisory board to really evaluate and get a better idea of how agencies that we are funding are are providing service with an equity lens they're planning for it they know something about it they're looking at it they're paying attention to it so we want to do what you think will be helpful okay thank you so from my perspective um this has really been a helpful discussion because this is our first foray into including this kind of topic so i think it's important that we really kind of think through how that happens i also know we don't want to micromanage staff and it is going to be an imperfect process and there does have to be a lot of grace given to everybody to really move this thing forward and make sure it has an impact so sounds like we're at a good place jake are you just stretching or do you uh you're good okay all right okay any other discussion i think we can move on if it's good with staff okay let's go ahead and move on then thank you so i think moving on is going to the next to other business question five so unless there's any so unless there's anything else i'm you know an asked about so how the heck are we gonna do it you know approach it this year um you know we really haven't talked about that i imagine that we are doing um we've probably been doing some kind of zoom meetings i mean we don't know um but so we we're just trying to get the application completed and out the door and um and then certainly i think we can come back for our what are we this is in september so for our october meeting um and and kind of pound out what that hearing orders are at that point in time so can i share my screen chair so i can share the it's not updated but i want to remind folks of the original time yeah yeah can i do that please all right i'm gonna go ahead and share uh so this i and i was supposed to and i haven't updated um so as you can see we're not too far off of time um we wanted to get this out by this friday and and that has not happened so we might have to push this date a little back um and really this we has already decided this was going to be pushed back we weren't going to be too concerned about this 115 date um so give us more time for uh this process right here right we were gonna we were gonna give ourselves more time maybe even into december to do this um so i i i think it will probably be a zoom meeting um i think that zoom allows us to have waiting rooms which is helpful um and we can bring people in it'll be more work for nicole as she brings people in and out due to the the timing um but i think that that is is what we can do but i just want to show that we are we are not necessarily um too off on the original time frame that we set so i can probably get everything done by mid week next week and maybe send it out by or have it i'm going to be out next week thursday and friday but i could probably have it set in the system to be sent out on the on friday and we just push things back a week because how will that work with people who are if we approve the recommendations on january i will no longer be here and new people may be coming on does that matter well we don't approve the recommendation that's the that's council who approves recommendations okay okay so we we we will have our deliberation meeting in december well we can still try to aim for that um but yeah okay that makes sense yeah i i would ask that we i think the schedule looks good let's try to you know i know we're going to lose a few days here and there and where we can we'll try to compress that to stick to the schedule as much as possible and all the remaining blocks uh i'm certain we're not going to be meeting in december in person so uh nicole will have incredible zoom skills after this year yeah you're definitely pushed for that raise nicole for the holiday bonus yeah and just to reiterate the you know are really critical because these the the big piece of this then is to make sure that our evaluations align with these questions so making sure that we're we're good with how these questions are asked becomes really important but um this is great so the there's no need to talk about the evaluation portion of this is that correct so so i think that will be something i mean elliberto we i mean we've already worked at aligning the evaluation i think we talked about that earlier with the advisory board so we wanted to make it easier to evaluate so that the evaluation tool that you use follows along with the you know with the actual application so they make it easier to rate it given we've made a few modifications in the application we'll have to go back and look at modifying the evaluation tool but i think we did bring that back to y'all earlier and i think we were good with those with those changes so i would say that probably what um what we'll be asking nicole to do in the fairly near future is to start um working on calendars and and getting the um the hearing schedule set up so that you can get that on your calendars and and and we can um we can be ready to you know to rock and roll and lock in those those dates because we realize that we are doing this during november and december which is you know usually a pretty busy time for folks yeah yeah not this year okay get your flu shots yeah thank you thank you for the reminder an okay so is there shakita your one board member we haven't had a chance to hear from you any thoughts or questions before we start closing it up no i think um and i agree with uh katelyn and graham and i totally believe that ellie burto will arrange it to how we want it to be said he know where we're coming from he knows what the outcome we are looking for so i i believe he can do it i have faith in you thanks shakita and no pressure no pressure i i will try i will try my hardest to get it right listen if if you don't get it exactly like we want it's no big deal we will just be silently disappointed he will get it done this end of year bonus will go to nicole this is it's going to be bad office dynamics don't eat any banana bread from nicole okay okay thank you uh so any other business no okay with no other business i'm revisiting my agenda here is there a motion to adjourn so moved second okay with that the meeting is adjourned thank you oh and by the way i just wanted to thank you all for for making time for this meeting i know you're all busy and but it's so valuable and i love hearing your feedback so thank you very much for for attending and being part of it all right everybody have a great rest of your week thanks everybody thank you thanks Karen


So, the last example of internet security in this case will consider SSH, Secure Shell. And it's something that I think you have used either as homework tasks, you may have needed to use Secure Shell. In this course, if you've taken the lab, you've used it on a number of occasions. What do we use Secure Shell for? So, some background. What's the purpose? What's this application used for? Remote access. So, remote access, what do you mean by that? So, what do we do with this remote access? Access what? Access any other computer that's running a Secure Shell server to do what? Download web pages? Run commands. So, we run commands on another computer. Well, we need to understand, well, what do we mean by a shell and then Secure Shell? So, in a number of operating systems, we can interact with the computer via running commands, text-based commands. And we say that the software that interprets the commands we type in is a shell, shell software. So, when I log into my computer, of course, I can open up, you all know, a terminal and I can type in commands. And those commands are executed on my computer to interact with the computer. The software that specifies the syntax of the commands and what each command should do is referred to as shell software. The shell interprets those commands. And there's different types of shells. So, we know, or you know, you've done it before, when I run a command on my computer, so I'm actually on my own laptop at the moment, lsstar.jpg, ls list the files on my computer and the star.jpg says list all the files which end with .jpg. And it shows me that command lists three files. Okay, so this is just an example of using a shell, but this is on my computer. And this is common in Unix-type operating systems, so Linux, OSX also supports shells. What about Windows? Do you have a similar feature in Windows? Yeah, you do. The old one was the command prompt. So you had the, well, before that, MS-DOS was before you even have a graphical interface. You interpreted commands, and in newer versions, or the more powerful one in Windows is called PowerShell now.  So, we can do that on our own computer. Of course, when we have network access, you think, all right, well, if I can do it on my computer, when we have multiple computers under our control, it would be nice if I could run commands remotely on another computer. That is, I could sit at my computer and run a command on another computer. And the concept was originally called a remote shell. So instead of using the shell to execute a command on my computer, I would remotely run a shell program on another computer. And there was a program called RSH, remote shell. And remote shell would allow you to specify which other computer you want to run a command on, and which command you want to run, and you would do that. The problem with remote shell is it had no security. Everything we did when we had to maybe supply username and password to authenticate ourselves with that remote computer, it was unencrypted. And all of the commands we sent to that other computer and all the responses that came back was unencrypted, therefore, there were some security problems. And secure shell allow us to run commands on another computer but do it in a secure manner. And one basic way that we can use secure shell, let's use the program secure shell and then run commands on some remote computer, which one, ICT server, which I have an account on, and run a command there saying, run this command, lsstar.jpeg, but not on my laptop, but run it remotely on this other computer, ICT. And it asked me for my username and password for ICT, so I need to be able to verify that I have access. Not anyone can run commands on that remote computer. And I get the response that comes back. So what happened here was that when I ran this command, it communicated with the ICT server and to do everything securely, there was some key exchange and setting up a secure connection. And then once everything was set up, the command lsstar.jpeg was sent to that remote computer, the ICT server, it was executed on the ICT server and the results of that command were sent back to my laptop. And the results was, there's one file called finish.jpeg. And when that command lsstar.jpeg was sent to ICT and the results were sent back, that was all encrypted. So if someone captured the exchange then, they would not be able to see which command I sent there. Similar, they should not be able to see my username and password when I logged in. So that's what SecureShell does, allows us to run remote commands but in a secure manner. Now you may not use it like this in some cases, you may not run a single command, you may use it in an interactive manner where you actually don't specify a command, you just log in and then you can interact with that remote computer. You can run many commands. Now I'm actually executing commands on that ICT server. So that's how you may have used it in the past. So how does it work with respect to security? Well there's SecureShell defines how we do the key exchange and how we do the encryption for the secure data transfer. It consists of multiple different phases and different protocols, there have been different versions. Despite the close name between SecureShell SSH and SSL they are different and we know that for SSL there's an implementation called OpenSSL, there's an implementation of SSH called OpenSSH. Again despite the similarities in the name they are completely different so don't get confused between SSL and SSH. So with SecureShell normally what we do is when we connect to a remote computer we use TCP, a transport protocol that provides us unencrypted communications between client and server, provides all the reliability such that if we send a message and something goes wrong in the internet it will be retransmitted automatically by TCP. So that's a normal transport protocol used by remote access applications. So what does SSH do? It adds a sublayer on top of that the SSH transport layer protocol that whenever we send something across the internet using TCP and IP the transport layer protocol of SSH will ensure it's encrypted. So it will make sure that every piece of data we send between client and server will be encrypted. But to do that we know we need a key at both client and server, a shared secret key so there's other steps. We need to do some authentication, check that we're communicating with the right person and that they're allowed to access that server. So there's an authentication protocol and that we'll see has a username password for login and there's the key exchange as well. So that's performed also in the authentication. We make sure that we can use say a Diffie-Hellman key exchange protocol so that we can have a shared secret key. So we'll go through an example to illustrate that and then say show a couple of extensions or usage scenarios of secure shell. First the authentication. Let's have a look at the example again. So I want to access ICT server, sorry, this one, shorter. The authentication in this case is by username and password. That is how does the server know it's someone who's allowed to access it? Well the server or the secure shell authentication protocol is now prompting me for a password. I supply the password, I type in the password on my computer, it's sent to the server and the server checks that password that I supplied against one that was set up on the server in that case. So I need an account on that server and that account comes with it, a username and password. So that's one form of authentication. The server authenticates the client because the client supplies their username and password which were registered in the past. How does the client authenticate the server? How does the client know it's communicating with the correct server? Let me make a couple of changes. I'll connect to a different server. I have one of my own that's outside of our area, we'll see later, sandylands.info, I'll log in, I have an account on the server. I try to log in, what's this say? And some of you may have seen this if you've used secure shell in the past. The authenticity of host, sandylands.info, that is the server I want to connect to, identify with this IP address, can't be established. So we're talking about how do we authenticate people and now my software is saying I cannot authenticate the server. I don't necessarily trust it. And it's saying the server has this fingerprint which is some... It has a key, DSA is used for signing, it's the digital signature algorithm. So it has a key and this is the hash of that key, the short interpretation. And it says are you sure you want to continue? What do I type? No, I cannot access the server. So this is a warning message saying I cannot authenticate the server. The client is not sure that the server, sandylands.info, that you're trying to contact, is in fact sandylands.info, or maybe it's someone doing a man in the middle attack between our client and the server. So that's our problem that we have and it's come up in SSL and in any scheme that we use public key crypto to exchange keys, what if a man in the middle attack occurs? We need some form of authentication. This is saying that we have no form of authentication yet. So maybe I want to trust that a man in the middle attack is not taking place. I believe that it's unlikely. So if I try again and ask me, are you sure? And I type yes, I trust it, then I can access that remote server. So now I'm logged into the remote server. So this warning message was saying, well, I can't authenticate the server. It could be someone doing an attack, I don't know. In the first case, I type no, I don't trust it, so I couldn't log in. But the second case, I type yes, let's trust it. And now I'm logged into my remote server. So we need some way to authenticate the server, but I think many of you have seen such messages. The first time you access a remote server, you often see this message, meaning there is no authentication of the server. The client can't be sure it's talking about the right server. It could be a man in the middle attack taking place now. Now when I'm securely issuing commands on my server, maybe someone's intercepting them and seeing what I'm sending. So I don't know, so that's the problem there. We'll look at a couple of the solutions in a moment. So we have this issue of authentication. For client authentication, down the bottom, there's password based. Now does the server check it's the right client? The client submits its password and the server already knows the password because the client had an account established on there in advance. And they check them and then the client is authenticated. That's common, that approach. How does the client authenticate the server? Well, we saw it doesn't or it couldn't in those two examples. We needed to somehow trust that it was the right server. So there's no formal way to authenticate. But there are some ways to authenticate the server. And the way that we should use it is that we use public key encryption. And the approach is that if the server has its own key pair, public private key pair, and if the client already knows the server's public key, then when they perform the key exchange, and we commonly use Diffie-Hellman for a key exchange, the server can sign the messages with its public key. So here's the second point here is an important part. Assume the client knows the server's public key. So if I knew the server's public key in advance and loaded it into my client, then when I connect to the server, it will not prompt this warning message saying, are you sure? Because I trust the public key of the server. And this is key-based authentication, it's referred to. Let's try. Let's have a look at some of the setup of the client and server to see that. In SecureShell, your client or your configuration of the user accounts, there's a directory called .ssh. And inside there are some files, some configuration files for your SecureShell software. And the first two, which already exist on my computer, I've already created them, these two, IDRSA and IDRSA.pub. IDRSA.pub is my public key certificate using RSA. So in the past, I created my public-private key pair using RSA, and they are stored in two files, the public one in IDRSA.pub, and IDRSA with no extension is my private key. Don't look at that, that should be kept private. So this is a file, and if you looked inside that file, you'll see my RSA private key. And how was it generated? Well, you know how to use OpenSSL to generate a RSA key pair, and it can generate the files, and that's just inside those. So I have my own key pair. Similar, the server has its own key pair, and other computers that use SecureShell can have their own key pair. What else can be used here? Let me access this time when I try to SecureShell in the sandylands.info, it automatically logged me in. Why? And why was there no warning first? Well, there was no warning because I previously accepted it, I said yes before I trusted. And when I say yes, I trusted in the known host file are the hosts or the servers that you've contacted in the past, and some key information of them. It's very hard to see, but one of the known hosts and it starts here. This is the key of the server that I trust. So this is the public key of the server for sandylands.info, so that the next time I try to log into it, because I already trust it now, it will not prompt this warning, are you sure? Do you want to continue? It only prompts once, and then it saves the information. So this is one of the known hosts which I trust. There may be others there. What is this information? Actually it's, maybe I've got that wrong, it's here. It's hard to see because it's wrapped around a line, but it's inside here is the public key of the server. It's just encoded in some way that we can save it as text, but it's the public key of the server, and I receive that, the server sent it to me. The question was, how does my client know that this is the public key of the server? How did I know? The server sent me their public key. How did I know it wasn't modified by a man in the middle attack? Well I didn't, that was why the warning came up. The warning says, the server has sent me their public key. I don't know if it's trusted or not. I said, yes, let's trust it. So I manually trusted it, and as a result, my software saved the key in this file, this known host. From now on, it's trusted, okay? But of course that's a security flaw in that it could have been a man in the middle attack. So that's how it works in practice. The client usually records the value for later use. What else can we show before we look at the exchange? When I access the ICT server, it asks my user, or my password, it assumes my username is the same as on my client, and it works. So this is password-based authentication at the client. There's an alternative which is key-based authentication. So to summarize the authentication techniques, a common approach for the server to authenticate the client is password-based. The user at the client supplies their username and password. And for the client to authenticate the server, the server sends its public key to the client. Well, unless we've set something up in advance, there is no authentication because a man in the middle attack could take place, and we give this warning message so we must manually trust the value. Well, what I really should do is when I get this warning message, is check the fingerprint that was supplied. If I remove my known hosts, let's delete these, I remove the known host so I no longer recognize any of the other servers, and I log into sandylands.info here. How do I be sure that it's the right public here of the server? I can check this fingerprint manually via some other means with the server's fingerprint. So if I can access the server via some other means and check its fingerprint there, there's a file that shows it, see if it matches this one, then I trust the public key, then I've manually verified. But until I do that, it's still a chance of a man in the middle attack. So with secure shell access, unfortunately, that men in the middle attacks are possible, and because many people will type yes here, then we're not sure if a man in the middle attack is taking place or not. We need some out of band manual verification. So enough examples on the command line, let's look at the exchange that takes place. So the communications protocol, in summary what we do, client and server, they establish a TCP connection. This is this SIN-SINAC act saying, we're about to exchange some data using TCP. But before we send any commands, like ls-star.jpeg, we set up the secure connection and the messages here summarize what takes place. We'll see them in a capture in a moment, but first there's some short messages from client to server and back saying, this is the version of the protocol we're using and the version of software, just to say that this is what I'm going to use. And if the server doesn't trust that version, it can reject the message and not connect. Then there's some initialization of the key exchange saying what algorithms are we going to use. So we'll see those messages. Then there is the key exchange. So again, we can use different algorithms to perform a key exchange. So this is to exchange a secret key. We will see an example where we use again, Diffie-Hellman, our favorite key exchange algorithm. It's an easy one to follow. Once we perform the Diffie-Hellman key exchange, both client and server have a shared secret key. Now that they can tell each side, let's change keys. Let's go from the key exchange steps to now using this new shared secret key to encrypt our data. And I think the service requests we will not see, but after this, we have encrypted data back and forth. So let's see that via a capture. And this is a capture I did a couple of years ago. It's so that the addresses may be different now, but we'll see that in summary, what's my laptop's IP address in this case? Anyone want to guess? My laptop or my client in this case? <IP_ADDRESS> and the server was <IP_ADDRESS>. At that point in time, that was the IP address of the ICT server. And I accessed the ICT server. I think I did it from my office at that point in time. So remember the 203 address is the server, the 192 address is the client in this case. And this is the secure shell messages that we see here. And in summary, what do we see? There's two messages at the start. The server tells the client what protocol it supports and the version of the software it supports. And similar, the client sends a message to the server saying what versions I support. Because the server may be set up to say, don't allow a client that's using a version lower than this value to connect because it may believe that older version is insecure. So that's an important thing with software when they use different versions of software, we may believe that some are insecure so there's some exchange to verify or to check whether you allow that. Then there's this key exchange in it, exchange from client to server and back. And we'll see in those messages, these are specifying what algorithms that we were planning to use. One of those algorithms will be Diffie-Hellman to say to exchange a secret that's used Diffie-Hellman and we see there are four messages there. And the first two are saying, let's agree upon some Diffie-Hellman parameters. What are the Diffie-Hellman parameters we should agree upon? We should be experts on Diffie-Hellman now. What are the parameters that we should agree upon before we use Diffie-Hellman? If you look in the next slide, I think we have one of Diffie-Hellman for a minute. If you go forward in your slides, just one or two slides, you'll see Diffie-Hellman. If you go forward, I've repeated this slide, showing Diffie-Hellman. Remember, there are two public parameters, alpha and q in our notation. So we need to know them. And they are public, anyone can know them. They don't need to be encrypted when we exchange them. And that's what these two messages are about. They're saying let's agree upon or what parameters are we gonna use? Which public values are we gonna use? And then these two messages will do the public here exchange, y of the server will go to the client and the y of the client will come back to the server. So that will be the Diffie-Hellman exchange. Once we've exchanged our Diffie-Hellman public values, the two y values, each side can independently calculate the shared secret key, k. So that happens after this step. So they calculate a shared secret key, k. Similar to SSL, they generate, they use that as a master key and generate another key from that. And then the client says, let's use that new key to encrypt our data and we'll use a symmetric key algorithm. So the client sends a message saying, let's change from the key exchange part to the data encryption part. And from then onwards, everything sent between client and server is encrypted using one of the algorithms chosen in the previous messages and using the keys which were generated from that Diffie-Hellman key exchange. So in our capture, we see all the other packets are encrypted packets. When we look at them, we would not see the contents of those messages. It just looks like random bytes. So there's the encrypted packet. And what would be inside there? If I could decrypt it, some of that will be the exchange of the username and password. Remember, the user sends the password to the server. That would be in one of these packets. I don't know which one. And the commands that I send to the server would be in those packets and the responses the server sends back will be in some of those packets. But it's all encrypted and that's the purpose of setting up the secure shell connection. So we'll look briefly in the first eight or so messages. The first two are quite short. Quite short. It's just the server saying this is the protocol I support, secure shell version 2.0 and the software I'm using and it's open secure shell, open SSH version 4.7 P1 and so on. So just the versions that they support. And similar, the one that comes back from the client. Is what the client uses. And assuming that they're both are okay with using those two versions, they continue. So the next message is from the client, 192.168 to the server, the key exchange in it. Let's have a look at that. Inside here are the algorithms that the client is proposing to use. Key exchange algorithms, KEX, key exchange. This is the client saying to perform a key exchange, I want to use one of these algorithms and it lists them here. I can't see all of them, but Diffie, Helman, Group, Exchange, Shell 256 and there are others here. So this is the client saying, these are the algorithms I support for key exchange. And similar, there's algorithms for encryption and for max message authentication codes. The server host key, this is for verifying the server. So what type of key do we expect from the server? Encryption from client to server, what algorithms I support, AES128, counter mode and others. And in the other direction, we can support other algorithms, usually they're the same in both directions and what MAC algorithms do I support? And what compression algorithms do I support? HMAC with MD5, HMAC, UMAC, so different MAC algorithms there. And compression, we may compress or not, none or use a particular compression library. So you see similarities with secure shell, a secure sockets layer. We exchange the versions we support, we agree upon parameters and we say what algorithms we support. This is sent from client to server and then what does the server send back? It says the list that it supports. And it's hard to see here because it's not shown clearly by Wireshark, but if we look at this long payload here, you'll see that it's also contains those strings, Diffie, Hellman, GroupExchange and so on. So it doesn't show very nicely but the list of algorithms that the server supports are sent in this message back. Note it is a list, unlike SSL where the server chooses and sends that choice back here, the client says the list it supports, the server sends back the list they support and they independently choose one from that list. I think there's an algorithm that says choose the first one on the list that both of them support and they should therefore choose the same values of those algorithms. Hence, after this step, they know what algorithm they'll use for key exchange, for encryption, for max and compression. Now they do the key exchange. The algorithm they chose in this case was Diffie-Hellman. Diffie-Hellman, GroupExchange, I think is the extension here, but quite simply, it's the one that we know. The first message is saying it's used to agree upon the public parameters. The public parameters, there's the alpha and q in our knowledge of Diffie-Hellman. We need to, both of us need to know what is q and what is alpha. In the capture we have here, they're denoted slightly differently. It's a bit confusing. I think this slide says that in the capture, q is actually listed as uppercase p and alpha is g. And alpha is referred to as the group. So the mathematical theory refers to that as a group. So when we find p and g in this capture, we'll know that's q and alpha in our knowledge of Diffie-Hellman. So what's happening is that the client is sending first a message to the server saying what group do you want to use? What range of alpha values can we use? Not what particular value, but a range of values. It says what's the minimum and what's the maximum? That's the idea here. And then the server sends back a response using a group of five. That's the value chosen and a modulus of this value. p is q, g is alpha. Remember we take the alpha, raise it to some power, mod by q. Well, we take g, raise to some power, mod by p. So just different variables here. So now we know the public parameters that we're gonna use for Diffie-Hellman. And the next two messages are exchanging the public keys. So we know the two public global parameters. Client sends its public key. And it's denoted as e in this capture. Remember the client calculates y of the client using Diffie-Hellman and sends that to the server. Here it is, this is the value in this case. It's called the client e. It's the public value of the client. And the next message, the server calculates its public value and sends it back. And it's denoted as the server f. So e and f correspond to our y of the client and y of the server. Just to summarize on that. So remember Diffie-Hellman, the algorithm we've denoted as alpha and q as global public parameters. They agreed upon in the first two messages. Then we exchange public keys, y of the client, y of the server. They were exchanged in the last two messages which were called e and f in secure shell implementation. That mapping of those values is listed here. So just different people give different variables to refer to those values. Almost done. So we've done the Diffie-Hellman key exchange. What else do we see in this message? What's interesting in this message? Mac, right? Signature. Remember our problem with public key exchange? Man in the middle attacks. I receive someone's public key, how do I know it's theirs? So we need someone to maybe sign that public key and then the receiver can verify it. So this message includes the public key of the server, f, but that is signed using some private key and the signature is also included in this message. Here's the signature. So we know to stop men in the middle attacks, we can't just trust the value of f we receive, we need to have it verified or the way that we achieve that is someone signs the value of f and then when the client receives f, it will check the signature and see if it matches. Who's signed the value of f or what key did they use to sign f? What type of key do we use to sign? We use a private key to sign. Whose private key was used to sign this? Maybe an RSA key, but whose, which entity signed this? The server signed its own value in this case. So the server generated f and signed it themselves using their own public private key pair, an RSA key pair. So when the client receives this to verify, if it was signed with the server's private key, what did the client use to verify? The server's public key. Where does the client get the server's public key? That's our problem and that's why we get this warning message in secure shell. When we get a public key from the server, the server sends their public key unsigned to us. So yes, I need to verify the signature of the Diffie-Hellman public key. And as the client, I need to know the RSA public key of the server to verify that. The RSA public key is included in the message that is sent from the server to the client, meaning if someone performed a man in the middle attack, they could modify that themselves. Let's try and draw that to see what's happening there. We're not draw all those messages, but illustrate what's happening with the signatures. And I'll try to be clear with the keys that are known. There's, the server has its own key pair. We'll denote as the RSA public key of the server and the RSA private key of the server. And in the Diffie-Hellman key exchange, we're not show all the messages, but the key exchange part of the messages. The client sent its Diffie-Hellman public key to the server. This was the value, and we've got different notation. This was the value, sometimes we'll denote it as YC or in the capture it was called E. So the Wireshark software called E. In our general Diffie-Hellman algorithm, we've called it Y, the public value. To be more precise, I'll say it's the Diffie-Hellman public key of the client. And what came back was the Diffie-Hellman public key of the server. And the notation we've seen is YS or in the capture it's called F. So different notation, but meaning the same value. When the client receives the public key, the Diffie-Hellman public key of the server, it doesn't know if it's the correct one or not, so it needs to be signed by someone. So we also have a signature inside this message. The signature, remember to sign something, we take the data, encrypt it with a private key. So this message from server back to client contains the Diffie-Hellman public key signed. Signed using what? The RSA private key of the server. Any questions? We need to be clear now, we've got two types of public-private key pairs, Diffie-Hellman and RSA, but we have the same concepts. When we sign something, we use a private key, we verify with a public key. We're using the Diffie-Hellman public-private values to do a key exchange. We're using the RSA public-private values to sign one part of that key exchange. So what the server did is it took the Diffie-Hellman public key and signed that with its own RSA private key, sent that signature in this message and here it is in the capture, the signature component of it. Here's the public key, Diffie-Hellman public key and here's the signature. And here is the RSA public key of the server because the client doesn't know that in advance. The server knows it's public key, the client doesn't know it. The client will need the RSA public key to verify the signature. So upon reception, it goes through the verification steps and to verify we decrypt using the RSA public key of the server, the signature component. Compare that decrypted value with the Diffie-Hellman public key that was received. So in some cases when we access the server it prompts the warning, in some cases it doesn't. So why is that? Well, why do we get a warning maybe? Well, what's the problem here? In this second message receive, what's the problem for the verification perspective? What could someone do to do an attack? The problem is that the RSA public key that the client is using to verify is sent by the server. If it was an attacker, the attacker could send that themselves and modify it to whatever they like it to be. So again, because this RSA public key of the server is received in this same message there's no way from the client to know maybe this is a man in the middle who has changed the Diffie-Hellman public key. They have changed the RSA public key and they've created the correct signature and when we verify it passes the verification. So the problem is the RSA public key of the server was sent from the server in the clear unsigned and received by the client. Hence my software, when it receives this prints a warning message. I can't trust this. Someone has sent me an RSA public key but I'm not sure if it's the correct one or not and it presents this warning. Do you wanna continue? If you type yes, then your software stores this RSA public key for later use. It now trusts it. But if you say no, then you cannot log in because you do not trust this RSA public key. So it's the RSA public key used to verify the signature which is important here. The same problem happened with HTTPS and SSL. We use Diffie-Hellman, we use RSA. How was the problem solved with HTTPS? How did the client, when the client received a Diffie-Hellman public key of the server, it was signed? How did the client verify? Let's have a look. When the client received the Diffie-Hellman public key, YS, in this key exchange message, it needs to verify it was signed with the private key of the server, the RSA private key. So therefore the client verified with the RSA public key of the server. That's the same step as what we're seeing. Why did the client trust the RSA public key of the server in HTTPS? What's the thing that's important? What do we trust? Why do we trust the RSA public key of the server? The certificate authority or the certificate. That is, in HTTPS, we use the RSA public key of the server to verify the Diffie-Hellman public key. Why do we trust the RSA public key of the server? Because it was signed by the authority, the certificate authority, in the certificate that we received. The certificate contains the RSA public key of the server. The same as in SSH, the server sends its public key to us, but the difference with the certificate that public key is signed by someone else, in Secure Shell, that public key is not signed by someone else. And since in the HTTPS, we trust that someone else, the authority, we trust the RSA public key of the server and hence can verify the Diffie-Hellman public key. In this case, we receive the public key, the Diffie-Hellman public key, we receive the RSA public key, but we don't have a way to trust the RSA public key explicitly. That's why we get the warning message. And if we manually check, we can answer the yes or no and if we say yes, then we do trust it. So in fact, very similar mechanisms, just a difference in who do we trust. If we do trust, then they generate a key and let me see if I used any particular notation. Let's find one more here. We're almost done. Assuming we trust the RSA public key, the end result is that we get a shared secret key, K. And it's known by both sides. That was the purpose of doing Diffie-Hellman, get a shared secret key. And then we can use that to do the data encryption. Similar to SSL, we don't use that key directly, we generate some keys from that. And this shows some other steps to generate those keys. So we have a value K that we obtain from Diffie-Hellman. What we do is we take some other values, combine them together, hash them to generate a subkey, or in this case, an encryption key from client to server. And we do that in other steps to generate some other keys. So we saw this in SSL as well. We have a master key from that. We can calculate hashes of that master key and some other strings to generate some subkeys. And we do that here. Where we take a hash of the master key, K, some hash value, another hash value, H, which is down below, some fixed strings, C means the character C here, and a session ID which is obtained from the initial message exchanges. Where this H value, the hash, is obtained from hashing all of these things. The public, or the IDs of the different entities, I think this should be ID of the client, ID of the server. M is the protocol version, that very first message. The public key of the server and the public Diffie-Hellman values and the secret key. Again, the exact details are not so important, but here we're using hash algorithms to generate subkeys. And we can change some of those strings. For example, if we change C to another letter, we'll get a different value. The hash of two different inputs produce two different random outputs. And that finishes our key exchange because after that, the client says, let's use these new keys. You've just generated a new session key, K, C to S, and similar for the other direction. Let's use them to encrypt. What do we encrypt? What algorithm do we use to encrypt? The next packet, what algorithm is going to be used? How would you find the answer in your exam? This packet, encrypted request packet. Tell me how to find the answer. Look where, where do you want me to look to find the answer of what algorithm was used to encrypt this packet? You may not see it on the screen. Tell me where to look. It's encrypted with some algorithm. The client and server need to know that algorithm. So where would you look in this capture to find the name of that algorithm? Where is it? Which message would I look in to find the name of the algorithm used? Which one? The first one, the first two just contain the versions of the protocol. There was nothing useful about algorithms in the first two. So what algorithms use to encrypt my data? The key exchange init messages contain the list of algorithms that I support from the client's perspective for key exchange and for encryption. Okay, for encryption from client to server, the client wants to use either AES128 in counter mode or AES192 in counter mode, or if you scroll across you'll see many others. And the server in its key exchange init message says the algorithms I want to support and it's hard to see in Wireshark because it's not shown explicitly but it's under this, it's in this list. If you see on the right here you'll eventually see some AES192 counter, AES256 counter and so on. So these key exchange init messages, client says the algorithms it supports, server says the algorithms it supports, they choose the first one in the lists which both of them support. Is there a reason there is, the server supports all of these, all right? The server says I support this list of algorithms and in this order of preference, right? It prefers the first one but it will support others. It depends upon what the client supports. So as long as the server considers them all to be secure then it can say it supports them and they'll choose the best one that the highest preference for each. So you could find the algorithm from those two lists. You'd need to look in there and see which one is common and at the highest point for the encryption and you'll see probably it's AES, AES128 or one of them. I think they both support AES128 counter mode so that would be the algorithm. Everything after that is encrypted with AES128 in counter mode and you will not see the exchange of username and password for the login or the messages sent between client and server. Any questions on secure shell? In particular the key exchange and setup. The order sent by the client is what it prefers. The server sends back a message, the list of algorithms in the order that it prefers. So they both indicate their preferences from that. I think the algorithm is defined that says choose the highest preference that is in both of them. Maybe with giving priority to the server if there's a conflict. So there's an algorithm that says how do you choose from those two lists? If they both support AES128, CTR at the highest preference they'll use that. If not, they'll find the next one that matches. Any other questions about secure shell? This is our second example of internet security. You'll see there are similarities though with SSL. Let's come back to our slides and see what we've missed. So we've gone through the steps of the setting up the secure connection and then after that we can encrypt data. We didn't see a service request. I think that's not so common. There are some algorithms that define how to generate the sub keys from the master key K. Many different algorithms are supported. So this is the list of ones which I think are supported. So they can use whichever is preferred. Some are required, some are recommended. That's normal Diffie-Hellman, but in the packet capture it used different notations. So it used these values just so we could compare them. And we've gone through the capture. This just illustrates when we encrypt the data, let's say using AES how it's done, where we have the original data, we may compress that. If we use a compression algorithm, we take that compressed data, we make the packet a fixed length so we may have to add some padding because when we encrypt, we need to encrypt a particular size to be efficient so we may pad it out. Add some header information like the packet data length and the packet length. Encrypt all of that and calculate a MAC of all of that with a sequence number at the front and we get the final packet which is sent containing the ciphertext and the MAC at the end. And that's what we saw in the capture, this part. Of course, when we see this, we cannot work out what the payload is.