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

RE: Issue with GSSAPI and the ISAKMP/Oakley resolution document

I agree with Ted's point about the variable-hop issue.  I'll also
observe a couple of other specific clarifications wrt the GSSAPI
integration as discussed:

Page 10 states:

   For authentication using GSSAPI, the GSSAPI package on either side
   provides authentication of the GSSAPI identities, and HASH_I and
   HASH_R are used to bind the GSSAPI identities and tokens to the Main
   Mode exchange.  Each side MUST specify the GSS_C_MUTUAL_FLAG to
   request mutual authentication between the two GSSAPI packages.  A
   provision is defined for the GSSAPI peers to exchange GSSAPI
   identities during Main Mode, at the expense of identity protection
   for the GSSAPI endpoint identities.

The GSS_C_MUTUAL_FLAG is input only by the context initiator (to solicit
a mutual authentication response from the target), not by the target.

Page 16 states:

  If the GSSAPI requires that the initiator and responder have prior
   knowledge of the GSSAPI endpoint names for each peer, this
   information may be exchanged during the first round trip (by
   including the GSS Identity Name attribute in the SA) at the expense
   of identity protection for the GSSAPI endpoints. When the GSSAPI
   requires the exchange of identity names, Aggressive Mode cannot be
   used.

Any GSSAPI context initiator must have prior knowledge of the name of
the target to which it's initiating a context, in order to input that
name to GSS_Init_sec_context(). GSSAPI doesn't require that a target
have prior knowledge of the name of an initiator which is establishing a
context to it; instead, the initiator's name is delivered to the target
as a result of context establishment.

--jl

John Linn, writing as an individual from
RSA Laboratories East, Bedford, MA, USA

> ----------
> From: 	Theodore Y. Ts'o[SMTP:tytso@MIT.EDU]
> Sent: 	Tuesday, October 28, 1997 6:50 PM
> To: 	ipsec@tis.com
> Subject: 	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
>