Re: [Tigress] Sketching a simple design

[Eric Rescorla <[e-mail]>]

On Mon, Aug 14, 2023 at 11:19 PM Yogesh Karandikar <[e-mail]>
wrote:

> Hi Chris,
>
>
> On Aug 14, 2023, at 3:02 PM, Christopher Wood <[e-mail]> wrote:
>
> Hi Yogesh,
>
> On Aug 14, 2023, at 4:35 PM, Yogesh Karandikar <ykarandikar=
> [e-mail]> wrote:
>
> Hi Eric,
>
> Please see replies inline.
>
> Thanks,
> Yogesh
>
>
> On Aug 11, 2023, at 7:04 PM, Eric Rescorla <[e-mail]> wrote:
>
> Yogesh,
>
> I attempted to address a number of these points in the message you are
> responding to, but perhaps not clearly enough, so let me try again.
>
>
> > Hi Eric, Dmitry and Brad,
> >
> > Thanks for kicking off this conversation.
> >
> > The solution that Eric (ekr) has proposed is elegant and simple. It
> > relies on the assumption that R is secret.
> >
> > If R is not secret, then an attacker can easily modify or delete R.1,
> > R.2 etc.
> >
> > Unfortunately secrecy of R can not be assumed.
> >
> > The extra layer that Brad discussed in his side conversation seems
> > like a variant of Device Claim from draft-art-tigress.
> >
> > As Brad pointed out, it’s good that various potential solutions are
> > headed in same direction.
> >
> > Coming back to the secrecy of R in invitation, we have tried to
> > capture that requirement in the text ekr quoted.
> >
> > >     An invitation for a shared credential transfer, sent to the
> Receiver
> > >         device shall be a self-contained and self-sufficient data
> (e.g. token,
> > >         URL, or QR code) allowing a user of the Receiver device to
> start a
> > >         process of transferring and adding a new credential. Such
> invitation
> > >         should be allowed to be sent over any generic communication
> channel
> > >         (e.g. sms, email, NFC).
> >
> > Example of sms implicitly hints that the invitation is sent over
> > non-secure channel.  But it does not explicitly spell it out.
>
> Indeed it does not. We routinely treat SMS and email as secure
> channels (e.g., for 2FA or account recovery). Of course, their
> security properties are far from ideal, but they're also fairly
> far from just posting the message publicly.
>
>
> > Perhaps it might be worth discussing the requirement in detail.
>
> Yes, I think the WG should discuss this requirement, as it seems clear
> that there's not agreement on this point and at least I didn't even
> understand that some people thought this text had this implication.
>
>
>
> Thanks for pointing it out. We’ll certainly address this with a PR to the
> requirements document.
>
>
> > I’ll try to describe the requirements in a use case format.
> >
> > - PersonA has a credential for AccessPointA.
> > - PersonA should be able to share that credential to anyone.
> > - They should be able to post an invitation at a town square to share
> >   it. That invitation can look like this:
> >     "Invitation to get credential for AccessPointA. It’s present at
> >     mailbox address R. First person to act will get the shared
> >     credential.”
> > - If PersonY is the first person to reach the mailbox R, only PersonY
> >   gets that credential. Also nobody else is able to thwart the sharing
> >   process by modifying or deleting any messages in the exchange.
> >
> > Thoughts? Suggestion? Questions?
>
> I would make several points. First, ignoring how this is implemented,
> this seems like an extremely bad set of properties, in that they
> create a race condition between the receiver of the credential and the
> attacker. We should expect the attacker to win a significant number of
> those races, with the result that not only is he able to disrupt the
> transfer of the credential, he actually ends up with it. That doesn't
>
> seem like a secure system and I don't think the IETF should
> standardize that.
>
>
> Being able to deliver the invitation to intended recipient securely is the
> ideal property.
>
> But we can *not* make assumptions about identity of the recipient or
> security of OutOfBand channel that carries the invitation. (From Tigress
> perspective the channel that carries the invitation is the OOB channel).
> E.g. Email is one such OOB channel.  I can hope that this email lands in
> the mailbox of intended recipients and no-one else has access to its
> contents. But I can’t be sure of that.
>
> We are just trying to acknowledge the limitations of the current methods
> to deliver the invitation.
>
> I’m not sure if the probability that the invitation gets securely
> delivered to intended recipient will ever reach 100%.
>
> We still need a Tigress channel to complete the exchange after the
> invitation is delivered and acted upon by the recipient.
>
>
> I can’t speak for Eric, but I think what he’s saying is that these
> non-secure channels are consistently used for second factor authentication
> mechanisms all the time. For example, they deliver one-time codes or
> password reset secrets fairly regularly. I just used a password reset email
> today, in fact!
>
>
> Just trying to establish a baseline here.
>
> We have some consensus that certain channels like SMS are not considered
> secure. Right?
>
> There is plenty of research about vulnerabilities where an attacker can
> easily get SMS intended for someone else.
>
> I found couple of interesting articles in a few minutes of searching :
>
>
> Security Analysis of SMS as a Second Factor of Authentication - ACM Queue
> <https://queue.acm.org/detail.cfm?id=3425909>
> queue.acm.org <https://queue.acm.org/detail.cfm?id=3425909>
> [image: favicon.ico] <https://queue.acm.org/detail.cfm?id=3425909>
> <https://queue.acm.org/detail.cfm?id=3425909>
>
> Bolstering Data Privacy and Mobile Security: An Assessment of IMSI Catcher
> Threats
> <https://www.nist.gov/speech-testimony/bolstering-data-privacy-and-mobile-security-assessment-imsi-catcher-threats>
> nist.gov
> <https://www.nist.gov/speech-testimony/bolstering-data-privacy-and-mobile-security-assessment-imsi-catcher-threats>
> [image: favicon.ico]
> <https://www.nist.gov/speech-testimony/bolstering-data-privacy-and-mobile-security-assessment-imsi-catcher-threats>
> <https://www.nist.gov/speech-testimony/bolstering-data-privacy-and-mobile-security-assessment-imsi-catcher-threats>
>
>
>
>
> I don’t see a technical reason as to why the Tigress use case is unique
> and these channels cannot work for similarly sensitive secrets, such as
> those proposed in Eric’s solution sketch. And given that it greatly
> simplifies the design space here, I’d like to see us pursue that option.
>
>
> The non-secure channels are used for delivering a second factor. Also
> typically the OTP is only valid for a few seconds (enough time for
> legitimate user to enter it but not enough for attacker to use it).
>
> Can we safely assume that the 2FA over non-secure channels is considered
> acceptable for a few seconds?
>
> For Tigress, we want to acknowledge that the channels are non-secure. Yet,
> we want to let people use those channels. Because what happens after using
> those channels is expected to be secure. Also note that the after is the
> Tigress domain.
>
>
> The solution that Eric has proposed is simple and elegant. But it relies
> on the assumption that the mailbox address (R) is secret.
>
> That solution does not work when the channel used to deliver the R can not
> keep the R secret.
>

Yogesh,

Putting aside the security properties of SMS for a second,

I've already explained twice, first in my original message, and then in my
response to you yesterday,
how my design can provide the at-most-once semantics you are asking for. I
would appreciate it if
you would address that (perhaps by explaining why I'm wrong) rather than
just
continuing to assert that it doesn't.

-Ekr


>
> Thanks,
> Yogesh
>
>
> Best,
> Chris
>
>
>
>
>
>
>
>
>
>
>
> Second, as I indicated in my response to Dmitry, although the basic
> scheme I described does not provide these "at-most-once" properties,
> later in my message I do describe an enhancement which is intended to
> provide them, under the heading "Restricting the exchange to two
> participants".  Briefly, the idea is that the Sender's initial message
> contains an additional secret X1 which is used along with R to
> generate the address of the receiver's response. The receiver deletes
> the sender's message after reading it, with the result that any
> subsequent participant is unable to generate the appropriate return
> address. It's of course possible I've missed something and this
> doesn't work. The cookie system designed in Brad's message also seems
> like it would address this issue, and IMO it's a lot simpler than
> adopting all of the machinery in draft-art-tigress.
>
>
> Both of those approaches can work but they essentially shift the work of
> Req-ConnectionIntegrity into the protocol that is going to use the Tigress
> channel.
>
> Those protocols are defined out of scope of IETF and could chose whatever
> X1 and PseudoRandom functions. They could even define a completely
> different approach if they wish.
>
> That increases the complexity of clients trying to implement the
> credential transfer solutions. The client has to implement n different
> methods for Req-connectionIntegrity to support n different verticals.
>
> Whereas draft-art-tigress handles that complexity and provides a simple
> channel interface for clients.
>
> As an implementer, I would prefer the Tigress channel to handle the
> complexity and provide Req-ConnectionIntegrity.
>
>
>
> Note that AFAIK none of these approaches prevents the race condition I
> alluded to above, which is why I still think it's necessary to assume
> R is secret or to have some other piece of secret material shared
> between sender and receiver. However, it does provide security againt
> subsequent leaks of R.
>
> -Ekr
>
> P.S.  Whatever you are doing when you respond seems to be be breaking
> threading, at least in gmail. Are other recipients having this issue?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Aug 11, 2023 at 9:03 PM Yogesh Karandikar <ykarandikar=
> [e-mail]> wrote:
>
>> Hi Eric, Dmitry and Brad,
>>
>> Thanks for kicking off this conversation.
>>
>>
>> The solution that Eric (ekr) has proposed is elegant and simple. It
>> relies on the assumption that R is secret.
>>
>> If R is not secret, then an attacker can easily modify or delete R.1, R.2
>> etc.
>>
>> Unfortunately secrecy of R can not be assumed.
>>
>> The extra layer that Brad discussed in his side conversation seems like a
>> variant of Device Claim from draft-art-tigress.
>>
>> As Brad pointed out, it’s good that various potential solutions are
>> headed in same direction.
>>
>> Coming back to the secrecy of R in invitation, we have tried to capture
>> that requirement in the text ekr quoted.
>>
>> An invitation for a shared credential transfer, sent to the Receiver
>>>     device shall be a self-contained and self-sufficient data (e.g.
>>> token,
>>>     URL, or QR code) allowing a user of the Receiver device to start a
>>>     process of transferring and adding a new credential. Such invitation
>>>     should be allowed to be sent over any generic communication channel
>>>     (e.g. sms, email, NFC).
>>>
>>
>> Example of sms implicitly hints that the invitation is sent over
>> non-secure channel.   But it does not explicitly spell it out.
>>
>> Perhaps it might be worth discussing the requirement in detail.
>>
>> I’ll try to describe the requirements in a use case format.
>>
>> - PersonA has a credential for AccessPointA.
>> - PersonA should be able to share that credential to anyone.
>> - They should be able to post an invitation at a town square to share it.
>> That invitation can look like this:
>>     "Invitation to get credential for AccessPointA. It’s present at
>> mailbox address R. First person to act will get the shared credential.”
>> - If PersonY is the first person to reach the mailbox R, only PersonY
>> gets that credential. Also nobody else is able to thwart the sharing
>> process by modifying or deleting any messages in the exchange.
>>
>>
>> Thoughts? Suggestion? Questions?
>>
>> Thanks,
>> Yogesh
>>
>>
>>
>>
>>
>>
>>
>>
>> *From: *Brad Lassey <[e-mail]>
>> *Subject: **Re: [Tigress] Sketching a simple design*
>> *Date: *August 8, 2023 at 2:33:25 PM PDT
>> *To: *Eric Rescorla <[e-mail]>
>> *Cc: *Dmitry Vinokurov <dvinokurov=[e-mail]>,
>> [e-mail]
>>
>>
>> On Tue, Aug 8, 2023 at 8:52 AM Eric Rescorla <[e-mail]> wrote:
>>
>>> > Hi Erik,
>>>
>>> Eric.
>>>
>>>
>>> > One potential but rather low risk is that R generated by a client
>>> > (collision risk) vs R generated by server - if implemented properly on
>>> > server, there is less chance of collision.
>>>
>>> R obviously has to be of sufficient size, but assuming it is (say 256
>>> bits) then the chance of collision is vanishingly small.
>>>
>>> We routinely assume that randomly generated values of sufficient size
>>> do not have collisions in situations where the results will be far
>>> more serious if they do, so I don't think this is a realistic
>>> objection.
>>>
>>>
>>> > Tigress requirements document doesn't mandate that the invitation URL
>>> > be sent over secure channel. Therefore we have to operate under
>>> > assumption that the channel may be insecure - such as SMS/ email;
>>> > hence, the invitition URL - e.g. https://<server>/R can be intercepted
>>> > (or mistakenly sent to a wrong receiver) - which is accepted and known
>>> > risk.
>>> >
>>> > This is identified as a high risk in the Threat model
>>> > document. Tigress proposes to mitigate this risk with the secret sent
>>> > out of band and additional second factor (verification code).
>>>
>>> It's unfortunate that the requirements are so unclear on this topic,
>>> as I had understood from previous conversations that we *were*
>>> assuming the integrity of the channel. I would note that the document
>>> tend to support this and are at best ambiguous.
>>>
>>> From Section 9 of the Requirements Document:
>>>
>>>     An invitation for a shared credential transfer, sent to the Receiver
>>>     device shall be a self-contained and self-sufficient data (e.g.
>>> token,
>>>     URL, or QR code) allowing a user of the Receiver device to start a
>>>     process of transferring and adding a new credential. Such invitation
>>>     should be allowed to be sent over any generic communication channel
>>>     (e.g. sms, email, NFC).
>>>
>>>
>>> And S 5.2.2 of the threat model:
>>>
>>>    Solution should require an end-to-end encrypted messaging channel
>>>    or otherwise specify a way to send a secret out of band.
>>>
>>> Moreover, if your concern is that the URL will be compromised and
>>> everything is protected by some short code, then we have other
>>> problems. So, I think we probably should discuss the threat model
>>> some more.
>>>
>>>
>>> > Therefore, we assume that we can not guarantee that the communication
>>> > via intermediate server is completely secure, but we want the protocol
>>> > to guarantee that once the first receiving device starts the transfer
>>> > flow, it can successfully complete it (first come first served
>>> > approach that I mentioned in IETF 117 Tigress session).  The content
>>> > of the data stored in the shared resource (aka mailbox) should't be
>>> > spoiled or deleted before the transfer completion
>>> > (Req-ConnectionIntegrity).
>>> >
>>> > Going back to the proposed protocol - knowing the R, malicious actor
>>> > can overwrite R, R.1, R.2 with harmful code (e.g. cat pictures, virus,
>>> > spam information, ads) or just delete R, R.1, R.2 etc. There is a
>>> > chance that this might happen just by mistake, not with harmful
>>> > intent. In any case, this breaks the (Req-ConnectionIntegrity).
>>>
>>> This is correct for the basic protocol but I believe not for the one I
>>> describe later in the message under the heading "Restricting the
>>> exchange to two participants".
>>>
>>>
>>> > If we say that we want to delegate this responsibility to the client
>>> > protocol, we also need to define an additional protocol for the
>>> > communication between sender and receiver clients. I don't really see
>>> > any benefits in adding a second protocol for the clients if this can
>>> > be addressed in a single server protocol with resource locking between
>>> > just 2 clients.  I think that the fact that a off-the-shelf webserver,
>>> > supporting WebDav can work for resource sharing, can't meet our
>>> > security requirements (and hence we need to implement an additional
>>> > protocol on the client level), is not a valid justification for using
>>> > such web-server.
>>>
>>> I'm not sure I follow you here. I would make several points.
>>>
>>> 1. I believe that this does meet the security requirements, without
>>>    any additional protocol other than what I've sketched above. Can
>>>    you share your concerns about why that's not the case?
>>>
>>> 2. I'm not sure why you are mentioning WebDAV here. This is just
>>>    straight HTTP. I did at one point suggest WebDAV, but having
>>>    thought through the problem more, I do not believe it is necessary.
>>>
>>> As far as "valid justification" goes, this design has several
>>> advantages over the REST API design in draft-art-tigress. First, it
>>> doesn't require modifications to the Web server, as this is a
>>> conventional configuration. Second, because the correctness and
>>> security properties are largely enforced at the endpoints it largely
>>> doesn't depend on the server behaving correctly beyond some simple
>>> access control mechanisms (not allowing clients to enumerate files).
>>>
>>> -Ekr
>>>
>>>
>>> --
>>> Tigress mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tigress
>>
>>
>>
>> Thanks Eric,
>> I think you made an important point at the mic during the meeting and
>> that was that a lot of the complexity of the original Tigress proposal
>> falls out of the fact that it is trying to have the sender and receiver
>> "co-edit" the same resource. That functionality is the sort of thing that
>> WebDAV set out to solve years ago, and hence why I think many of us jumped
>> to that solution space.
>>
>> If we instead read/write separate resources sequentially, it
>> simplifies things greatly. In fact, Eric Kinnear and I effectively sketched
>> out the same solution you describe here in a side conversation after the
>> working group meeting.  It is probably a good sign that two different sets
>> of people arrived at roughly the same rough conclusion independently.
>>
>> There were two additional ideas that we discussed that could layer on top
>> of this. The first was aimed at reinforcing the "only two" property that
>> Dmitry and Yogesh brought up during their presentation and that was to have
>> the server set a session cookie for both the sender and receiver and
>> restrict the access to /R* to only two unique session cookies.
>>
>> The second was to have a convention that the sender and receiver can PUT
>> a file at /R.sender and /R.receiver respectively that contains a webhook
>> URL and the server can ping that webhook whenever any new file is PUT to
>> /R*.
>>
>> I think both of these things could be optional enhancements, which would
>> preserve the property that you can use an off the shelf HTTP server and be
>> spec compliant.
>>
>> -Brad
>>
>>
>>
>>
>> --
>> Tigress mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tigress
>>
>
> --
> Tigress mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tigress
>
>
>