Draft: draft-ietf-mls-architecture

Commentary: In the current definition , the AS is portrayed as a distinct service that could , for example run on a server separate from other MLS participants . However , in the MLS spec , it 's more of an abstract layer that fulfills certain functionalities , some of which are likely to run on client devices . For example , an identity key that signs individual group - level signature keys could live in the secure element of a device . From the standpoint of the spec , that key would be part of the AS . This PR changes the definition of the AS to reflect this , although there are of course multiple ways to tackle this . The MLS spec is not explicit about the fact that it 's the AS that 's potentially responsible for message authentication , i.e. to bridge a potential gap between the key used to sign a message and the key in a member 's leaf . However , it makes sense that this would be part of an abstract AS layer . If not , I believe it would still make sense to address this in the architecture doc somewhere . The plan is to add more details on compromise of parts of the abstract AS to the security section in a future PR . Let us know what you think ! This is joint work with and 
 Thanks !
The basic function of the Authentication Service (AS) is to provide a
trusted mapping from user identities (usernames, phone numbers,
etc.), to long-term identity keys, which may either be one per Client
or may be shared amongst the clients attached to a user.
A certification authority or similar service which signs some sort
of portable credential binding an identity to a signature key.
A directory server which provides the key for a given identity
(presumably this connection is secured via some form of transport
security such as TLS).
The MLS protocol assumes a signature keypair for authentication of
messages.  It is important to note that this signature keypair might
be the identity keypair itself, or a different signature keypair for
which the public key has been, for example, signed by the identity
private key.  This flexibility allows for multiple infrastructure
considerations and has the benefit of providing ways to use different
signature keys across different groups by using hierarchical
authentication keys.  This flexibility also comes at the price of a
security tradeoff, described in the security considerations, between
potential unlinkability of the signature keys across groups and the
amount of time required to reinstate authentication and secrecy of
messages after the compromise of a device.
Ultimately, the only requirement is for the applications to be able
to check the credential containing the protocol signing key and the
identity against the Authentication Service at any time.
By definition, the Authentication Service is invested with a large
amount of trust.  A malicious AS can impersonate - or allow an
attacker to impersonate - any user of the system.  As a corollary, by
impersonating identities authorized to be members of a group, an AS
can break confidentiality.
This risk can be mitigated by publishing the binding between
identities and keys in a public log such as Key Transparency (KT)
KeyTransparency.  It is possible to build a functional MLS system
without any kind of public key logging, but such a system will
necessarily be somewhat vulnerable to attack by a malicious or
untrusted AS.
The AS is considered an abstract layer by the MLS specification.
Although the name suggests that it is a separate "service", part of
this service could be running on the members' devices, while another
part is a separate entity entirely.
In most cases, the first functionality will be provided by a distinct
entity, which fulfills a role similar to that of an certification
authority in the WebPKI: It provides a binding of an identity (e.g.,
a user name, phone number, email address, etc) to a signature key.
The identity/signature key pair can then either be used directly in a
group, or as an intermediate, which in turn authenticates the
Credential used in the group.
The flexibility afforded by the latter option allows for multiple
infrastructure considerations and has the benefit of providing ways
to use different signature keys across different groups by using
hierarchical authentication keys.  This flexibility also comes at the
price of a security tradeoff, described in the security
considerations, between potential unlinkability of the signature keys
across groups and the amount of time required to reinstate
authentication and secrecy of messages after the compromise of a
device.
MLS messages are authenticated by a signature conforming to the
signature scheme of the group's ciphersuite.  To allow for
deniability (see Section Non-Repudiation-vs-Deniability), messages do
not necessarily have to be signed by the private key corresponding to
a member's Credential, but can instead be signed by a different key,
which is authenticated by the key in the Credential in some way.
While Credential authentication can be performed by a separate
entity, message authentication will likely be performed individually
by each member.  As a consequence, the message authentication part of
the AS would have to run on the members' devices.
By the nature of its roles in MLS authentication, the AS is invested
with a large amount of trust and the compromise of one of its
functionalities could allow an adversary to, among other things,
impersonate group members.
We will discuss security considerations regarding the compromise of
the different AS functionalities in detail in Section as-compromise.