Subject: [Asrg] RE: You say tomato, I say authentication

From: "Raymie Stata" <[email-masked]>
Date: Wed, 12 Mar 2003 09:12:43 -0800

Instead of authenticating senders, what if we authenticated
sender-domains, leaving it to domains to authenticate senders (or not)?

Further, what if we pushed the signing part of the problem onto MTAs,
"originating MTAs" to be exact.

So Phillip Hallam-Baker's the story goes more like this:

0) On an on-going basis, Alice's domain maintains a certificate(s) for
   e-mail authentication/integrity.  Self-signed or not, doesn't
   matter, registered in XKMS service for the domain.

1) To send mail, Alice uses SMTP to post the message to an
   "originating MTA" blessed by her domain.  (Of course, we'd all like
   to see that domain use an authenticated variant of SMTP to verify
   Alice's identity, but if you think about it, this is really a
   policy issue that perhaps domains would prefer we left to them.)

2) This MTA receives the message, (perhaps checks that the message
   meets certain of the domain's policies), signs it (S/MIME) using
   (one of) the above-mentioned certificate(s).

3) If Bob (or his receiving MTA) care, they can check the message on
   arrival.

Potential advantages of doing this at the domain rather sender level:

a) Many fewer certificates and thus potentially (much) more scalable.

b) No concerns about the adequacy of (sending) MUAs.

c) No concerns about (human) senders being confused, having to
   learn, making mistakes, being apathetic, etc.

d) Because it's now easier for domains to take "ownership" of their
   outgoing mail, there's a bit more fairness to white/blacklisting of
   entire domains.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 12 Mar 2003 11:12:18 -0800

> sender-domains, leaving it to domains to authenticate senders 

That is another equally valid method.

I see a range of possible authentication mechanisms:

Reverse MX		- Not cryptographic, can be defeated,
			  email must be routed through approved outgoing MTA
SSL			- Applies to whole domain, strong crypto
			  email must be routed through approved outgoing MTA
S/MIME		- Applies to individual sender, strong crypto
			  no restrictions on routing.

And of course a trusted third party / CA can add value here but is
not absolutely essential.

I think we need to accept that there is a rationale and a place for
each of these, and possibly new mechanisms that are carefully tailored
to the problem of spam without boiling the secure email ocean.

>    policy issue that perhaps domains would prefer we left to them.)

Actually this gated model is actualy one that appears as a requirement
in many secure email deployments - the canonical reason eing to add 
disclaimers to messages.

The 'end to end' model of security does not address the security 
requirements of a lot of financial institutions, the end is the 
institution, not Alice or Bob.

> Potential advantages of doing this at the domain rather sender level:

I agree, we definitely need the choice. The only reason I backed off
the domain level security scheme was that I didn't want to have yet
more complaints about people not being able to send direct from their
MTA while we discussed the principles.

I am currently working on a broad-based security policy language that
allows any security policy to be advertised through the DNS or other 
name/directory system. This is similar to work we are currently doing 
with Microsoft, IBM and RSA for Web Services.

Rather than send the draft to the group in its current form I would like 
to continue to refine the idea for a while in a small group. My experience
is that it is usualy better if one gets as many bugs out of a proposal
as possible before going for widespread review.

		Phill

---

From: [email-masked]
Date: Thu, 13 Mar 2003 10:09:12 +1300

>Raymie Stata wrote :

Well I agree. That's what my original post "[Asrg] Proven solution for
authenticating messages" described:

The New Zealand government has developed a specification for securing
Internet email (authentication/encryption/integrity), 
between agencies, using S/MIME gateways.
http://www.e-government.govt.nz/see/mail/index.asp

The specification is an interpretation of several RFCs:
http://www.e-government.govt.nz/docs/see-mail-bus-req-2-2/chapter1.html

This system is in use by over 50% of government agencies in New Zealand
already.  Agencies have chosen to implement it either with commercial off
the shelf packages, or through the development of an open source version.

If an ISP were to adopt the system, then a customer's FROM address, could
match the email address(es) associated with the
username/password of the ISP account.  In this way, we could authenticate
all messages between that ISP's customers and any other system user.

Because it happens at a server level, the customer never sees the complexity
of PKI.  The servers automatically establish 
and maintain links with new servers they discover (so long as the server's
CA is trusted).

Regards, Mike Pearson

Personal: The views expressed are not necessarily those of my employer.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg