oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

x

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@4045 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Johan Danielsson
1997-11-20 01:18:20 +00:00
parent 7ade4e9e4b
commit aab09ed04a
2 changed files with 40 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
doc/draft-foo2.ms
View File

@@ -14,11 +14,13 @@
.ad l .ad l
.in 0 .in 0
.ta \n(.luR .ta \n(.luR
.nf
Network Working Group Assar Westerlund Network Working Group Assar Westerlund
<draft-ietf-cat-krb5-tcp.txt> SICS <draft-ietf-cat-krb5-tcp.txt> SICS
Internet-Draft Johan Danielsson Internet-Draft Johan Danielsson
October, 1997 PDC, KTH November, 1997 PDC, KTH
Expire in six months Expire in six months
.fi
.ce .ce
Kerberos over TCP Kerberos over TCP
@@ -58,25 +60,24 @@ protocol.
.ti 0 .ti 0
Specification Specification
A Kerberos server MAY accepts requests on port 88 (decimal). 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 The data sent from the client to the KDC should consist of 4 bytes
containting the length Kerberos request in network byte order and then containing the length, in network byte order, of the Kerberos request,
the request (AS-REQ or TGS-REQ) itself. The reply from the KDC should followed by the request (AS-REQ or TGS-REQ) itself. The reply from
consist of the length of the reply packet in network byte order the KDC should consist of the length of the reply packet (4 bytes,
followed by the packet itself (AS-REP, TGS-REP, or KRB-ERROR). network byte order) followed by the packet itself (AS-REP, TGS-REP, or
KRB-ERROR).
C->S: Open connection to port 88 at the server .nf
.br C->S: Open connection to TCP port 88 at the server
C->S: length of request [as 4 bytes in network byte order ] C->S: length of request
.br
C->S: AS-REQ or TGS-REQ C->S: AS-REQ or TGS-REQ
.br S->C: length of reply
S->C: length of reply [as 4 bytes in network byte order ]
.br
S->C: AS-REP, TGS-REP, or KRB-ERROR S->C: AS-REP, TGS-REP, or KRB-ERROR
.br .fi
: connection is closed
.ti 0 .ti 0
Discussion Discussion
@@ -90,12 +91,11 @@ than UDP.
In theory, there's no reason for having explicit length fields, that In theory, there's no reason for having explicit length fields, that
information is already encoded in the ASN1 encoding of the Kerberos information is already encoded in the ASN1 encoding of the Kerberos
packets. But having explicit lengths makes it unnecessary to have to packets. But having explicit lengths makes it unnecessary to have to
decode the ASN1 encoding just to know how much data has to be read. 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 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 to do a half-close after the request and a full-close after the reply.
reply. This does not work well with all kind of firewalls so the This does not work well with all kinds of firewalls.
simpler and more robust solution of explicit length fields.
.ti 0 .ti 0
Security considerations Security considerations

38
doc/standardisation/draft-foo2.ms
View File

@@ -14,11 +14,13 @@
.ad l .ad l
.in 0 .in 0
.ta \n(.luR .ta \n(.luR
.nf
Network Working Group Assar Westerlund Network Working Group Assar Westerlund
<draft-ietf-cat-krb5-tcp.txt> SICS <draft-ietf-cat-krb5-tcp.txt> SICS
Internet-Draft Johan Danielsson Internet-Draft Johan Danielsson
October, 1997 PDC, KTH November, 1997 PDC, KTH
Expire in six months Expire in six months
.fi
.ce .ce
Kerberos over TCP Kerberos over TCP
@@ -58,25 +60,24 @@ protocol.
.ti 0 .ti 0
Specification Specification
A Kerberos server MAY accepts requests on port 88 (decimal). 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 The data sent from the client to the KDC should consist of 4 bytes
containting the length Kerberos request in network byte order and then containing the length, in network byte order, of the Kerberos request,
the request (AS-REQ or TGS-REQ) itself. The reply from the KDC should followed by the request (AS-REQ or TGS-REQ) itself. The reply from
consist of the length of the reply packet in network byte order the KDC should consist of the length of the reply packet (4 bytes,
followed by the packet itself (AS-REP, TGS-REP, or KRB-ERROR). network byte order) followed by the packet itself (AS-REP, TGS-REP, or
KRB-ERROR).
C->S: Open connection to port 88 at the server .nf
.br C->S: Open connection to TCP port 88 at the server
C->S: length of request [as 4 bytes in network byte order ] C->S: length of request
.br
C->S: AS-REQ or TGS-REQ C->S: AS-REQ or TGS-REQ
.br S->C: length of reply
S->C: length of reply [as 4 bytes in network byte order ]
.br
S->C: AS-REP, TGS-REP, or KRB-ERROR S->C: AS-REP, TGS-REP, or KRB-ERROR
.br .fi
: connection is closed
.ti 0 .ti 0
Discussion Discussion
@@ -90,12 +91,11 @@ than UDP.
In theory, there's no reason for having explicit length fields, that In theory, there's no reason for having explicit length fields, that
information is already encoded in the ASN1 encoding of the Kerberos information is already encoded in the ASN1 encoding of the Kerberos
packets. But having explicit lengths makes it unnecessary to have to packets. But having explicit lengths makes it unnecessary to have to
decode the ASN1 encoding just to know how much data has to be read. 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 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 to do a half-close after the request and a full-close after the reply.
reply. This does not work well with all kind of firewalls so the This does not work well with all kinds of firewalls.
simpler and more robust solution of explicit length fields.
.ti 0 .ti 0
Security considerations Security considerations