Re: [Tigress] Left over comments from the interim

[Yogesh Karandikar <[e-mail]>]

Hi Eric,

Replies inline.

Thanks,
Yogesh


> On Oct 12, 2023, at 7:22 PM, Eric Rescorla <[e-mail]> wrote:
> 
> Hi Yogesh,
> 
> Thanks for fleshing out the scenario you have in mind. Some comments below.
> 
> > Let’s assume Hotel as the vertical for this example.
> > 
> > 1. Alice sends a Hotel credential invitation to Bob over channel_1
> > (with Security score of 3 because of a recently published research
> > paper about vulnerabilities)
> > 
> > 2. The transport facilitates the provisioning information transfer to
> > B_device (the first device to claim the share). No other party is able
> > to snoop on this transfer.
> > 
> > 3. B_device is at the hotel trying to access. B_Device’s credential
> > will be marked with security score of channel_1. Let’s say the Hotel’s
> > Credential policy blocks automatic access if the Credential was
> > generated using channel_1 with a score of less than 6. In this case
> > B_Device will not be able to use the Credential instead see an error
> > message asking the user to see the Hotel front desk. At the Front
> > desk, the person will be instructed to follow a protocol to perhaps
> > looks at some government ID, instructions from Alice or other policies
> > as defined by Hotel.
> >
> > In this case:
> > 
> > if B_Device belonged to Bob, the intended Recipient, {
> >     the Front desk person removes restriction on the Credential.
> > } else {
> >     Front desk person rejects the Credential and follows Hotel protocol to deal with the situation
> > }
> 
> First, it would be good to see an actual protocol sketch here, because
> there are both secure and insecure ways to do this. Specifically, I
> would like to focus on how the hotel establishes this question:
> 
>    if B_Device belonged to Bob, the intended Recipient
> 
> How specifically do you envision this working, and in particular what
> binds B's *device* to B's credentials? This is easy to get wrong
> and I don't think it's really reasonable to punt it to the verticals.
> That's leaving a sharp object around for others to step on.
> 

I’m not sure if I actually understand the question here. 

Currently when Alice rents a hotel room, she gets 2 (or more) physical key cards. Later Alice hands a key card to Bob and Bob can use it anywhere. In this process, Bob doesn’t need to go to front desk. Hotel doesn’t verify Bob’ identity. The idea is that Hotel trusts that Alice used her judgement and a secure channel to hand over the key card.

In the Digital Credential world, the verticals are trying to mimic that user experience. Alice hands a Digital Credential to Bob using her judgement and a secure channel. All works well when the Hotel has reasonable trust in the channel. In that case Bob doesn’t need to see the front desk and there is no extra friction in use of the Credential.


In the key card world, Alice could have put the card in an envelope and put it under a door-mat to share with Bob. In that case, whoever gets the key card in hand can use it everywhere. Hotel would have no clue that happened.

In the Digital Credential world Alice could use a “under the door-mat” channel. But now Hotel would know that the used channel doesn’t have security score they like. In that case the Credential doesn’t work right away unless the person with Credential is forced to see the Front desk. Hotel could call Alice to verify the name of the person (or she could use their website/App etc). 

As you can see this is actually improving security of the overall access sharing compared to physical key card flow. 


> 
> Second, it seems to me that if we already have decided that there
> is a trusted third party in this case who can verify the user's
> ID directly and physically, then that interaction can also be
> used to bootstrap a secure channel in the manner suggested by
> Tommy. Specifically, when the Receiver goes to the front desk
> they exchange a key with the front desk (e.g., via a QR code)
> and that can be used to secure the rest of the transaction.
> 
> 
> Finally, this really seems like the easiest case. Surely there are
> situations in which people want to transfer credentials but there is
> no handy third party to facilitate physical authentication (e.g., I
> want to send someone my car keys). Do you have a proposed technical
> approach that would work in that case?


In the car key world, there are proposal where the car itself introduces the second factor friction. It could be entering a PIN code obtained from the sharer, or presence of sharer’s key. It will depend on the members of the Vertical to determine what works best for them based on their policies.

Note that result of sharing process is a battle between ease of use (shared Credential just works) vs friction from second factor. 

The Friction of second factor is considered a necessary option by verticals. They need ability to introduce that friction when their security policy demands it. 

 E.g. a Hotel that is hosting important people during a certain week could say that they want to check ID that week. In that case they need to twist the knob to not trust Digital Credential transfer no matter how secure the channel was.


To me we should try to enable the flow that Verticals typically use. 

There are 2 components  involved in sharing Credentials. Channel_1 to send the invitation. Tigress channel for secure and private transport of provisioning information.

IMO, scope of Tigress WG should be on evaluating the Tigress channel.



> 
> -Ekr
> 
> On Thu, Oct 12, 2023 at 6:33 PM Yogesh Karandikar <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi Everyone,
>> 
>> Thank you for the interactions on the call this morning. 
>> 
>> Let me to answer some of the questions raised.
>> 
>> The components of this system are as follows:
>> 
>> Component_1: Channel_1 to send invitation from Initiator to Recipient. This is interactive channel where users have to take an action to send something. Let’s say that this channel has security properties score  on a scale of 0 to 10 (0 == None, 10 == Best possible).
>> 
>> Component_2: A transport that facilitates roundtrips between 2 devices without user interaction. This transport needs to provide the guarantee that communication happens between Initiator Device and first Recipient device to claim. No other device should be able to read the communication or disrupt it by writing or deleting some message. (Req-RoundTrips, Req-ConnectionIntegrity  from requirements document). Also this transport has no reason to establish Identities of the users or collect any metadata (Privacy requirements). 
>> 
>> Component_3: Second factor by the vertical (if necessary). How is the necessity defined? The details will vary by vertical. But general principle is that security score of channel_1 will be a factor in determining the necessity. (Security score may not be the only factor). 
>> 
>> 
>> How does this all fit together? 
>> 
>> Let’s assume Hotel as the vertical for this example.
>> 
>> 1. Alice sends a Hotel credential invitation to Bob over channel_1 (with Security score of 3 because of a recently published research paper about vulnerabilities) 
>> 
>> 2. The transport facilitates the provisioning information transfer to B_device (the first device to claim the share). No other party is able to snoop on this transfer.  
>> 
>> 3. B_device is at the hotel trying to access. B_Device’s credential will be marked with security score of channel_1. Let’s say the Hotel’s Credential policy blocks automatic access if the Credential was generated using channel_1 with a score of less than 6. In this case B_Device will not be able to use the Credential instead see an error message asking the user to see the Hotel front desk. At the Front desk, the person will be instructed to follow a protocol to perhaps looks at some government ID, instructions from Alice or other policies as defined by Hotel. 
>> 
>> In this case:
>> 
>> if B_Device belonged to Bob, the intended Recipient, {
>>     the Front desk person removes restriction on the Credential.
>> } else {
>>     Front desk person rejects the Credential and follows Hotel protocol to deal with the situation
>> }
>> 
>> 
>> To me, Tigress WG needs to focus on component_2 from above (transport for ProvisioningInformation).
>> 
>> But I understand that there could be more questions about the overall System. So I guess it would be good to address all those concerns in this email thread.
>> 
>> I do have some comments about ekr’s proposal but I would hold off on them until we are ready to discuss the 2 proposals for component_2. Also it would perhaps be best to compare the 2 proposals in a separate email thread.
>> 
>> Thanks again,
>> Yogesh  
>>  
>> 
>> 
>> 
>>> On Oct 12, 2023, at 4:50 PM, Eric Rescorla <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> I had also interpreted the Threat Model document the way that Brad and
>>> Chris do, but of course, it's always possible people have different
>>> interpretations. Stepping back from the document here, I guess I just
>>> don't understand what Yogesh and Dmitry have in mind here.
>>> 
>>> To recap what I said on the call, I think we all agree that there is
>>> some channel C1 that we are going to use to transfer the initial
>>> Tigress invitation.
>>> 
>>> 1. If we assume that C1 is secure, then we can provide all the
>>>    information the Receiver needs in C1, including a secret of some
>>>    kind (S1) that the Receiver can use to authenticate itself and can
>>>    be used to encrypt the traffic.
>>> 
>>> 2. If C1 is insecure--meaning that the attacker is able to see the
>>>    contents--then any system in which the only initial information is
>>>    passed in C1 is going to be insecure because the attacker can race
>>>    the Receiver to communicate with the Sender.
>>> 
>>> Thus, if we assume that C1 is insecure, then the Receiver must have
>>> some other secret (S2) that is *not* known to the attacker. By
>>> hypothesis, S2 cannot be delivered via C1, so it must be delivered via
>>> some other channel C2 [0]. Dmitry, Yogesh:
>>> 
>>> 1. What do you envision the nature of S2 to be? E.g., is it high
>>>    entropy or low entropy?
>>> 2. What is an example of channel C2 that you would imagine people
>>>    using?
>>> 
>>> -Ekr
>>> 
>>> [0] I'm assuming for the moment that it's a shared secret. There is
>>> presumably some world in which instead the Receiver provides a
>>> hash of their public key, but I doubt we're thinking that, as
>>> it has other challenges.
>>> 
>>> 
>>> 
>>> 
>>>    
>>>  
>>> 
>>> On Thu, Oct 12, 2023 at 1:15 PM Christopher Wood <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>>> On Oct 12, 2023, at 1:33 PM, Brad Lassey <lassey=[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> Hi folks,
>>>>> I had a couple points to make until we ran out of time. First, was something I said in the chat but wanted to voice more widely. Yogesh mentioned verticals having the ability to layer additional security guarantees on top of the protocol. It would be useful to have at least one illustrative example of how that could be done and to define the extension points needed to enable that.
>>>>> 
>>>>> Second, I'd like to point out that we have a threat model document for this work (https://datatracker.ietf.org/doc/html/draft-lassey-tigress-threat-model) A lot of the discussion today was centered on what threats the protocol is intending to mitigate and how. I'm hoping that the threat model can help to make those discussions going forward. As I understood it, we were discussing the threat labeled "Attacker intercepts or eavesdrops on sharing message" which has section 5.2.2 as a mitigation (either use an end-to-end encrypted messaging channel or the solution needs to specify some other out-of-band mechanism to transmit the secret). If folks think that mitigation is insufficient, please file an issue (https://github.com/bslassey/tigress-threat-model/issues) Also, if I'm misunderstanding and  folks were thinking of a different threat, we should add it to the threat model either by filing an issue or proposing a PR. 
>>>> 
>>>> I’m still quite confused about the assumptions being made here. As you say, the threat model document says that the mitigation for this particular attack is to effectively use a secure channel to send the secret. If that’s an acceptable mitigation, then why is use of a secure channel not an assumption of the design space here? As was pointed out on the call, most of the protocol mechanics hinge on this assumption, and your draft with Ekr demonstrates that the solution can be incredibly simple in this case.
>>>> 
>>>> What am I missing?
>>>> 
>>>> Thanks,
>>>> Chris
>>>> 
>>>>> 
>>>>> Finally, I'd like to call out that the threat model is intended to cover the range of solutions to the problem, which is a pretty hard task in the abstract. Now that we have another concrete proposal, if thinking through it raises new threats, let's document those. I'd also note that the new proposal introduces new mitigations to existing threats that we need to document as well.
>>>>> 
>>>>> -Brad
>>>>> -- 
>>>>> Tigress mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/tigress
>>>> 
>>>> -- 
>>>> Tigress mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/tigress
>>> -- 
>>> Tigress mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/tigress
>>