From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: secret@ietf.org
Reply-To: iesg@ietf.org
Subject: WG Review: Transfer dIGital cREdentialS Securely (tigress)
A new IETF WG has been proposed in the Applications and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send your
comments to the IESG mailing list (iesg@ietf.org) by 2022-07-11.
Transfer dIGital cREdentialS Securely (tigress)
-----------------------------------------------------------------------
Current status: BOF WG
Chairs:
TBD
Assigned Area Director:
Roman Danyliw <rdd@cert.org>
Applications and Real-Time Area Directors:
Murray Kucherawy <superuser@gmail.com>
Francesca Palombini <francesca.palombini@ericsson.com>
Mailing list:
Address: secret@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/secret
Archive: https://mailarchive.ietf.org/arch/browse/secret/
Group page: https://datatracker.ietf.org/group/tigress/
Charter: https://datatracker.ietf.org/doc/charter-ietf-tigress/
There are many situations in which it is desirable to transfer a copy of a
digital credential to another person. For example, a private car owner may
want to provide access to their vehicle to a friend or a family member. A
private home owner may want to provide access to their home to their cat
sitter. An individual staying at a hotel may want to transfer a copy of a
hotel room key to their spouse. Today, no such standardized method exists in
a cross-platform, credential type-agnostic capacity.
The WG charter includes the definition and standardization of a protocol that
will facilitate such credential transfers from one person's device to another
person's device. The protocol will leverage a "relay server" to transfer data
from sender to recipient. The scope of the transfer is limited to a single
origin device and a single destination device. Note: neither private keys nor
secret symmetric keys present on the sender's device are exchanged during the
transfer operation. In the transfer protocol, the "credential" being
transferred from sender to recipient comprises data both necessary and
sufficient for the recipient to exchange with the credential authority for
new digital key material granting the recipient a subset of the sender's
capabilities or entitlements.
Privacy goals include:
* The relay server should not see sensitive details of the share
* The relay server should not be able to provision the credential itself,
acting as an intermediary for the recipient (person-in-the-middle,
impersonation attack)
* Aside from potentially the IP address, the relay server should not learn
the identity of the sender or receiver
Sufficient security measures should be embedded in the protocol in an effort
to:
* Ensure only the intended recipient is able to provision the credential
* Ensure the credential can only be provisioned once (anti-replay)
* Ensure the sender has intent to share (proof of the fact that the share
initiation is attributed to a valid device and a user)
The solution the WG defines is expected to:
* Allow a sender to initiate a share and select a relay server
* Allow a recipient to view the share request, and provision the credential
associated with the share upon receipt
* Allow a sender and a recipient to perform multiple round trip
communications within a limited time frame
* Not require that both the sender and recipient have connectivity to the
relay server at the same time
* Support opaque message content based on the credential type
* Support a variety of types of credentials, to include those adhering to
public standards (e.g., Car Connectivity Consortium) and proprietary (i.e.,
non-public or closed community) formats
The following topics are out of scope for the WG:
* Defining the mechanism the receiver will use in order to provision the
credential with the credential authority
* The User Interface (UI) that is displayed to the sender or receiver during
sending or receiving (this will depend on the device manufacturer's interface
guidelines)
* Defining the format or content of each field within the encrypted data
(i.e., the provisioned credentials and associated information) stored on the
relay server
The WG will deliver a protocol to facilitate secure credential transfer. The
WG must consider all Privacy and Security goals in an effort to perform the
credential transfer in a secure manner. The protocol will use appropriate
cryptographic mechanisms to protect the transferred credentials in accordance
with the security and privacy goals described above.
Milestones:
Dec 2022 - WG adoption of the secure credential transfer protocol
Dec 2023 - Submit secure credential transfer protocol to the IESG for
publication
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>,
tigress-chairs@ietf.org,
tigress@ietf.org
Subject: WG Action: Formed Transfer dIGital cREdentialS Securely (tigress)
A new IETF WG has been formed in the Applications and Real-Time Area. For
additional information, please contact the Area Directors or the WG Chairs.
Transfer dIGital cREdentialS Securely (tigress)
-----------------------------------------------------------------------
Current status: BOF WG
Chairs:
Leif Johansson <leifj@sunet.se>
Prachi Jain <pjain@fastly.com>
Assigned Area Director:
Roman Danyliw <rdd@cert.org>
Applications and Real-Time Area Directors:
Murray Kucherawy <superuser@gmail.com>
Francesca Palombini <francesca.palombini@ericsson.com>
Mailing list:
Address: tigress@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/tigress
Archive: https://mailarchive.ietf.org/arch/browse/tigress/
Group page: https://datatracker.ietf.org/group/tigress/
Charter: https://datatracker.ietf.org/doc/charter-ietf-tigress/
There are many situations in which it is desirable to transfer a copy of a
digital credential to another person. For example, a private car owner may
want to provide access to their vehicle to a friend or a family member. A
private homeowner may want to provide access to their home to their cat
sitter. An individual staying at a hotel may want to transfer a copy of a
hotel room key to their spouse. Today, no such standardized method exists in
a cross-platform, credential type-agnostic capacity.
The WG will standardize a protocol that will facilitate such credential
transfers from one person's device to another person's device. The protocol
will leverage a "relay server" to transfer data from sender to recipient. The
scope of the transfer is limited to a single origin device and a single
destination device. Note: neither private keys nor secret symmetric keys
present on the sender's device are exchanged during the transfer operation.
In the transfer protocol, the “credential” is the information issued by a
credential authority for a given user and device that allows them to have
access rights to a certain asset. The “share” is a data structure
transferred from the sender to recipient that comprises the data both
necessary and sufficient for the recipient to request a new credential from
the credential authority to provision it to the receiving device.
Privacy goals include:
* The relay server should not see sensitive details of the share
* The relay server should not be able to provision the credential itself,
acting as an intermediary for the recipient (person-in-the-middle,
impersonation attack)
* Aside from network-level metadata, the relay server should not learn
information about the sender or receiver
Sufficient security measures should be embedded in the protocol in an effort
to:
* Ensure only the intended recipient is able to provision the credential
* Ensure the credential can only be provisioned once (anti-replay)
* Ensure the sender has the intent to transfer (proof of the fact that the
share initiation is attributed to a valid device and a user)
The solution the WG defines is expected to:
* Allow a sender to initiate a share and select a relay server
* Allow a recipient to view the share request, and provision the credential
associated with the share upon receipt
* Allow a sender and a recipient to perform multiple round trip
communications within a limited time frame
* Not require that both the sender and recipient have connectivity to the
relay server at the same time
* Support opaque message content based on the credential type
* Support a variety of types of credentials, to include those adhering to
public standards (e.g., Car Connectivity Consortium) and proprietary (i.e.,
non-public or closed community) formats
The following topics are out of scope for the WG:
* Defining the mechanism the receiver will use in order to provision the
credential with the credential authority
* The User Interface (UI) that is displayed to the sender or receiver during
sending or receiving (this will depend on the device manufacturer's interface
guidelines)
* Defining the format or content of each field within the encrypted data
(i.e., the provisioned credentials and associated information) stored on the
relay server
The WG will deliver a protocol to facilitate secure credential transfer. The
WG must consider all Privacy and Security goals in an effort to perform the
credential transfer securely. The protocol will use appropriate cryptographic
mechanisms to protect the transferred credentials in accordance with the
security and privacy goals described above.
Milestones:
Dec 2022 - WG adoption of the secure credential transfer protocol
Dec 2023 - Submit secure credential transfer protocol to the IESG for
publication