Subject: regarding authentication IDs...

From: "Jack De Winter" <[email-masked]>
Date: Tue, 08 Jul 1997 14:30:08 -0400

okay, this may sound stupid, but bear with me...

when we are adding SASL support to a layer like IMAP, POP3,
or ACAP, it is easy to establish the identity of the remote
user, and assign priviledges.  Encryption just bolsters
security.

Now, if we are doing this at the transport level, say SMTP,
is authentication pretty useless?  If not, what kind of authentication
should we all be promoting between SMTP servers?  I can see the
encryption having a strong case, but even in those cases, there
might need to be some keys exchanged and this issue of 'identity'
may come up again.

regards,
Jack

p.s. Almost forgot, if you are submitting a message into a system
using SMTP, then the above is easy.  It's more of the 'once I have
submitted the message' case that I am concerned with.
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/

Author of SLMail for 95 & NT (http://www.seattlelab.com/)

---

From: Chris Newman <[email-masked]>
Date: Tue, 08 Jul 1997 12:13:24 -0700 (PDT)

On Tue, 8 Jul 1997, Jack De Winter wrote:
> is authentication pretty useless?

It can be used within an enclave to prevent forged email, or to
authenticate/bill services such as an email->fax gateway.  It's also 
necessary to prevent man-in-the-middle attacks when doing encryption.

---

From: "Jack De Winter" <[email-masked]>
Date: Tue, 08 Jul 1997 15:26:01 -0400

>necessary to prevent man-in-the-middle attacks when doing encryption.

True... I can see those uses.  However, if we are going to use
this at a SMTP level generically, shouldn't we try to agree on
certain types of methods for exchanging information about the
authentication types?

A good example are two servers we have, one on a separate system.
I would like to set them up to allow for full permissions from
within the environ, but accept only incoming mail from outside of
the environ.  Now, should we simply agree on a format for exchanging
the names of the servers?  Or do we just create dummy accounts on
the systems that would allow the other system to authenticate?

I personally would prefer to see a difference between system level
and user level accounts, and would prefer if it was interoperable 
on a large scale.  I.e. So I could set it up so that I could get
Chris' system to authenticate relatively easily.

i.e. can we make a decision on how systems should authenticate,
independant of the user? or at least make recommendations for the
people writing the profiles for system to system protocols?

regards,
Jack

---

From: Chris Newman <[email-masked]>
Date: Tue, 08 Jul 1997 15:18:11 -0700 (PDT)

> certain types of methods for exchanging information about the

The authentication types are listed as arguments to the AUTH EHLO keyward.

> people writing the profiles for system to system protocols?

So you want a naming convention for services at a host?

I'd suggest using the KerberosV4 naming convention:
<service-name>.<server-name>

So the user "smtp.innosoft.com" would refer to the SMTP service at the
innosoft.com domain.

---

From: "Jack De Winter" <[email-masked]>
Date: Wed, 09 Jul 1997 10:21:57 -0400

>So the user "smtp.innosoft.com" would refer to the SMTP service at the

I think this is a good approach.  This way I would be able to allow
chris's server to do certain types of traffic and not others.

Questions:
1) Would there by an all encompassing service type?
2) How to handle an entire domain? (i.e. how to allow *.innosoft.com to
	be able to use those services)
3) What kind of collision to expect between the system space and the user
	name space?  How to handle them?
	3a) Perhaps a variation, such as <service-name>@<server-name> would
	avoid some of the collisions.

Other than the questions though, it seems like a straightforward approach.

regards,
Jack

---

From: Chris Newman <[email-masked]>
Date: Wed, 09 Jul 1997 09:38:53 -0700 (PDT)

> 1) Would there by an all encompassing service type?

I'm not sure there's a need.

> 	be able to use those services)

To be more precise, Kerberos uses the convention: <ident>.<inst>@<realm>

<ident> is the identity, <inst> is an instance of that identity, and
<realm> is the authentication database.  For servers, Kerberos uses the
service name for <ident> and the server name for <inst>.

> 	avoid some of the collisions.

The "@" has a different meaning in the Kerberos model and I'd rather not
create a new naming model.

---

From: "Jack De Winter" <[email-masked]>
Date: Wed, 09 Jul 1997 14:06:31 -0400

>I'm not sure there's a need.

I am thinking about cases where we want to have multiple server to server
levels with different permissions.  Or in that case, does the server just
ignore the service type and use the rest?

>service name for <ident> and the server name for <inst>.

Would an example of this be [email-masked]?

>create a new naming model.

fair enough... as long as we can come up with a good way to differntiate,
for example, a client to a SMTP server and another server to that SMTP
server, with no ambiguity.  That is my main case.

regards,
Jack

---

From: Chris Newman <[email-masked]>
Date: Tue, 08 Jul 1997 12:13:24 -0700 (PDT)

---

From: "Jack De Winter" <[email-masked]>
Date: Tue, 08 Jul 1997 15:26:01 -0400

regards,
Jack

---

From: Chris Newman <[email-masked]>
Date: Tue, 08 Jul 1997 15:18:11 -0700 (PDT)

---

From: "Jack De Winter" <[email-masked]>
Date: Wed, 09 Jul 1997 10:21:57 -0400

Questions:

regards,
Jack

---

From: Chris Newman <[email-masked]>
Date: Wed, 09 Jul 1997 09:38:53 -0700 (PDT)

---

From: "Jack De Winter" <[email-masked]>
Date: Wed, 09 Jul 1997 14:06:31 -0400

regards,
Jack