Re: [Tigress] Tigress Digest, Vol 10, Issue 1

[Prachi Jain <[e-mail]>]

Well, looks like it's already on the mailing list. My bad !!

Tigress folks,

Please let us know if you have any feedback on this change.


On Tue, May 30, 2023 at 9:47 AM Prachi Jain <pjain=
[e-mail]> wrote:

> Hi Dmitry,
>
> Apologies for delayed response. I was on vacation and in a spotty internet
> coverage place so couldn't get to you earlier.
> This seems to be a very minor change and you are welcome to send an email
> on the mailing list to get feedback on it. Once you get the feedback, feel
> free to merge and publish a new version.
>
> I would also like to do an adoption call on the threat model. Letus know
> what the authors think about it.
>
> -Prachi
>
> On Thu, May 25, 2023 at 1:33 PM Dmitry Vinokurov <[e-mail]>
> wrote:
>
>>
>> Hi folks,
>>
>> I would like to make a consensus call on
>> https://github.com/dimmyvi/tigress-requirements/pull/59 change to the
>> requirements draft.
>> I believe they change has rather editorial nature, more formally defining
>> the “Credential” term.
>>
>>
>>
>> Dmitry Vinokurov
>> * Pay* | 669-269-5514 | Infinite Loop 6, Cupertino, CA |
>> [e-mail]
>>
>> On May 3, 2023, at 9:59 AM, [e-mail] wrote:
>>
>> Send Tigress mailing list submissions to
>> [e-mail]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://www.ietf.org/mailman/listinfo/tigress
>> or, via email, send a message with subject or body 'help' to
>> [e-mail]
>>
>> You can reach the person managing the list at
>> [e-mail]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Tigress digest..."
>> Today's Topics:
>>
>>   1. Re: Update of digital credential definition (Dmitry Vinokurov)
>>
>> *From: *Dmitry Vinokurov <[e-mail]>
>> *Subject: **Re: [Tigress] Update of digital credential definition*
>> *Date: *May 3, 2023 at 9:59:11 AM PDT
>> *To: *[e-mail]
>>
>>
>> Hi all,
>>
>> Yogesh has put up a new PR based on the prior discussion of definition of
>> Digital Credential in Tigress Requirements doc:
>> [image: 59.png]
>>
>> Updated definition of Digital Credential based on feedback by ykarandikar
>> · Pull Request #59 · dimmyvi/tigress-requirements
>> <https://github.com/dimmyvi/tigress-requirements/pull/59>
>> github.com <https://github.com/dimmyvi/tigress-requirements/pull/59>
>> <https://github.com/dimmyvi/tigress-requirements/pull/59>
>>
>>  Please review.
>>
>>
>> Dmitry Vinokurov
>> * Pay* | 669-269-5514 | Infinite Loop 6, Cupertino, CA |
>> [e-mail]
>>
>> On Apr 19, 2023, at 9:40 PM, [e-mail] wrote:
>>
>> Send Tigress mailing list submissions to
>> [e-mail]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://www.ietf.org/mailman/listinfo/tigress
>> or, via email, send a message with subject or body 'help' to
>> [e-mail]
>>
>> You can reach the person managing the list at
>> [e-mail]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Tigress digest..."
>> Today's Topics:
>>
>>   1. Re: threat model review (Yogesh Karandikar)
>>
>> *From: *Yogesh Karandikar <[e-mail]>
>> *Subject: **Re: [Tigress] threat model review*
>> *Date: *April 19, 2023 at 9:40:19 PM PDT
>> *To: *Eric Rescorla <[e-mail]>
>> *Cc: *[e-mail], Daniel Kahn Gillmor <[e-mail]>,
>> Dmitry Vinokurov <[e-mail]>
>>
>>
>> Inline,
>>
>> Thanks,
>> Yogesh
>>
>>
>> On Apr 19, 2023, at 6:59 PM, Eric Rescorla <[e-mail]> wrote:
>>
>>
>>
>> On Tue, Apr 18, 2023 at 4:22 PM Yogesh Karandikar <ykarandikar=
>> [e-mail]> wrote:
>>
>>> Hi,
>>>
>>> Some more replies inline.
>>>
>>> Thanks,
>>> Yogesh
>>>
>>>
>>> On Apr 18, 2023, at 12:00 PM, [e-mail] wrote:
>>>
>>> Send Tigress mailing list submissions to
>>> [e-mail]
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://www.ietf.org/mailman/listinfo/tigress
>>> or, via email, send a message with subject or body 'help' to
>>> [e-mail]
>>>
>>> You can reach the person managing the list at
>>> [e-mail]
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Tigress digest..."
>>> Today's Topics:
>>>
>>>   1. Re: threat model review (Daniel Kahn Gillmor) (Dmitry Vinokurov)
>>>
>>> *From: *Dmitry Vinokurov <[e-mail]>
>>> *Subject: **Re: [Tigress] threat model review (Daniel Kahn Gillmor)*
>>> *Date: *April 18, 2023 at 11:20:54 AM PDT
>>> *To: *[e-mail]
>>>
>>>
>>> Hi Daniel,
>>>
>>> Thank you for the feedback.
>>> Added some replies in-line.
>>>
>>> Dmitry Vinokurov
>>> * Pay* | 669-269-5514 | Infinite Loop 6, Cupertino, CA |
>>> [e-mail]
>>>
>>> On Apr 16, 2023, at 12:00 PM, [e-mail] wrote:
>>>
>>> Send Tigress mailing list submissions to
>>> [e-mail]
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://www.ietf.org/mailman/listinfo/tigress
>>> or, via email, send a message with subject or body 'help' to
>>> [e-mail]
>>>
>>> You can reach the person managing the list at
>>> [e-mail]
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Tigress digest..."
>>> Today's Topics:
>>>
>>>   1. Re: threat model review (Daniel Kahn Gillmor)
>>>
>>> *From: *Daniel Kahn Gillmor <[e-mail]>
>>> *Subject: **Re: [Tigress] threat model review*
>>> *Date: *April 15, 2023 at 1:52:54 PM PDT
>>> *To: *Yogesh Karandikar <[e-mail]>, Eric Rescorla <
>>> [e-mail]>
>>> *Cc: *[e-mail]
>>>
>>>
>>> Thanks for this further clarification, Yogesh.
>>>
>>> Since we seem to be struggling with terms and definitions in this
>>> thread, i'll ask a few more questions, as i'm still strugging with a
>>> clear picture of the goals of this project.  I apologize if these are
>>> already well understood here.
>>>
>>> On Fri 2023-04-14 18:16:19 -0700, Yogesh Karandikar wrote:
>>>
>>> Digital Credential is defined in the requirements document as:
>>> Cryptographic material and other data used to authenticate the user
>>> with an access point
>>>
>>>
>>> Do you mean "authenticate" or "authorize"?  Authentication is about
>>> identity.  Authorization is about access.
>>>
>>>
>>> The last time i checked into a hotel (they authenticated me at the
>>> desk), i was given two RFID cards that were authorized to access (by
>>> elevator) the floor of the hotel that the room was on, and the room
>>> itself.
>>>
>>> Had I handed one of those cards to someone else, i would have been
>>> granting them *authorized* access without an *authenticating*
>>> credential.  Just to make sure i'm understanding the terms right: the
>>> "access point" is the elevator or the door in this case, right?
>>>
>>>
>>> Access point is indeed the the elevator or door entry.
>>>
>>>
>>> In my hotel, neither the elevator nor the door knows the identity of the
>>> cardholder when i transfer the card to someone else.
>>>
>>>
>>> If we explicitly define the credential transfer process as a process
>>> that authenticates the recipient to the access point, that appears to
>>> fix semantics in the protocol that would foreclose a common current
>>> practice.
>>>
>>> Is that intentional?
>>>
>>> DV>> to “authorize” is more correct verb here, I agree with you. The
>>> goal is to authorize the user to gain access.
>>> I will update the requirements doc.
>>>
>>>
>>>
>>> Actually it needs to be “authenticate and authorize”.  The
>>> authentication here is mutual authentication between device and access
>>> point.
>>>
>>> I’m not sure if the current RFID cards and access points perform mutual
>>> authentication, but with Digital Credentials that is a goal.
>>>
>>> It adds to privacy promise. A device will not reveal any detail about
>>> presence or absence of a credential to just any access point probing for it.
>>>
>>
>> This seems entirely orthogonal to this WG and specific to the
>> credentials.
>>
>>
>> It’s indeed extra information about credential, provided to satisfy
>> curiosity about credential.
>>
>> I don't see how anything we have proposed here would enforce this
>> property.
>>
>>
>> I agree that enforcing credential properties is outside the scope of this
>> WG.
>>
>>
>> -Ekr
>>
>>
>>
>>>
>>>
>>> As we discussed in the other email, it would be good to have common
>>> terminology across charter and all the documents.
>>>
>>>
>>> Agreed.
>>>
>>> - Bob’s device needs to trust the url as a credential transfer url.
>>>
>>>
>>> The word "trust" is a tricky one in this space, and common use of the
>>> word is sometimes subtly opposed to the technical meaning.
>>>
>>> It might help to be a little bit clearer here.  Which of these do you
>>> mean?
>>>
>>> a) Bob's device needs to be able to reliably assess whether the URL that
>>>    initiates the Tigress process is in fact a credential transfer URL
>>>
>>> b) Bob's device must assume that the URL that initiates the Tigress
>>> process is
>>>    a credential transfer URL, and he learns this in some unspecified
>>>    out-of-band way; the protocol offers no way for him to prove it
>>>    that it is correct.
>>>
>>> (a) is i think closest to the "normal english" use of the term "trust".
>>>
>>> (b) is the technical/security engineer use of the term "trust", as in
>>> "trusted third party" or "trusted computing base".
>>>
>>>
>>> Thinking about these questions also raises some additional concerns
>>> about how TIGRESS plays with the rest of the ecosystem: Does Bob's
>>> device needs to be able to reliably identify *in any non-TIGRESS
>>> context* that the URLs seen are *not* credential transfer URLs?
>>>
>>> Risky "magic URLs" in unexpected contexts can be seen, for example, in
>>> the forwarded-bulk-email case:  Charlie receives a bulk e-mail that she
>>> thinks Dave would be interested in, which has some links in it that she
>>> doesn't know are unique to her (e.g. an unsubscribe link).  She forwards
>>> the message without thinking to Dave, and Dave can then unsubscribe
>>> Charlie from the distribution list.  Does TIGRESS need to consider this
>>> scenario?
>>>
>>> DV>> I think “trust” of a credential transfer URL stems from previous
>>> versions of requirements document where it was stated that the intermediary
>>> server needed to be in a “trusted” or “allow”-list
>>> On the receiving device.
>>> In the current version of requirements we removed this requirement based
>>> on interim IETF meeting consensus - moving it to security considerations.
>>> Current consideration shifts the definition of trustworthiness to
>>> implementation: “Threat model for implementation that uses an
>>> intermediary server to facilitate the credential transfer, should
>>> consider evaluation of the trustworthiness of the intermediary server
>>> by the receiver device based on agreed criteria"
>>> This, I believe is closer to your statement b). Protocol per se does not
>>> give instructions how to define or implement this.
>>>
>>>
>>> I agree with Dmitry about this being statement (b).
>>>
>>>
>>>
>>> - Bob’s device needs to know what type of credential is being
>>> transferred and if it supports that credential. If it does, which
>>> service or application (Car Key, Hotel Key, Apartment Key) should
>>> handle this credential transfer. Then fire up the right handler to
>>> complete the transfer.
>>>
>>>
>>> What level of granularity do you imagine Tigress specifying here?
>>> Should we be thinking about registering a new namespace that is
>>> initially populated with generic classes like Car, Hotel, Apartment? or
>>> is this more of a "each vendor is going to register their own "type", so
>>> Bob can distinguish between, say, a Schlage or a Yale lock, or a Hyundai
>>> from a Honda?
>>>
>>> Are you envisioning a generic "unlocker" app (or OS utility) that can
>>> use this protocol, or will i need to install distinct apps for my home
>>> and my car, and then yet another new app for my friend's house when i
>>> stay over, and a fourth one for the times when i drive my parent's car?
>>>
>>>      --dkg
>>>
>>> DV>>  I believe in the early protocol draft (
>>> https://datatracker.ietf.org/doc/draft-art-tigress/01/)
>>> we proposed 2 ways to define credential type or “vertical”:
>>> 1) in the credential transfer URL parameters: ref to paragraph 3.4.1 Credential
>>> Vertical in Share URL.
>>> 2) In the Provisioning Information Format - paragraph 3.3.1 -
>>> “Provisioning Information Format”.
>>>
>>> The protocol document has not been adopted - and is going to be the next
>>> step after adoption of Requirement and Threat model document.
>>> We would very much appreciate your help formulating this type of
>>> credential.
>>> General rule we are trying to follow was "need to know” basis for the
>>> protocol - e.g. we need to differentiate Car Key from a Hotel key - since
>>> this affects the protocol (one data exchange vs multiple exchanges), but
>>> information about the Hardware manufacturer of the lock is excessive since
>>> it does not affect the transfer.
>>>
>>>
>>> To add to what Dmitry mentioned, each type of credential is covered by
>>> different specifications. Depending on the type of credential, the
>>> provisioning process is different. So current proposal is to keep the
>>> granularity at the level of different verticals (CarKey, HotelKey). But if
>>> there is an argument in favor of going more granular, it is certainly worth
>>> discussing.
>>>
>>>
>>>
>>> Tigress mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tigress
>>>
>>>
>>>
>>>
>>> Tigress mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tigress
>>>
>>>
>>> --
>>> Tigress mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tigress
>>
>>
>>
>>
>> Tigress mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tigress
>>
>>
>>
>>
>> Tigress mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tigress
>>
>>
>>
> --
> Tigress mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tigress
>