[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue with GSSAPI and the ISAKMP/Oakley resolution document

Hi all,

	My apologies for not having a chance to look at this sooner, but
Morton's law has unfortunately been applying in my life --- when it
rains, it pours....

	I've been looking over the GSSAPI authentication in the
ISAKMP/Oakley document, and I think there's a potential problem in that
the text appears to assume that a GSSAPI exchange is a single
round-trip.  In fact, a GSSAPI mechanism can have any number of whole
(or a half) round trip.  So if hosts A and B are engaging in a GSSAPI
exchange, all of the following might happen, depending on the GSSAPI
mechanism:

	A --> B

	A --> B		B --> A

	A --> B		B --> A		A --> B		

	A --> B		B --> A		A --> B		B --> A

		etc.

The text seems to presume the second case above, which is A sends a
token to B, and then B sends a token back to A.  

	However, this is not general enough.  In fact, Mike Swift from
Microsoft just submitted a GSSAPI mechanism for supporting Kerberos 5
user-to-user authentication which requires two full round trips of token
exchanges (draft-ietf-cat-user2user-00.txt).  

	This may simply require a simple textual fix to the GSSAPI
section of ISAKMP/Oakley.  However, the fix may be more complex than
that, since the ISAKMP/Oakley document appears to assume a fixed number
of round-trips, and the GSSAPI mechanism violates this assumption.

							- Ted