Re: [VoT] Missing RP / IdP authentication entirely

[Justin Richer <[e-mail]>]

Chris,

As I said, you can already communicate that the IdP is speaking to the user and not a proxy, and determining that is by and large the purpose of communicating the vector in the first place. In particular, the “C” component can tell you some details about verifier impersonation resistance in use during the primary authentication at the IdP.The “M” vector communicates how much you can expect that binding to last over time. Consequently, I’m not sure what you think is missing in the transmission capabilities. So using the NIST proposed vector definitions, you could have:

C2.Cm.Cv.Cs

Can you give me a concrete example of how you would propose communicating this instead?

I’m glad you brought up the concept of scope though, as I strongly believe in well-defined and limited scope for solutions. If you try to solve everything, you end up solving nothing. Trust and Identity is a *huge* problem space, and VoT is not trying to solve everything in that space. I believe the focus should be very specific, and trying to go far outside of that space is going to end up with a solution that doesn’t actually work. Instead, I think it’s more important and valuable to have point solutions that are meant to be composed. This is why the VoT value is explicitly anchored in the trustmark concept: from there, you can start to ask and answer the questions of how the vector should be processed, using technologies that are specific to the the channel that the vector was communicated over. If you’re doing OIDC, then you’re going to be using OIDC’s registration and discovery components to establish the base level of trust between the IdP and the RP. If you’re doing SAML, it’s the metadata endpoints for the IdP and SP/RP. After all, why would an RP trust anything from a given IdP, including a vector value? Solving that isn’t specific to VoT and is going to vary based on the technology, and we don’t want to tie VoT strongly to any specific identity federation protocol. 

You and I disagree about the value of VoT as it’s defined. Form my standpoint, it absolutely is improving the status quo for everyone who’s trying to communicate this same information using LoA. I also think that this needs to be combined with other elements to solve the larger problems.

 — Justin

> On Nov 28, 2017, at 4:01 AM, Chris Drake <[e-mail]> wrote:
> 
> Hi Justin,
> 
> This spec seems doomed to repeating the mistakes of OpenID - all the stuff they shoved into the "out of scope" basket came back to haunt them almost immediately.
> 
> Trust is a two-way street.  You can't call this "VoT" if you explicitly exclude half the trust.  VoT brings nothing if it has no desire to improve on the status quo!
> 
> " communicating the state of the transaction from the idp to the rp " *absolutely requires* that the RP has confidence that the IdP is communicating with the user and not a proxy.  This is a concept (impersonation resistance) not a technology (embedded hardware certificate devices) - VoT offers the chance for this vector to be communicated outside the vendor-obscured lines of technology.  If it's not included, communicating a valuable bit of state information (and one that's near-universally exploited in the wild!) is not going to be possible.
> 
> Kind Regards,
> Chris Drake
> 
> 
> Tuesday, November 28, 2017, 12:26:12 PM, Justin Richer wrote:
> 
>  <>
> 
> This spec isn't about solving primary authentication to the idp, it's about communication the state of the transaction from the idp to the rp. As you observed, this is very explicitly and deliberately about the user, not about the systems. We considered adding that kind of information in early on, but it was decided that such issues are better solved by discovery and registration protocols. VoT isn't the right tool for that, and any complete solution is going to have multiple tools working together. It should be in a standard but not here, working at a different level. This is about users, not machines. 
> 
> Verifier impersonation resistance can be communicated here already as the vector's C value can describe that the user underwent an authentication process that meets that standard. NIST's implementation of VoT under 800-63 does exactly that. VoT doesn't say how to meet that, that's what the rest of 800-63 is for, on the NIST side. Other trust frameworks will have their own anchors. 
> 
> --Justin
> 
> Sent from my phone
> 
> -------- Original message --------
> From: Chris Drake <[e-mail]> 
> Date: 11/28/17 2:46 AM (GMT+01:00) 
> To: Jim Fenton <[e-mail]>, "Grassi, Paul A. (Fed)" <[e-mail]> 
> Cc: [e-mail], Justin Richer <[e-mail]>, John Bradley <[e-mail]>, Leif Johansson <[e-mail]>, Phil Hunt <[e-mail]> 
> Subject: [VoT] Missing RP / IdP authentication entirely 
> 
> Hi All,
> 
> Completely missing from the standard are any "two directional" vectors:
> 
> 100% of the work here is user-focussed, with no attention on RP / IdP legitimacy - a huge mistake, since 91% of successful attacks against authentication take advantage of the completely-missing "machine to user" authentication step (e.g. NIST "Verifier Impersonation Resistance").
> 
> I can't decide if this needs to be a new set of vectors, or if it makes sense to incorporate into one of the existing ones:
> 
> *. Who is the RP, and how certain is the User/IdP that the RP is legitimate ?
> *. Who is the IdP, and how certain is the RP/User that the IdP is legitimate ?
> *. What steps has the IdP taken to ensure the users and RPs are not duped ?
> 
> What I am certain about, is that it needs to be in the standard.  It makes NO SENSE to put all this effort into something that addresses only 9% of the problem.  NIST recently fixed this, so should we.
> 
> Kind Regards,
> Chris Drake
> 
> 
>