Subject: Need for secured email delegation workflow

From: vaibhav singh <[email-masked]>
Date: Wed, 12 Jul 2017 12:33:58 +0530

Hi,

First of all, I am kind of new and still learning how email infrastructure
fits in, so please feel free to highlight any glaring issues with my logic.

I was working on implementing Email Delegation for my email server, and
felt a need to highlight a couple of things.

1.) I could not find a place where this workflow is outlined. It seems like
everyone, from Microsoft to Google, have an implementation for email
delegation, and they are all kind of doing their own thing.

2.) As I could not find any RFC/Internet Draft covering this flow, I could,
potentially, create a really bad email delegation implementation in which I
could allow potentially anyone to send mails on behalf of anyone, and I
will still be, say, RFC-2822 compatible (I may be incorrect here, but I
could not really find any place which would restrict a user from sending an
email on someone's behalf, by editing the "Sender" header before sending an
IMAP request.)

Am I missing something here? Is this something which should be an Internet
draft/RFC?

-- 

Regards,
Vaibhav Singh

---

From: "John Levine" <[email-masked]>
Date: 12 Jul 2017 16:29:58 -0000

>felt a need to highlight a couple of things.

Email Delegation is not as far as I can tell a phrase that has ever
appeared in an RFC, and I have no idea what it means.

Can you tell us what you're trying to do?

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Jul 2017 09:42:49 -0700

On 7/12/2017 12:03 AM, vaibhav singh wrote:
> 1.) I could not find a place where this workflow is outlined.

It's possible that Internet Mail Architecture (RFC 5598) will assist 
your efforts, including use of common vocabulary.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 12 Jul 2017 12:56:56 -0400

> On Jul 12, 2017, at 3:03 AM, vaibhav singh <[email-masked]> wrote:
> 
> I was working on implementing Email Delegation for my email server, and felt a need to highlight a couple of things. 
> 
> 1.) I could not find a place where this workflow is outlined. It seems like everyone, from Microsoft to Google, have an implementation for email delegation, and they are all kind of doing their own thing.

I suspect this topic is not really appropriate for this list, so I'll keep this brief.

> Am I missing something here? Is this something which should be an Internet draft/RFC?

It seems you want to authorize a third party to send email on your behalf.
It is not clear that logistical guidance of how to do is proper subject
matter for an RFC.  The relevant technical standards are:

	* DKIM, allows you to delegate a keypair and a "selector" for a third
	  party to send authenticated email with "d=<yourdomain.example>"

	* SPF, allows you designate a set of SMTP clients that are authorized
	  to originate email with envelope sender addresses in your mail.

	* SMTP generally allows any client to send from any domain.  Any
          constraints that block third parties from sending on behalf of
	  of your domain are "self inflicted" (restrictive SPF, abominable
          DMARC).  To the extent that you employ these, they provide the
          means to exempt third parties from your own restrictive policies.

Any process that the third party wants you to follow in order to register
with them to send on your behalf is I think outside the scope of IETF
standards.

-- 
	Viktor.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Jul 2017 13:10:19 -0400

On Wed, Jul 12, 2017 at 12:56:56PM -0400, Viktor Dukhovni wrote:
> matter for an RFC.

Why?  We have a whole area dedicated to Management and Operations,
including one named DNSOP.

> with them to send on your behalf is I think outside the scope of IETF

The more general thing is that there is no way for a domain operator
to signal to a possible vendor its authority to allow said vendor to
operate $thing on the domain operator's behalf.  It would have been
nice if the protocol we stumbled into creating that was well-suited to
this (RDAP) didn't have a bootstrapping mechanism that was nailed to
the historical facts about whois, but some of us lost that fight in
the WG.  The way this is mostly done today is to put a bunch of TXT
records at the apex of the zone in question, thereby permanently
bloating DNS answers for large numbers of domains for no good reason
(and offering a useful amplification mechanism in passing).

I can think of more than one existing IETF standard that might be good
for this, but I can't think of one that solves the use case today.  It
might be a useful thing for some of us to discuss in the halls in
Prague.  If anyone is interested in having that conversation, please
contact me off-list.  I hear there is beer in Prague.  Maybe we can
arrange for various birds to get together in a bar rather than a hall.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Jul 2017 15:12:03 -0400

vaibhav singh <[email-masked]> wrote:
    > First of all, I am kind of new and still learning how email
    > infrastructure fits in, so please feel free to highlight any glaring
    > issues with my logic.

    > 1.) I could not find a place where this workflow is outlined. It seems
    > like everyone, from Microsoft to Google, have an implementation for
    > email delegation, and they are all kind of doing their own thing.

I think that when you say "email delegation", you mean where a manager
(or other person) authorizes their "PA" (personal assistant, formerly known
as "secretary") to send email on their behalf.  Back in the days of BNR COCOS
it was very common thing for middle management, but even in those dark days
of mainframe based email, it was usually accomplished by having the PA log in
with the manager's email.

It's good that microsoft(outlook) and google(gmail) have realized that
sharing passwords is a dumb thing.  I think that in the walled gardens of
those systems, that the email delegation is accomplished entirely within
their MUA/MTA.

    > 2.) As I could not find any RFC/Internet Draft covering this flow, I
    > could, potentially, create a really bad email delegation implementation
    > in which I could allow potentially anyone to send mails on behalf of
    > anyone, and I will still be, say, RFC-2822 compatible (I may be

RFC2822 (and 822 before it, and the one for that) always let anyone send any
email claiming to be from anyway.  That was both a strength ("permissionless
innovation"), and led to our spam disaster.  So as others in this thread
have mentioned, we have SPF to give clues as to which IP addresses are
authorized to speak authoritative for a domain, and DKIM to make sure that
the headers are authentic (and optionally body). Neither provides for content
signing that is reachable by end users at this time.
I don't think you are looking for SPF or DKIM, unless you are trying
to seperate the PA and the manager into different (submission) mail systems.

All of this is MTA to MTA protocol, not MUA to MTA.

    > incorrect here, but I could not really find any place which would
    > restrict a user from sending an email on someone's behalf, by editing
    > the "Sender" header before sending an IMAP request.)

Since you speak about IMAP, you are clearly not in the MTA business, but
I suspect in the MUA side of things.  Maybe I'm wrong and you are building
IMAP servers.  I didn't think that IMAP included email submission, but I'm
sure I'm not up to speed... (30 years since I wrote that MTA for AmigaOS...)
So let me speak about email submission protocol (rfc4409) and you can
substitute IMAP if that is in fact appropriate.

It seems to me that a mail server that has an authorized user SHOULD force
the SMTP From (aka "Sender") to the authorized user.  Perhaps it MAY also
force the body From: to a specific value, but I haven't encountered an
open source one that does.  It seems that you are asking how a MUA could
indicate (and provide proof) that it is authorized to set the From:
order Sender: to another value.  (I really think, btw, you want to set
the From: to the manager, and leave the Sender: as the PA)

This seems like it might be the space for a SAML assertion.
I believe that many IMAP servers use small subsets of SAML to provide mailbox
ACLs, and it would fit right in there.  I suspect that there is space for
an RFC about how to do this in a standard way.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: vaibhav singh <[email-masked]>
Date: Fri, 14 Jul 2017 09:38:56 +0530

Hi John,

First of all, sorry for not defining things properly. I will be adding this
glossary to all Email Delegation threads:

Definition: Email Delegation will be the workflow in which a user is able
to send emails on behalf of another user. A general example will be a
secretary replying back to emails which his/her boss received.

Couple of terms:

*manager* = The user who wants to delegate some other user to manage his
account on his behalf.

*delegate* = The user who has to get access to the manager's account.

Please note that email delegation could also cover cases like creating
folders, deleting folders etc in the manager's account.

So, I was working on a similar workflow and looking around to see how
others have implemented this workflow, and felt that a proper document
describing this workflow would really help, as the Email Delegation
behavior did not seem consistent and sometimes, not secure.

-- 

Regards,
Vaibhav Singh

---

From: "John R Levine" <[email-masked]>
Date: 14 Jul 2017 00:24:50 -0400

> secretary replying back to emails which his/her boss received.

Oh, OK.  This is rather outside the scope of IETF standards.  Historically 
(like more than a decade ago) mail programs let anyone put any address on 
the From: line.  These days we have some designs like SPF and DMARC that 
limit sending mail as other domains (e.g., as [email-masked] if 
your regular address is [email-masked]) but we've never said anything 
about how a system decides who's allowed to send mail from various 
addresses in the same domain.

We do have standards for logging into mail systems both to send and to 
pick up mail.  A widely used convention (not a standard) is that you can 
send mail with an address on the From: line if you have the credentials to 
pick up mail sent to that address.  If that's your local convention, we do 
have designs like oauth which allow access delegation.  That might be a 
useful place to look.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: vaibhav singh <[email-masked]>
Date: Fri, 14 Jul 2017 10:00:22 +0530

> those systems, that the email delegation is accomplished entirely within

Exactly!! That is the workflow I am talking about. However, I feel that
this could be something which could be used for other things as well, for
example, in the place where I work, we have some automated tools where a
user can input certain data and the tool will send mails to our group email
address on behalf of the user.

Couple of terms:

*entity *= Any email user.
Please note that email delegation could also cover cases like creating
folders, deleting folders etc in the manager's account.

This concept, in my opinion, could be generalized to include "entities"
which could request permission to send mails on behalf of some other
"entity". Sort of like OAUTH with emails, if you will. I am still hazy with
all the details and not sure about how useful this could be, but it seems
promising to me.

Another question which I was not clear about was how S/MIME would be
integrated with delegation. For example, suppose the delegate were to
create a signed email on behalf of the manager, in which case the manager
would have to share his private key with the delegate. This would
definitely not be secure.

-- 

Regards,
Vaibhav Singh

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Jul 2017 21:51:40 -0700

On 7/13/2017 9:24 PM, John R Levine wrote:
> Oh, OK.  This is rather outside the scope of IETF standards.

Except that that scenario was exactly the reason for the rfc5322.Sender 
(originally rfc733.Sender) distinction from the rfc5322.From field. See 
Section 3.6.2, which still has this explained in those terms.

So it hasn't been specified with authentication protections -- and it's 
not clear that we now how to provide that granularity at scale, or 
rather there is pretty strong operational demonstration that we do /not/ 
know how -- but it has already been done as a semantic.  40 years ago, 
this year, with periodic renewals...

The problem now is that the construct has mostly been moved to the 'via' 
hack in the <display-name> field.

d/

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Jul 2017 15:15:52 +0200

vaibhav singh <[email-masked]> wrote:
    > create a signed email on behalf of the manager, in which case the
    > manager would have to share his private key with the delegate. This
    > would definitely not be secure.

It is possible to have more than one certificate issued for a given DN,
but usually we try to avoid such things.   Some variation of this is probably
the right answer.  You'll have to talk to an enterprise CA provider to
understand if they do anything.  I suspect that if you can make contact
with the microsoft certificate authority people (I don't know them), they
will know if they have solved this problem.

I'm not sure if you read this part:

    mcr> This seems like it might be the space for a SAML assertion.
    mcr> I believe that many IMAP servers use small subsets of SAML to provide
    mcr> mailbox
    mcr> ACLs, and it would fit right in there. I suspect that there is space
    mcr> for
    mcr> an RFC about how to do this in a standard way.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 14 Jul 2017 17:42:03 +0300

> On 14 Jul 2017, at 7:30, vaibhav singh <[email-masked]> wrote:
> 
> 
> 
> On Thu, Jul 13, 2017 at 12:42 AM, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> vaibhav singh <[email-masked] <mailto:[email-masked]>> wrote:
> Exactly!! That is the workflow I am talking about. However, I feel that this could be something which could be used for other things as well, for example, in the place where I work, we have some automated tools where a user can input certain data and the tool will send mails to our group email address on behalf of the user.
> 
> Couple of terms:
> 
> manager = The user who wants to delegate some other user to manage his account on his behalf.

I think “principal” is a better term. I would expect “manager” to authorize b to manage on behalf of c.
> delegate = The user who has to get access to the manager's account.
> 
> entity = Any email user.
> 
> Please note that email delegation could also cover cases like creating folders, deleting folders etc in the manager's account.
> 
> 
> This concept, in my opinion, could be generalized to include "entities" which could request permission to send mails on behalf of some other "entity". Sort of like OAUTH with emails, if you will. I am still hazy with all the details and not sure about how useful this could be, but it seems promising to me.
> 
> Another question which I was not clear about was how S/MIME would be integrated with delegation. For example, suppose the delegate were to create a signed email on behalf of the manager, in which case the manager would have to share his private key with the delegate. This would definitely not be secure.

This is part of a wider issue. Even without delegation, if I use my own email account with several MUAs (say, my laptop and my phone), where is the private key stored?  Is it shared between laptop and phone?

You end up reading encrypted mail only using one MUA, which is one more thing dragging the use of S/Mime down.

While it may be OK to share a key with my phone (but too difficult to do securely in practice), sharing with a delegate is hairy on many different layers. But still it’s the same issue.

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Jul 2017 00:36:06 +0200

Yoav Nir <[email-masked]> wrote:
    > This is part of a wider issue. Even without delegation, if I use my own
    > email account with several MUAs (say, my laptop and my phone), where is
    > the private key stored? Is it shared between laptop and phone?

I think that simple delegation would be a better tool to delegate email
access from my desktop to my phone and/or laptop.  That way the server
knows it's an anciliary device, it could be revoked easier, and a more
suspicious profile could be applied by servers.   Google has tried to
do this with the "App passwords", but my understanding is that they still
not restricted to specific apps.  Just additional passwords that have
most access, but not password resetting access.

OpenPGP format permits a (public) key blog on contain many signing (sub)keys,
and so distributing a public key with a set of subkeys where the private
keys are stored into laptops and phones, etc. would work.

    > thing dragging the use of S/Mime down.

Agreed; I'm not sure if PKIX has a subkey concept.  I suspect it's in a
standard, but I'm unclear if it was ever deployed.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: S Moonesamy <[email-masked]>
Date: Fri, 14 Jul 2017 16:53:25 -0700

Hi Vaibhav,
At 21:08 13-07-2017, vaibhav singh wrote:
>First of all, sorry for not defining things properly. I will be 
>adding this glossary to all Email Delegation threads:
>
>Definition: Email Delegation will be the workflow in which a user is 
>able to send emails on behalf of another user. A general example 
>will be a secretary replying back to emails which his/her boss received.

Please see Section 3.6.2 of RFC 5322

Regards,
S. Moonesamy

---

From: Yoav Nir <[email-masked]>
Date: Sat, 15 Jul 2017 11:24:04 +0300

> On 15 Jul 2017, at 1:36, Michael Richardson <[email-masked]> wrote:
> 
> 

That works OK for signatures, but for encryption?  You’d have to encrypt the message with each subkey.  Yeah, I know only the symmetric key gets encrypted but it’s still ugly.

And we haven’t even mentioned the web MUA and where it stores the private keys.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Jul 2017 15:52:50 +0200

Yoav Nir <[email-masked]> wrote:
    >> OpenPGP format permits a (public) key blog on contain many signing
    >> (sub)keys, and so distributing a public key with a set of subkeys
    >> where the private keys are stored into laptops and phones, etc. would
    >> work.

    >>> You end up reading encrypted mail only using one MUA, which is one
    >>> more thing dragging the use of S/Mime down.

    >> Agreed; I'm not sure if PKIX has a subkey concept.  I suspect it's in
    >> a standard, but I'm unclear if it was ever deployed.

    > That works OK for signatures, but for encryption?  You’d have to
    > encrypt the message with each subkey.  Yeah, I know only the symmetric
    > key gets encrypted but it’s still ugly.

I'm pretty sure that the spec already says to do that.

    > And we haven’t even mentioned the web MUA and where it stores the

There are existing S/MIME and PGP plugins and extensions for browsers that do
this.  I'm aware of one that has received significant commercial success in
some quarters.  I think that they can use the javascript local storage for
private keys, but I suspect that they also have options to store them
encrypted elsewhere.