Subject: Re: FW: I-D ACTION:draft-zhu-ws-kerb-00.txt

From: Jeffrey Altman <[email-masked]>
Date: Mon, 06 Nov 2006 07:50:00 -0800

I believe there is a significant need for a Web Proxy protocol for
obtaining Kerberos tickets.  The question that I have is whether or
not this protocol would solve the deployment problems that have resulted
in port 88/udp, 88/tcp being blocked by firewalls in the first place.

Many of us with operational experience in the academic sector are
used to maintaining open access to our KDCs.  However, many in the
commercial and government sectors refuse to because they want to limit
the attacks against their KDCs.  They want to prevent DoS attacks,
prevent potentially untrusted clients from sending the KDCs a specially
crafted request that might be able to take advantage of perhaps yet
unknown vulnerability, and even restrict the ability to probe the KDCs
for valid principal names.

The protocol you describe provides a proxy service but I do not see
how it addresses the issues that have lead to the KDC requiring a proxy
in the first place.  Why would an administrator be willing to deploy
this proxy protocol when they are not willing to allow external access
to the KDC?

One of the things that I have seen a need for is a HTTP proxy for
Kerberos requests.  Do you foresee your proposed protocol being used
within a HTTP exchange?

It would be helpful to me if you could explain when you expect this
protocol to be used.

Jeffrey Altman

Liqiang(Larry) Zhu wrote:
>  
> resending per Doug's suggestion . 
>  
> http://www.ietf.org/internet-drafts/draft-zhu-ws-kerb-00.txt
>  
> 
> ------------------------------------------------------------------------
> *From:* Douglas E. Engert [mailto:[email-masked]]
> *Sent:* Wed 10/18/2006 7:44 AM
> *To:* Liqiang(Larry) Zhu
> *Subject:* Re: FW: I-D ACTION:draft-zhu-ws-kerb-00.txt
> 
> Larry,
> There were a number of bounced messages on the ietf-krb-wg
> list because of your attachment named draft-zhu-ws-kerb-00.URL
> 
> These sites won't accept .URL as an attachment. You may want to send
> it again as .txt or don't send it as an attachment, but just a url
> refference.
> 
> 
> 
> Liqiang(Larry) Zhu wrote:
>> Fyi.
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Tuesday, October 17, 2006 12:50 PM
>> To: [email-masked]
>> Subject: I-D ACTION:draft-zhu-ws-kerb-00.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>       Title           : Kerberos for Web Services
>>       Author(s)       : L. Zhu
>>       Filename        : draft-zhu-ws-kerb-00.txt
>>       Pages           : 9
>>       Date            : 2006-10-17
>>      
>>    This document defines extensions to the Kerberos protocol and the
>>    GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
>>    exchange messages with the KDC using the GSS-API server as the proxy,
>>    by encapsulating the Kerberos messages inside GSS-API tokens.  With
>>    these extensions, Kerberos is suitable for securing communication
>>    between the client and web services over the Internet
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-zhu-ws-kerb-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-zhu-ws-kerb-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>       [email-masked].
>> In the body type:
>>       "FILE /internet-drafts/draft-zhu-ws-kerb-00.txt".
>>      
>> NOTE: The mail server at ietf.org can return the document in
>>       MIME-encoded form by using the "mpack" utility.  To use this
>>       feature, insert the command "ENCODING mime" before the "FILE"
>>       command.  To decode the response(s), you will need "munpack" or
>>       a MIME-compliant mail reader.  Different MIME-compliant mail
>> readers
>>       exhibit different behavior, especially when dealing with
>>       "multipart" MIME messages (i.e. documents which have been split
>>       up into multiple messages), so check your local documentation on
>>       how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 
> --
> 
>   Douglas E. Engert  <[email-masked]>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
>

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 8 Nov 2006 16:18:04 -0800

Heimdal solves this issue in one way, without this mechanism, we need to solve the same problem for RAS/EAP perhaps in a different way, what is the end?  
 
It is a good thing if we can solve this problem in a generic way.
 
-- Larry

________________________________

From: Andrew Bartlett [mailto:[email-masked]]
Sent: Wed 11/8/2006 4:01 PM
To: [email-masked]
Cc: Liqiang(Larry) Zhu; [email-masked]
Subject: Re: FW: I-D ACTION:draft-zhu-ws-kerb-00.txt

> in port 88/udp, 88/tcp being blocked by firewalls in the first place.

It would bypass potentially overly restrictive firewalls on client
networks, that are perhaps not even aware that kerberos may be wanted or
used on the wider internet.

This may or may not be a good thing, but I note that Heimdal allows
itself to listen on port 80, as a KDC, to get around such 'interesting'
networks.  (Such as, i presume, wireless hotspots and other such
inflexible networks).

For similar reasons, there are SSH servers found on port 443...

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org <http://samba.org/> 
Samba Developer, Red Hat Inc.                  http://redhat.com <http://redhat.com/>

---

From: Andrew Bartlett <[email-masked]>
Date: Thu, 09 Nov 2006 11:27:41 +1100

On Wed, 2006-11-08 at 16:18 -0800, Liqiang(Larry) Zhu wrote:
>  
>  Heimdal solves this issue in one way, without this mechanism, we need
> to solve the same problem for RAS/EAP perhaps in a different way, what
> is the end?  
>  

Indeed.  My point was more to illustrate that the 'port 88 blocked' is
not always an issue with the server's network, but with the client's,
and to follow up by noting that their is clearly some existing, real
world need for this.

I agree, some standardisation of the solution would be nice.  

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

---

From: Andrew Bartlett <[email-masked]>
Date: Thu, 09 Nov 2006 11:01:36 +1100

Andrew Bartlett