Re: [Tigress] Left over comments from the interim

[Eric Rescorla <[e-mail]>]

On Wed, Oct 25, 2023 at 12:38 PM Yogesh Karandikar <[e-mail]>
wrote:

> Inline,
>
> Thanks,
> Yogesh
>
> On Oct 20, 2023, at 6:44 PM, Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Fri, Oct 20, 2023 at 4:20 PM Yogesh Karandikar <[e-mail]>
> wrote:
>
>> Replies inline,
>>
>> Thanks,
>> Yogesh
>>
>>
>> On Oct 16, 2023, at 12:47 PM, Eric Rescorla <[e-mail]> wrote:
>>
>>
>>
>> On Mon, Oct 16, 2023 at 11:55 AM Yogesh Karandikar <[e-mail]>
>> wrote:
>>
>>> 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.
>>>
>>
>> Yes, and this will work fine with both proposals described already.
>>
>>
>> Indeed if the channel_1 is secure, both proposal would be fine.
>>
>>
>>
>> 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).
>>>
>>
>> Yes, but my point is that precisely how this is implemented matters. For
>> example, suppose that Alice and Attacker are both staying at the hotel and
>> Alice wants to transfer her key to Bob.
>>
>> In this case, however, she sends the invitation over an insecure channel
>> and so the attacker captures it and initiates the transfer protocol.
>>
>> The attacker then initiates his own transfer of his own room to Bob. This
>> causes Bob to go to the front desk and ask for the transfer to complete and
>> show his ID.
>>
>> The front desk calls Alice and says "Did you mean to do a transfer to
>> Bob". Alice says "yes" and the front desk and unblocks the transfer. This
>> causes the transfer to go through but to the attacker.
>>
>> In order prevent this, you need to bind the showing of the ID to the
>> actual transaction it is enabling. This should be possible, but it's not
>> trivial and we shouldn't be leaving that to the verticals.
>>
>>
>> This is actually not accurate.
>>
>> If Attacker intercepted Alice’s invite and acted upon it to get
>> Credential for Alice’s room. That Credential will still not work on Alice’s
>> room or common areas because it will be marked with security score of
>> channel_1 and will need to go through second-factor (Front desk visit in
>> this case).
>>
>> Attacker will still have to visit Front desk, they will call Alice if she
>> shared key with Attacker.
>>
>
> Not necessarily, because depending on the protocol the front desk has no
> way of knowing that the message from Alice actually went to the Attacker
> and not Bob.
>
>
> Again, the problem here is that you have not described a complete protocol
> and so it's not possible to know whether it in fact has the property you
> describe.
>
>
> Why does the front desk need to know that?
>
> Front desk person doesn’t need to understand the technical details of
> Credential sharing. They just need to follow a process defined by their
> employer.
>

Yes, I was using "Front desk" as metonymy for "the entire system at the
front deks"


>
> I thought the process would be pretty obvious to imagine for anyone who
> has ever tried to receive service in person or on phone for anything like
> airline tickets, hotel reservation.
>

Many things that seem obvious at a high level are insecure when examined in
detail, so it's important to actually define how things work.



 But let me spell it out:
>
>
>
> A personX approaches front desk and says my Credential that I received
> from my friend doesn’t work, can you help?
>
> Front Desk: Sure, tap your credential against this reader I have and I’ll
> get to see the details.
>

Here we have the first piece of new information, which is that there is a
reader at the front desk. That seems like (1) a fairly big deployment
hurdle and (2) makes the problem quite a bit easier, because now we have a
high bandwidth channel at this point of interaction.



PersonX taps the credential and front desk person gets details about which
> room the Credential is for and any other relevant details as defined by the
> Vertical.
>
> Front Desk, asks personX to confirm room number and name of friend who
> shared the Credential.
>
> If the information provided by personX matches what the Front Desk screen
> shows, front desk person can proceed with call to friend and government ID
> verification.
>

Great. But ISTM that you're making this more complicated than it has to be,
because you've
decided to treat the insecure channel (C1) as the introduction channel
rather than the secure
one (C2).

If we forget that we are doing a credential transfer and think about how
users get their
room keys at initial checkin, that requires either (1) a secure channel or
(2) an in-person
interaction which can be used to bootstrap a secure channel. It seems like
if we are
going to require (2) we could just do whatever it is hotels do in that case
for the
credential transfer as well.

This is pretty standard operating practice when trying to get some service
> from anything.
>

Actually, practices very quite substantially. As an example, you can
routinely check in
for airlines simply by presenting your ID without showing information from
the carrier
at all. This is secure(ish) because your identity will be checked again
later when you
try to go through security. Again, each situation needs its own security
analysis.


In the scenario you have described, if attacker sent their room’s
> Credential to Bob, then Bob’ information about Alice and room number won’t
> match.
>
> Same way when attacker approaches front desk, the information about
> Alice’s friend that Front desk receives won’t match.
>
>
>
>
>
>> 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.
>>>
>>
>> Well, if the sharer's key is present then it can be used directly instead
>> of the system we are proposing to build here.
>>
>>
>>
>> What does used directly mean?
>>
>
> That if the sender and recipient's keys are in the same place, you can
> establish a secure channel at that time, e.g., by having Alice display a
> bar code that Bob's phone reads.
>
>
>
> Are you suggesting that if Alice and Bob can be in proximity, they should
> only share Credentials by a proximity method?
>

No.



> Also, are you assuming that proximity equals highest amount of security
> and hence Verticals should not worry about second factor?
>

Or rather that it is sufficiently secure that you don't need a second
factor.



>
> If it's a PIN, then actually doing the PIN securely in way that's not
>> subject to attack is not at all straightforward.
>>
>>
>>
>> Agreed, doing a PIN is only effective if done correctly.
>>
>> But that is something already prevalent in the industry. As someone had
>> mentioned in one of the earlier email threads how they received sms to
>> reset their email password.
>>
>> So it’s kind of a solved problem. Of-course it can be improved.
>>
>
> The reason that people think that SMS is safe as a password reset
> mechanism is that they are trusting the SMS channel, so this does not solve
> the problem at hand, which is when you do not trust the SMS channel and
> need to *bind* the exchange over the untrusted channel to the PIN. That is
> a much more difficult problem.
>
>
>
> To me Second factor is out of scope for Tigress, but it makes interesting
> conversation.
>

Well, again, I think the charter and threat model document are quite clear
on
this point, so it's more than just an "interesting conversation".

-Ekr


>
>
> -Ekr
>
>
>