7 .ds LF Westerlund, Danielsson
12 .ds CH Kerberos over TCP
18 Network Working Group Assar Westerlund
19 <draft-ietf-cat-krb5-tcp.txt> SICS
20 Internet-Draft Johan Danielsson
21 November, 1997 PDC, KTH
32 This document is an Internet-Draft. Internet-Drafts are working
33 documents of the Internet Engineering Task Force (IETF), its
34 areas, and its working groups. Note that other groups may also
35 distribute working documents as Internet-Drafts.
37 Internet-Drafts are draft documents valid for a maximum of six
38 months and may be updated, replaced, or obsoleted by other
39 documents at any time. It is inappropriate to use Internet-
40 Drafts as reference material or to cite them other than as
43 To view the entire list of current Internet-Drafts, please check
44 the "1id-abstracts.txt" listing contained in the Internet-Drafts
45 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
46 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
47 Coast), or ftp.isi.edu (US West Coast).
49 Distribution of this memo is unlimited. Please send comments to the
50 <cat-ietf@mit.edu> mailing list.
56 This document specifies how the communication should be done between a
57 client and a KDC using Kerberos [RFC1510] with TCP as the transport
63 This draft specifies an extension to section 8.2.1 of RFC1510.
65 A Kerberos server MAY accept requests on TCP port 88 (decimal).
67 The data sent from the client to the KDC should consist of 4 bytes
68 containing the length, in network byte order, of the Kerberos request,
69 followed by the request (AS-REQ or TGS-REQ) itself. The reply from
70 the KDC should consist of the length of the reply packet (4 bytes,
71 network byte order) followed by the packet itself (AS-REP, TGS-REP, or
75 C->S: Open connection to TCP port 88 at the server
76 C->S: length of request
77 C->S: AS-REQ or TGS-REQ
79 S->C: AS-REP, TGS-REP, or KRB-ERROR
85 Even though the preferred way of sending kerberos packets is over UDP
86 there are several occasions when it's more practical to use TCP.
88 Mainly, it's usually much less cumbersome to get TCP through firewalls
91 In theory, there's no reason for having explicit length fields, that
92 information is already encoded in the ASN1 encoding of the Kerberos
93 packets. But having explicit lengths makes it unnecessary to have to
94 decode the ASN.1 encoding just to know how much data has to be read.
96 Another way of signaling the end of the request of the reply would be
97 to do a half-close after the request and a full-close after the reply.
98 This does not work well with all kinds of firewalls.
101 Security considerations
104 This memo does not introduce any known security considerations in
105 addition to those mentioned in [RFC1510].
111 [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
112 Authentication Service (V5)", RFC 1510, September 1993.
119 Swedish Institute of Computer Science
145 EMail: joda@pdc.kth.se