Kerberos authentication for Web Services

[Nicolas Williams]

On Mon, Jul 08, 2002 at 03:20:36PM -0400, Ken Hornstein wrote:
> I believe Sam Hartman already pointed out that generating a new network
> protocol to communicate with the KDC is a Really Bad Idea.  In general,
> that part of Kerberos is supposed to be invisible to you.  You could
> do that (I believe you said you wanted to avoid firewalls), but you
> would be making yourself not interoperate with all of the existing code
> that's already out there.

It's possible that jredburn at wso.williams.edu is confusing KDC and AP
exchanges.

It's also possible that he wants to tunnel KDC exchanges through a web
proxy or perhaps he's thinking of something along the lines of IAKERB
(i.e., proxying the KDC exchange through the service to which the client
is authenticating). I can't imagine that he really wants SOAP/XML
replacements for the RFC15010 messages.

The latter might be useful in their own right. Tunneling KDC exchanges
should be doable provided that no ticket addresses are used and provided
that an encapsulation for the KDC exchanges over the tunnel protocol
exists. And something like IAKERB outside the context of GSS-API might
also be useful (MS seems to think IAKERB is useful, for one).

But the questions that have been asked here about Kerberos and SOAP
seem to indicate a desire to write a new KDC exchange protocol in terms
of SOAP and XML - ugh!

> --Ken


Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.