1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
Network Working Group Assar Westerlund
<draft-ietf-cat-krb5-tcp.txt> SICS
Internet-Draft Johan Danielsson
November, 1997 PDC, KTH
Expire in six months
Kerberos over TCP
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list.
Abstract
This document specifies how the communication should be done between
a client and a KDC using Kerberos [RFC1510] with TCP as the transport
protocol.
Specification
This draft specifies an extension to section 8.2.1 of RFC1510.
A Kerberos server MAY accept requests on TCP port 88 (decimal).
The data sent from the client to the KDC should consist of 4 bytes
containing the length, in network byte order, of the Kerberos
request, followed by the request (AS-REQ or TGS-REQ) itself. The
reply from the KDC should consist of the length of the reply packet
(4 bytes, network byte order) followed by the packet itself (AS-REP,
TGS-REP, or KRB-ERROR).
Westerlund, Danielsson [Page 1]
Internet Draft Kerberos over TCP November, 1997
C->S: Open connection to TCP port 88 at the server
C->S: length of request
C->S: AS-REQ or TGS-REQ
S->C: length of reply
S->C: AS-REP, TGS-REP, or KRB-ERROR
Discussion
Even though the preferred way of sending kerberos packets is over UDP
there are several occasions when it's more practical to use TCP.
Mainly, it's usually much less cumbersome to get TCP through
firewalls than UDP.
In theory, there's no reason for having explicit length fields, that
information is already encoded in the ASN1 encoding of the Kerberos
packets. But having explicit lengths makes it unnecessary to have to
decode the ASN.1 encoding just to know how much data has to be read.
Another way of signaling the end of the request of the reply would be
to do a half-close after the request and a full-close after the
reply. This does not work well with all kinds of firewalls.
Security considerations
This memo does not introduce any known security considerations in
addition to those mentioned in [RFC1510].
References
[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
Authors' Addresses
Assar Westerlund
Swedish Institute of Computer Science
Box 1263
S-164 29 KISTA
Sweden
Phone: +46-8-7521526
Fax: +46-8-7517230
EMail: assar@sics.se
Johan Danielsson
PDC, KTH
S-100 44 STOCKHOLM
Westerlund, Danielsson [Page 2]
Internet Draft Kerberos over TCP November, 1997
Sweden
Phone: +46-8-7907885
Fax: +46-8-247784
EMail: joda@pdc.kth.se
Westerlund, Danielsson [Page 3]
|
