draft-ietf-cat-krb5gss-mech2-00.txt   draft-ietf-cat-krb5gss-mech2-01.txt 
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Comments on this document should be sent to Comments on this document should be sent to
"ietf-cat-wg@lists.stanford.edu", the IETF Common Authentication "ietf-cat-wg@lists.stanford.edu", the IETF Common Authentication
Technology WG discussion list. Technology WG discussion list.
ABSTRACT ABSTRACT
This specification defines protocols, procedures, and conventions to be This specification defines protocols, procedures, and conventions to be
employed by peers implementing the Generic Security Service Application employed by peers implementing the Generic Security Service Application
Program Interface (as specified in RFC 2078) when using Kerberos Program Interface (as specified in RFC 2078) when using Kerberos
Version 5 technology (as specified in RFC 1510). This obsoletes Version 5 technology (as specified in RFC 1510). This obsoletes
RFC 1964. [XXX not quite yet because it's still missing some sections] RFC 1964.
ACKNOWLEDGEMENTS ACKNOWLEDGEMENTS
Much of the material in this specification is based on work done for Much of the material in this specification is based on work done for
Cygnus Solutions by Marc Horowitz. Cygnus Solutions by Marc Horowitz.
1. Introduction 1. Introduction
The previous GSSAPI Kerberos V5 mechanism, described in RFC 1964, has The previous GSSAPI Kerberos V5 mechanism, described in RFC 1964, has
several flaws which make integrating new encryption types (enctypes) several flaws which make integrating new encryption types (enctypes)
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Defining all GSSAPI tokens for the new Kerberos V5 mechanism in terms of Defining all GSSAPI tokens for the new Kerberos V5 mechanism in terms of
the Kerberos protocol specification ensures that new encryption types the Kerberos protocol specification ensures that new encryption types
and checksum types may be automatically used as they are defined for the and checksum types may be automatically used as they are defined for the
Kerberos protocol. Kerberos protocol.
2. Token Formats 2. Token Formats
All tokens, not just the initial token, are framed as the All tokens, not just the initial token, are framed as the
InitialContextToken described in RFC 2078 section 3.1. The InitialContextToken described in RFC 2078 section 3.1. The
innerContextToken element of the token will not itself be encoded in innerContextToken element of the token will not itself be encoded in
ASN.1. The rationale for not using ASN.1 in the inner token is that ASN.1, with the exception of caller-provided application data. The
some implementors may wish to implement this mechanism in a kernel or rationale for avoiding the use of ASN.1 in the inner token is that some
other similarly constrained application where ASN.1 encoding may be implementors may wish to implement this mechanism in a kernel or other
similarly constrained application where full ASN.1 encoding may be
cumbersome. Also, ASN.1 encoders and decoders are very difficult to cumbersome. Also, ASN.1 encoders and decoders are very difficult to
implement completely correctly, so keeping ASN.1 usage to a minimum implement completely correctly, so keeping ASN.1 usage to a minimum
decreases the probability of bugs in the implementation of the decreases the probability of bugs in the implementation of the
mechanism. mechanism.
All integer fields are in network byte order. All other fields have the All integer fields are in network byte order. All other fields have the
fixed size shown. fixed size shown.
2.1. Packet Notation 2.1. Packet Notation
skipping to change at page 2, line 52 skipping to change at page 2, line 53
The Object Identifier (OID) of the new krb5 v2 mechanism is: The Object Identifier (OID) of the new krb5 v2 mechanism is:
{iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) {iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2)
krb5v2(3)} krb5v2(3)}
2.3. Context Establishment 2.3. Context Establishment
2.3.1. Option Format 2.3.1. Option Format
Options contained in context establishment tokens shall have the Context establishment tokens, i.e., the initial ones that the
following format: GSS_Init_sec_context() and the GSS_Accept_sec_context() calls emit while
a security context is being set up, may contain options that influence
the subsequent behavior of the context. This document describes only a
small set of options, but additional types may be added by documents
intended to supplement this one. The generic format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option type | | option type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option length | | option length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option data | | option data |
/ : / / : /
skipping to change at page 4, line 9 skipping to change at page 4, line 12
KRB-CRED length (32 bits) KRB-CRED length (32 bits)
The length in bytes of the following KRB-CRED message. The length in bytes of the following KRB-CRED message.
KRB-CRED message (variable length) KRB-CRED message (variable length)
The option data for this option shall be the KRB-CRED message that The option data for this option shall be the KRB-CRED message that
contains the credentials being delegated (forwarded) to the context contains the credentials being delegated (forwarded) to the context
acceptor. Only the initiator may use this option. acceptor. Only the initiator may use this option.
2.3.1.2. Null Option 2.3.1.2. Null Option
The Null option terminates the option list: The Null option terminates the option list, and must be used by both the
initiator and the acceptor. Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option type = 0 | | option type = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length = 0 | | length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option type (32 bits) option type (32 bits)
skipping to change at page 4, line 35 skipping to change at page 5, line 10
2.3.2. Initial Token 2.3.2. Initial Token
This is the initial token sent by the context initiator, generated by This is the initial token sent by the context initiator, generated by
GSS_Init_sec_context(). GSS_Init_sec_context().
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| initial token id | | initial token id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | | reserved flag bits |I|C|S|R|M|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum type count | | checksum type count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum type list | | checksum type list |
/ : / / : /
/ : / / : /
| checksum type list | | checksum type list |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options | | options |
/ : / / : /
skipping to change at page 5, line 9 skipping to change at page 5, line 36
| AP-REQ data | | AP-REQ data |
/ : / / : /
/ : / / : /
| AP-REQ data | | AP-REQ data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
initial token ID (32 bits) initial token ID (32 bits)
Contains the integer 0x01010101, which identifies this as the Contains the integer 0x01010101, which identifies this as the
initial token in the context setup. initial token in the context setup.
flags (32 bits) reserved flag bits (26 bits)
Context establishment flags, with values as defined by RFC 1509. These bits are reserved for future expansion. They must be set to
zero by the initiator and be ignored by the acceptor.
0 1 2 3 I flag (1 bit)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0x00000020 -- GSS_C_INTEG_FLAG
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero padding |I|C|S|R|M|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I GSS_C_INTEG_FLAG 0x00000020 C flag (1 bit)
C GSS_C_CONF_FLAG 0x00000010 0x00000010 -- GSS_C_CONF_FLAG
S GSS_C_SEQUENCE_FLAG 0x00000008
R GSS_C_REPLAY_FLAG 0x00000004
M GSS_C_MUTUAL_FLAG 0x00000002
D GSS_C_DELEG_FLAG 0x00000001
The zero padding reserves bits for future expansion. The padding S flag (1 bit)
bits shall be set to zero by the initator and ignored by the 0x00000008 -- GSS_C_SEQUENCE_FLAG
acceptor. GSS_C_DELEG_FLAG ("D" flag) must be set if the
R flag (1 bit)
0x00000004 -- GSS_C_REPLAY_FLAG
M flag (1 bit)
0x00000002 -- GSS_C_MUTUAL_FLAG
D flag (1 bit)
0x00000001 -- GSS_C_DELEG_FLAG; This flag must be set if the
"delegated credentials" option is included. "delegated credentials" option is included.
checksum type count (32 bits) checksum type count (32 bits)
The number of checksum types supported by the initiator. The number of checksum types supported by the initiator.
checksum type list (variable length) checksum type list (variable length)
A list of Kerberos checksum types, as defined in RFC 1510 A list of Kerberos checksum types, as defined in RFC 1510
section 6.4. These checksum types must be collision-proof and section 6.4. These checksum types must be collision-proof and
keyed with the context key. Each checksum type number shall be 32 keyed with the context key. Each checksum type number shall be 32
bits wide. This list should contain all the checksum types bits wide. This list should contain all the checksum types
skipping to change at page 6, line 28 skipping to change at page 7, line 20
| initiator address length | | initiator address length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| initiator address | | initiator address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acceptor address type | | acceptor address type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acceptor address length | | acceptor address length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acceptor address | | acceptor address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application data length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application data | | application data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| initial token id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | | flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum type count | | checksum type count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum type list | | checksum type list |
/ : / / : /
/ : / / : /
| checksum type list | | checksum type list |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options | | options |
/ : / / : /
/ : / / : /
| options | | options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
initiator address type (32 bits) initiator address type (32 bits)
The initiator address type, as defined in the Kerberos protocol The initiator address type, as defined in the Kerberos protocol
specification. specification. If no initiator address is provided, this must be
zero.
initiator address length (32 bits) initiator address length (32 bits)
The length in bytes of the following initiator address. The length in bytes of the following initiator address. If there
is no inititator address provided, this must be zero.
initiator address (variable length) initiator address (variable length)
The actual initiator address, in network byte order. The actual initiator address, in network byte order.
acceptor address type (32 bits) acceptor address type (32 bits)
The acceptor address type, as defined in the Kerberos protocol The acceptor address type, as defined in the Kerberos protocol
specification. specification. If no acceptor address is provided, this must be
zero.
initiator address length (32 bits) acceptor address length (32 bits)
The length in bytes of the following acceptor address. The length in bytes of the following acceptor address. This must
be zero is there is no acceptor address provided.
initiator address (variable length) initiator address (variable length)
The actual acceptor address, in network byte order. The actual acceptor address, in network byte order.
application data length (32 bits)
The length of the following application data, if provided. If no
application data are passed as input channel bindings, this length
field should be set to zero.
applicatation data (variable length) applicatation data (variable length)
The actual application data, if provided. The application data, if provided, encoded as a ASN.1 octet string
using DER. If no application data are passed as input channel
bindings, this shall be a zero-length ASN.1 octet string.
initial token ID (32 bits)
The initial token ID from the initial token.
flags (32 bits) flags (32 bits)
The context establishment flags from the initial token. The context establishment flags from the initial token.
checksum type count (32 bits) checksum type count (32 bits)
The number of checksum types supported by the initiator. The number of checksum types supported by the initiator.
checksum type list (variable length) checksum type list (variable length)
The same list of checksum types contained in the initial token. The same list of checksum types contained in the initial token.
skipping to change at page 8, line 10 skipping to change at page 9, line 10
2.3.3. Response Token 2.3.3. Response Token
This is the reponse token sent by the context acceptor, if mutual This is the reponse token sent by the context acceptor, if mutual
authentication is enabled. authentication is enabled.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| response token id | | response token id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | | reserved flag bits |D|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum type count | | checksum type count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum type list | | checksum type list |
/ : / / : /
/ : / / : /
| checksum type list | | checksum type list |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options | | options |
/ : / / : /
/ : / / : /
| options | | options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP-REP or KRB-ERROR length | | AP-REP or KRB-ERROR length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AP-REP or KRB-ERROR data | | AP-REP or KRB-ERROR data |
/ : / / : /
/ : / / : /
| AP-REP or KRB-ERROR data | | AP-REP or KRB-ERROR data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum type | | MIC length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum data | | MIC data |
/ : / / : /
/ : / / : /
| checksum data | | MIC data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
response token id (32 bits) response token id (32 bits)
Contains the integer 0x02020202, which identifies this as the Contains the integer 0x02020202, which identifies this as the
response token in the context setup. response token in the context setup.
flags (32 bits) reserved flag bits (30 bits)
This currently is defined to only contain one flag, the error flag, These bits are reserved for future expansion. They must be set to
which has a value of 0x00000001. If this flag is set, then the zero by the acceptor and be ignored by the initiator.
last field contains a KRB-ERROR message, otherwise, it contains an
AP-REP message. The other bits in the flags field are reserved; D flag -- delegated creds accepted (1 bit)
they should be set to zero by the acceptor and ignored by the 0x00000002 -- If this flag is set, the acceptor processed the
initiator. delegated credentials, and GSS_C_DELEG_FLAG should be returned to
the caller.
E flag -- error (1 bit)
0x00000001 -- If this flag is set, a KRB-ERROR message shall be
present, rather than an AP-REP message. If this flag is not set,
an AP-REP message shall be present.
checksum type count (32 bits) checksum type count (32 bits)
The number of checksum types supported by both the initiator and The number of checksum types supported by both the initiator and
the acceptor. the acceptor.
checksum type list (variable length) checksum type list (variable length)
A list of Kerberos checksum types, as defined in RFC 1510 A list of Kerberos checksum types, as defined in RFC 1510
section 6.4. These checksum types must be collision-proof and section 6.4. These checksum types must be collision-proof and
keyed with the context key. Each checksum type number shall be 32 keyed with the context key. Each checksum type number shall be 32
bits wide. This list should contain the intersection of the list bits wide. This list should contain the intersection of the list
of checksum types specified by the initiator in the initial token of checksum types specified by the initiator in the initial token
and the list of checksum types supported by the acceptor. and the list of checksum types supported by the acceptor.
options (variable length) options (variable length)
The option list, as described earlier. At this time, no options The option list, as described earlier. At this time, no options
are defined, but an implementation might make use of these options are defined for the acceptor, but an implementation might make use
to acknowledge an option from the initial token. After all the of these options to acknowledge an option from the initial token.
options are specified, a null option must be used to terminate the After all the options are specified, a null option must be used to
list. terminate the list.
AP-REP or KRB-ERROR length (32 bits) AP-REP or KRB-ERROR length (32 bits)
Depending on the value of the error flag, length in bytes of the Depending on the value of the error flag, length in bytes of the
AP-REP or KRB-ERROR message. AP-REP or KRB-ERROR message.
AP-REP or KRB-ERROR data (variable length) AP-REP or KRB-ERROR data (variable length)
Depending on the value of the error flag, the AP-REP or KRB-ERROR Depending on the value of the error flag, the AP-REP or KRB-ERROR
message as described in RFC 1510. If this field contains an AP-REP message as described in RFC 1510. If this field contains an AP-REP
message, the sequence number field in the AP-REP shall be filled. message, the sequence number field in the AP-REP shall be filled.
If this is a KRB-ERROR message, no further fields will be in this If this is a KRB-ERROR message, no further fields will be in this
message. message.
checksum type (32 bits) MIC length (32 bits)
A Kerberos checksum type, as defined in RFC 1510 section 6.4. This The number of bytes in the following MIC data field.
checksum type must be collision-proof and keyed with the context
key. The checksum type implies the length of the checksum data.
checksum length (32 bits)
The number of bytes in the following checksum data field.
checksum data (variable length) MIC data (variable length)
The checksum itself, as defined in RFC 1510 section 6.4, computed A MIC token, as described in section 2.4.2, computed over the
over the concatenation of the flags and the options. XXX does this concatentation of the response token ID, flags, checksum length and
need a new key usage as well? type fields, and all option fields. This field and the preceding
length field must not be present if the error flag is set.
2.4. Per-message Tokens 2.4. Per-message Tokens
2.4.1. Sequence Number Usage Sequence numbers for per-message tokens 2.4.1. Sequence Number Usage
are 32 bit unsigned integers, which are incremented by 1 after each
token. An overflow condition should result in a wraparound of the Sequence numbers for per-message tokens are 32 bit unsigned integers,
sequence number to zero. The initiator and acceptor each keep their own which are incremented by 1 after each token. An overflow condition
sequence numbers per connection. should result in a wraparound of the sequence number to zero. The
initiator and acceptor each keep their own sequence numbers per
connection.
2.4.2. MIC Token 2.4.2. MIC Token
Use of the GSS_GetMIC() call yields a token, separate from the user data Use of the GSS_GetMIC() call yields a token, separate from the user data
being protected, which can be used to verify the integrity of that data being protected, which can be used to verify the integrity of that data
when it is received. The MIC token has the following format: when it is received. The MIC token has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 46 skipping to change at page 11, line 46
checksum type (32 bits) checksum type (32 bits)
A Kerberos checksum type, as defined in RFC 1510 section 6.4. This A Kerberos checksum type, as defined in RFC 1510 section 6.4. This
checksum type must be collision-proof and keyed with the context checksum type must be collision-proof and keyed with the context
key. key.
checksum length (32 bits) checksum length (32 bits)
The number of bytes in the following checksum data field. The number of bytes in the following checksum data field.
checksum data (variable length) checksum data (variable length)
The checksum itself, as defined in RFC 1510 section 6.4. The The checksum itself, as defined in RFC 1510 section 6.4. The
checksum is calculated as in the following section. checksum is calculated over the encoding described in the following
section. The key usage GSS_TOK_MIC -- 22 [XXX need to register
XXX A kerberos key usage needs to be registered for generating MIC this] shall be used.
tokens.
The mechanism implementation should only use checksum types which it The mechanism implementation should only use checksum types which it
knows to be valid for both peers. If mutual authentication is used, knows to be valid for both peers. If mutual authentication is used,
then any checksum type specified by the acceptor may be used. If mutual then any checksum type specified by the acceptor may be used. If mutual
authentication is not used XXX what do we do then? This seems to be a authentication is not used XXX what do we do then? This seems to be a
more general issue than just GSSAPI. What checksum type did we use for more general issue than just GSSAPI. What checksum type did we use for
the authenticator checksum? the authenticator checksum?
2.4.2.1. Data to be Checksummed in MIC Token The checksum in the MIC 2.4.2.1. Data to be Checksummed in MIC Token
token shall be calculated over the following elements.
The checksum in the MIC token shall be calculated over the following
elements. This set of data is not actually included in the token as is;
the description only appears for the purpose of specifying the method of
calculating the checksum.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIC token id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number | | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| direction | | direction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application data | | application data |
/ : / / : /
/ : / / : /
| application data | | application data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MIC token ID (32 bits)
The MIC token ID from the MIC message.
sequence number (32 bits) sequence number (32 bits)
The sequence number. The sequence number.
direction (32 bits) direction (32 bits)
All bits in this field shall be zero if the message is sent from All bits in this field shall be zero if the message is sent from
the context initiator. If the message is sent from the context the context initiator. If the message is sent from the context
acceptor, all bits shall be one. acceptor, all bits shall be one.
application data (variable length) application data (variable length)
The application-supplied data. The application-supplied data, encoded as an ASN.1 octet string
using DER.
2.4.3. Wrap Token 2.4.3. Wrap Token
Use of the GSS_Wrap() call yields a token which encapsulates the input Use of the GSS_Wrap() call yields a token which encapsulates the input
user data (optionally encrypted) along with associated integrity check user data (optionally encrypted) along with associated integrity check
quantities. quantities.
2.4.3.1. Wrap Token With Integrity Only 2.4.3.1. Wrap Token With Integrity Only
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| integrity wrap token id | | integrity wrap token id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number | | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| direction | | direction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application data length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application data | | application data |
/ : / / : /
/ : / / : /
| application data | | application data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum type | | checksum type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum length | | checksum length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum data | | checksum data |
skipping to change at page 12, line 42 skipping to change at page 13, line 40
token with integrity only. token with integrity only.
sequence number (32 bits) sequence number (32 bits)
The sequence number. The sequence number.
direction (32 bits) direction (32 bits)
All bits in this field shall be zero if the message is sent from All bits in this field shall be zero if the message is sent from
the context initiator. If the message is sent from the context the context initiator. If the message is sent from the context
acceptor, all bits shall be one. acceptor, all bits shall be one.
application data length (32 bits)
The number of bytes in the following application data field.
application data (variable length) application data (variable length)
The application-supplied data. The application-supplied data, encoded as an ASN.1 octet string
using DER.
checksum type (32 bits) checksum type (32 bits)
A Kerberos checksum type, as defined in RFC 1510 section 6.4. This A Kerberos checksum type, as defined in RFC 1510 section 6.4. This
checksum type must be collision-proof and keyed with the context checksum type must be collision-proof and keyed with the context
key. The checksum type implies the length of the checksum data. key. The checksum type implies the length of the checksum data.
checksum length (32 bits) checksum length (32 bits)
The number of bytes in the following checksum data field. The number of bytes in the following checksum data field.
checksum data (variable length) checksum data (variable length)
The checksum itself, as defined in RFC 1510 section 6.4, computed The checksum itself, as defined in RFC 1510 section 6.4, computed
over the concatenation of the sequence number, direction field, and over the concatenation of the token ID, sequence number, direction
application data, as in the MIC token checksum in the previous field, application data length, and application data, as in the MIC
section. token checksum in the previous section. The key usage
GSS_TOK_WRAP_INTEG -- 23 [XXX need to register this] shall be used.
The mechanism implementation should only use checksum types which it The mechanism implementation should only use checksum types which it
knows to be valid for both peers, as described for MIC tokens. knows to be valid for both peers, as described for MIC tokens.
2.4.3.2. Wrap Token With Integrity and Encryption 2.4.3.2. Wrap Token With Integrity and Encryption
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encrypted wrap token id | | encrypted wrap token id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encrypted data length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encrypted data | | encrypted data |
/ : / / : /
/ : / / : /
| encrypted data | | encrypted data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
encrypted wrap token id (32 bits) encrypted wrap token id (32 bits)
Contains the integer 0x05050505, which identifies this as a Wrap Contains the integer 0x05050505, which identifies this as a Wrap
token with integrity and encryption. token with integrity and encryption.
encrypted data length (32 bits) encrypted data length (32 bits)
The number of bytes in the following encrypted data field. The number of bytes in the following encrypted data field.
encrypted data (variable length) encrypted data (variable length)
The encrypted data itself, as defined in RFC 1510 section 6.3. The The encrypted data itself, as defined in RFC 1510 section 6.3.
encryption is performed using the key/enctype exchanged during Note that this is not the ASN.1 type EncryptedData as defined in
context setup. The actual data to be encrypted are specified RFC 1510 section 6.1, but rather the bare ciphertext without
framing, encryption type, or kvno information. The encryption is
performed using the key/enctype exchanged during context setup.
The key usage GSS_TOK_WRAP_PRIV -- 24 [XXX need to register this]
shall be used. The actual data to be encrypted are specified
below. below.
2.4.3.2.1. Data to be Encrypted in Wrap Token 2.4.3.2.1. Data to be Encrypted in Wrap Token
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number | | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| direction | | direction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application data length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application data | | application data |
/ : / / : /
/ : / / : /
| application data | | application data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
sequence number (32 bits) sequence number (32 bits)
The sequence number. The sequence number.
direction (32 bits) direction (32 bits)
All bits in this field shall be zero if the message is sent from All bits in this field shall be zero if the message is sent from
the context initiator. If the message is sent from the context the context initiator. If the message is sent from the context
acceptor, all bits shall be one. acceptor, all bits shall be one.
application data length (32 bits)
The number of bytes in the following application data field.
application data (variable length) application data (variable length)
The application-supplied data. The application-supplied data, encoded as an ASN.1 octet string
using DER.
XXX Two kerberos key usages need to be registered, one for integrity- 3. ASN.1 Encoding of Octet Strings
only tokens, and one for integrity-and-encryption tokens.
3. Kerberos Protocol Dependencies This protocol makes several In order to encode arbitirarly-sized application data, ASN.1 octet
assumptions about the Kerberos protocol, which may require changes to string encoding is in this protocol. The Distinguished Encoding Rules
the successor of RFC 1510. (DER) shall always be used in such cases. For reference purposes, the
DER encoding of an ASN.1 octet string, adapted from ISO/IEC 8825-1,
follows:
+--------+-------//-------+-------//-------+
|00000100| length octets |contents octets |
+--------+-------//-------+-------//-------+
|
+-- identifier octet = 0x04 = [UNIVERSAL 4]
In this section only, the bits in each octet shall be numbered as in the
ASN.1 specification, from 8 to 1, with bit 8 being the MSB of the octet,
and with bit 1 being the LSB of the octet.
identifier octet (8 bits)
Contains the constant 0x04, the tag for primitive encoding of an
octet string with the default (UNIVERSAL 4) tag.
length octets (variable length)
Contains the length of the contents octets, in definite form (since
this encoding uses DER).
contents octets (variable length)
The contents of the octet string.
The length octets shall consist of either a short form (one byte only),
which is to be used only if the number of octets in the contents octets
is less than or equal to 127, or a long form, which is to be used in all
other cases. The short form shall consist of a single octet with bit 8
(the MSB) equal to zero, and the remaining bits encoding the number of
contents octets (which may be zero) as an unsigned binary integer.
The long form shall consist of an initial octet and one or more
subsequent octets. The first octet shall have bit 8 (the MSB) set to
one, and the remaining bits shall encode the number of subsequent octets
in the length encoding as an unsigned binary integer. The length must
be encoded in the minimum number of octets. An initial octet of 0xFF is
reserved by the ASN.1 specification. Bits 8 to 1 of the first
subsequent octet, followed by bits 8 to 1 of each subsequent octet in
order, shall be the encoding of an unsigned binary integer, with bit 8
of the first octet being the most significant bit. Thus, the length
encoding within is in network byte order.
An initial length octet of 0x80 shall not be used, as that is reserved
by the ASN.1 specification for indefinite lengths in conjunction with
constructed contents encodings, which are not to be used with DER.
4. Name Types
The name types and forms for this mechanism will be basically identical
to those specified in RFC 1964. The actual text describing these will
be included later.
5. Kerberos Protocol Dependencies
This protocol makes several assumptions about the Kerberos protocol,
which may require changes to the successor of RFC 1510.
Sequence numbers, checksum types, and address types are assumed to be no Sequence numbers, checksum types, and address types are assumed to be no
wider than 32 bits. The Kerberos protocol specification might need to wider than 32 bits. The Kerberos protocol specification might need to
be modified to accomodate this. This obviously requires some further be modified to accomodate this. This obviously requires some further
discussion. discussion.
Key usages need to be registered within the Kerberos protocol for use Key usages need to be registered within the Kerberos protocol for use
with GSSAPI per-message tokens. One may also need to be registered for with GSSAPI per-message tokens. The current specification of the
the checksum in the reply token during context establishment. Kerberos protocol does not include descriptions of key derivations or
key usages, but planned revisions to the protocol will include them.
This protocol also makes the assumption that any cryptosystem used with This protocol also makes the assumption that any cryptosystem used with
the session key will include integrity protection, i.e., it assumes that the session key will include integrity protection, i.e., it assumes that
no "raw" cryptosystems will be used. no "raw" cryptosystems will be used.
4. Security Considerations The GSSAPI is a security protocol; 6. Security Considerations
therefore, security considerations are discussed throughout this
document. The old Kerberos 5 GSSAPI mechanism's constraints on possible
cryptosystems and checksum types do not permit it to be readily expanded
to accomodate more secure technologies with larger checksums or The GSSAPI is a security protocol; therefore, security considerations
encryption block sizes. Sites are strongly encouraged to adopt the are discussed throughout this document. The old Kerberos 5 GSSAPI
mechanism specified in this document in the light of recent publicity mechanism's constraints on possible cryptosystems and checksum types do
about the deficiencies of DES. not permit it to be readily extended to accomodate more secure
cryptographic technologies with larger checksums or encryption block
sizes. Sites are strongly encouraged to adopt the mechanism specified
in this document in the light of recent publicity about the deficiencies
of DES.
5. References 7. References
[ISOIEC8824-1:1995] ISO/IEC, "Information technology -- Abstract Syntax
Notation One (ASN.1): Specification of basic notation",
ISO/IEC 8824-1:1995.
[ISOIEC8825-1:1995] ISO/IEC, "Information technology -- ASN.1 encoding
rules: Specification of Basic Encoding Rules (BER), Canonical Encoding
Rules (CER) and Distinguished Encoding Rules (DER)",
ISO/IEC 8825-1:1995.
[RFC1510] Kohl, J., Neumann, C., "The Kerberos Network Authentication [RFC1510] Kohl, J., Neumann, C., "The Kerberos Network Authentication
Service (V5)", RFC 1510. Service (V5)", RFC 1510.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964. RFC 1964.
[RFC2078] Linn, J., "Generic Security Service Application Program [RFC2078] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078 Interface, Version 2", RFC 2078
6. Author's Address 8. Author's Address
Tom Yu Tom Yu
Massachusetts Institute of Technology Massachusetts Institute of Technology
Room E40-345 Room E40-345
77 Massachusetts Avenue 77 Massachusetts Avenue
Cambridge, MA 02139 Cambridge, MA 02139
USA USA
email: tlyu@mit.edu email: tlyu@mit.edu
phone: +1 617 253 1753 phone: +1 617 253 1753
 End of changes. 48 change blocks. 
114 lines changed or deleted 201 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/