Re: Devilish: Forget about DNS

On Mon, 9 Feb 2004, Hadmut Danisch wrote:

> On Mon, Feb 09, 2004 at 11:26:50AM -0800, Jeff_Silverman wrote:
> >
> > So why not use kerberos, which was designed to authenticate things?
> >
> 
> 
> For several reasons:
> 
> - This is about authorization, not authentication
I disagree with you.  The trusted third party authenticates that the 
message is authentic.  The receiver decides if the it will accept the 
authentication as valid, if it will accept authentic mail from this 
sender, if it will accept mail with no authentication.  This idea is in 
keeping with the spirit of Kerberos, which provides authentication, not 
authorization ( Microsoft not withstanding).


> - There is no world wide kerberos network. There's only
>   DNS. That's why I still propose to use DNS to find the
>   server providing the authorization record.
There is no world wide kerberos network (WWKN) yet.  However, a WWKN might 
solve several other problems.  In any event, Microsoft wants to build a 
network of authentication services called "passport".  Do you think the 
evil empire will publish how passport works so you can build a passport 
client for your favorite OS?

> - Kerberos requires interaction of the authenticating user.
>   We don't have him here. It's a store and forward service.
>   Of course, you could authenticate relays against each other, 
>   but what would this take to work?
I don't know yet.  If the ticket is in the message, then maybe you don't 
need to authenticate the relays.
> - With kerberos, you trust the machine you're authenticating to.
>   That's not the case.
That's why the authentication servers would have to be run by trusted 
third parties.

Right now, authenticating a transaction across the internet is a 
challenging proposition and there are all sorts of horror stories about 
security failures due to failures of both clients and servers.  At the 
risk of telling you something you already know, https does not solve the 
problem, it merely assures that nobody in the middle between client and 
server can get involved in the transaction.  It amazes me that so much 
business is transacted over the internet.

 > 
> But your question is not bad or wrong. Your way of thinking is
> correct. 
Thank you.
> Don't stick to DNS as the holy grail. Ask what you 
> want to do and find the appropriate service.
> 
> Present your proposal about how to use kerberos and let's discuss it. 
I'm still cooking the proposal - your objections are helpful and I 
appreciate them.

My thinking is that the when the sender wish to send a message to a 
receive, he/she contacts a trusted third party in a secure way who issues 
a ticket.  This ticket is unique, and it has the IP address or IP name of 
the authentication server.  The sender then includes the ticket 
with the message.  The receiver gets the message, extracts the ticket and 
contacts the trusted third party in a secure way to verify that the ticket 
is valid.  The trusted third party validates that the ticket is valid.  
The receiver than decides on the basis of internal policy whether to 
accept the mesesage or reject the message.

If the message is authentically from a spammer, then it can be rejected.
If the trusted third party has a history of getting defrauded, it can be 
rejected and the sender can be told it has to find a new, trust worthy 
authentication agent.
If the message has no ticket, then the receiver policy will dictate 
whether to deliver the message or not.


I'm not married to kerberos - I don't understand its limitations well 
enough to say whether it is up to the assignment that I am proposing.  I 
can certainly see how to implement this idea as web based service using 
https.

 > 
> regards
> Hadmut
> 
>