Thanks for the details, Sasha! Please don't feel like you need to answer my questions while on vacation - there's no rush here.
Enjoy your vacation! On Sat, Sep 25, 2021 at 9:22 PM Sasha Tokarev <alex...@microsoft.com> wrote: > Hi Matt, > > > > Disclaimer: I’m at vacation my responses may delay. > > > > *> What's the flow to join a cloud identity here? What are the permission > prompts like? I assume that home users who use generic home user Microsoft > accounts (as I believe encouraged during Windows install/configuration) > aren't assumed to be granting this permission, though it could reasonably > be described as a "device joined to cloud identity"?* > > > > There are many ways of joining devices, many of them looks like domain > joining, and requires admin’s action and explicit user action. Home user > also either go via explicit action and consent which include web SSO: > > [image: Graphical user interface, text, application Description > automatically generated] > Thanks! So this is a per-local-app permission, that can also be granted to all apps? My main concerns, in terms of privacy (not security issues) here are: 1) Home user using a Microsoft account on their personal device unexpectedly gets logged in. If the user has to give explicit permission to Chrome or all apps (apart from just using a Microsoft account), as it sounds like is the case, I'm much less concerned about this. I'd still be more comfortable if Chrome-side integration is disabled by default, though the settings folk may not think it's worth a new setting. 2) An enterprise uses corp Microsoft accounts, but doesn't want to use Microsoft as an IDP. It may not want this information to be sent to Microsoft. Admittedly, I'm not sure how much of a concern this is, if Microsoft is managing their accounts in the first place. Note that I'd be concerned about this happening for non-Microsoft managed accounts here, too, just think it's less likely for it to be possible to accidentally happen for non-Microsoft accounts. Sounds like this does need explicit opt-in even with Microsoft managed accounts, so sounds like this isn't at all an issue. 3) A bit less of a concern, but a person using their home account on a corp device (not uncommon, though not generally a great idea), gets their personal, non-corp managed account, sent to the IDP, inheriting the fact that IDP is enabled on the device. It could either be using the corp IDP configuration, or the IDP configuration associated with the domain of their home account - both seem problematic to me. 4) Enterprise intends to use the feature, but accidentally leaks this information to a 3P. bouncing through the IDP. It sounds like there's server-side configuration to prevent this, and given that the feature has to be explicitly enabled on the OS, they've already indicated that they trust their IDP. *> Would this be enabled by default (for enterprise users only)? * > > > > It is like domain join, when you join device to domain you expect SSO. > Given that there is explicit user or admin action, and consent, which > includes web SSO, it should be enabled by default both for consumers and > enterprise users, like it is enabled in Edge. Additional flags will only > complicate deployment and doesn’t bring extra protection, users will have > to remember about the extra flag. It decreases effectiveness of the > feature. > > > > We do not ask to deploy extra flags to enable Windows Integrated Auth, > once you joined to the domain you got it, this is a new versions of Windows > Integrated Authentication. > > > > *> Also, what about incognito? * > > > > In incognito it must be OFF by default, to protect user and organization, > but it is OK, to have a settings controllable by admin to make it on. > > > > *> So this means evil.com > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fevil.com%2F&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296227472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8mZUTvFB1vrlxQNfNP2PQnzhVYLnwtD09CLUiqm7SI8%3D&reserved=0> > could redirect to https://login.microsoftonline.com/ > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogin.microsoftonline.com%2F&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296237374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=B4ZotsvVWhTesV1o4bXJUS9GaGKsF0UvBA%2Bra9BWmn8%3D&reserved=0>, > and tell it to log in using the IDP to https://www.mywork.com > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mywork.com%2F&data=04%7C01%7Calextok%40microsoft.com%7Cb342b03abc15473cfac008d980643cb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637681990296237374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Fb3gSUH4%2B%2BZRN02BynDXfKBpE1cPQ%2FaJuowthjrM3kA%3D&reserved=0>, > by providing a redirect URI there? Or is the referrer to the IDP validated > in some way?* > > > > I’m not sure I fully understand the attack here. Evil.com will have to use > mywork.com <https://www.mywork.com>’s redirect URI, it means that token > (authentication artifact) will be delivered to https://www.mywork.com not > to evil.com. Overall, these kinds of threats covered by federation > protocols OIDC, OAuth, SAML etc. IDPs exist in the modern world (Facebook, > Google, AAD, MSA) they have to be protected from all kinds of threats, as > they authenticate the user and redirect the token. All these IDPs produce a > cookie for themselves to avoid useless re-auth. This proposal only manages > the way of more secure delivering those cookies from native component in > OS, which must be implemented by IDPs vendors, to IDPs web site. This > proposal doesn’t change protocols how an IDP talks with web applications > (aka resources, aka target resources, aka relying parties). All threats and > mitigation applied to existing protocols. > I'm not suggesting a threat here, just trying to understand what information is used by the server to authenticate users (which, sure, I want to know so I can figure out the worst that can happen in the case of a malicious actor). What happens if the cookie is rejected? Could an MitM attacker figure out if the cookie is rejected or not by whether the user was redirected from the IDP to the destination site? *> I believe the initial proposed CL I saw wiring this up added the > cookies to all requests to the magic URL. Does this mean that only main > frame navigations need these additional cookies?* > > > > No, all navigations. It is a cookie by nature, it must follow all cookie > rules. If XHR-web request should append a cookies, then we need append this > cookie. The difference between this cookie and regular cookie is regular > cookie is not protected, an attacker can steal it and use on a different > device. This cookie is protected. Attacker can steal it but it will be > expired very fast. > So not just all navigations, but also XHRs and subresource requests, then? What about internal Chrome requests? These are non-webby requests, but I believe some enterprise policies may trigger them (e.g., installing extensions mandated by group policy). Should enabling 3P cookie blocking also block these, in contexts where we consider the IDP server a 3P server? These sound like SameSite=None cookies, which are slated for removal from the web platform. Admittedly, partitioned cookies will be added before that, though since these aren't really partitioned, it's not accurate to call these partitioned cookies, since they give a cross-site identity. Clearing all cookies also clears cookies (whether the user does it, or it's done by a Clear-Site-Data header), while the state maintained by these is persistent. These are also not scoped per Chrome profile, unlike cookies. So I'm not sure saying these must follow all cookie rules is accurate here. I'd be more comfortable not overloading the cookie request header. *> Is there some other communication behind the scene between the OS and > the IDP here to authenticate the device? Or is this just a matter of > encoding data in the request?* > > > > I think it is easier to answer this question is to describe what cookie > is. Please, note, format of the cookie is something internal between IDP > native component and IDP web services. Microsoft’s cookie is JWT-blob that > contains PRT > <https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token>, > nonce, and signature. The PRT contains deviceid, userid and the key hash. > The key for the signature is in a hardware chip, e.g., TPM: > > > > { > > ctx: "HfRmDwiULBY5mDyUxd8\/RQV2xs72B55H", > > *alg*: "HS256" > > }. > > { > > request_nonce: "AQABAAAAA…. < used to make sure that issuer still has > access to the hardware key >", > > refresh_token: "AQABAAAAAAA….< an encrypted by IDP blob that contains > deviceid, userid, keyHash >", > > *iat*: *1597885901* > > }. > > [signature] > > > > When such cookie arrived to IDP, we check nonce and signature. It gives us > assurance PRT comes from the same device as it was originally created. > Hence, we can trust device and user info inside PRT. A browser doesn’t > create PRT, PRT is created and updated: > > 1. During Windows logon > 2. Application logon (if user has added account), e.g., when Outlook > accessing Exchange. > > > > Browser just reads PRT-cookie. > > > > Thank you, > > Aleksandr > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEK7mvrauaO%3DyXmwEEjCz-%3DbUAFgKAB5ev%2BN1GnGJV7%2B-3imMQ%40mail.gmail.com.
