Re: UNH Plugfest 5

["Julian Satran" <Julian_Satran@il.ibm.com>]

Paul,

Initiators are required to implement
authentication but may use none. If the administrator insists that authentication
must be used with redirectors too
the same administrator will have to
take care that the redirectors have the required authentication.

The standard does not have to say anything
about it..

We can't take the position of weakening
always the security of the redirector nor one of requiring everybody to
follow a stricter authetication.

Julo

Paul Koning <pkoning@equallogic.com>
Sent by: owner-ips@ece.cmu.edu

14/01/03 20:32

To	ips@ece.cmu.edu
cc
Subject	Re: UNH Plugfest 5

> "Robert D. Russell" <rdr@io.iol.unh.edu>
wrote on 14/01/2003 02:56:59:
>> ...
>> 2. If the initiator offers authentication on the first login request,
>>    and the target replies with a redirection, can that
redirection be
>>    safely believed by the initiator without first finishing
the
>>    authentication?  Probably not, which limits
the value of redirection.
>>    Could/should anything be said about this in the standard?
>>
>>
> That is an interesting point that was briefly discussed. It is not
> sure that a legitimate target would give out the "secrets"
required
> to authenticate the redirection nor that the redirector has to ahve
> all the authentication implemented. If the redirection is not
> legitimate you will learn about it one step later and you will not
> be able to get to the legitimate target anyhow.  However an
> initiator would be ill advised to change it's internal tables to
> point to a new target before validating it.  An initiator is
also at
> liberty to insist on authentication in which case the redirection
> will have to provided after authentication.
> 
> As we assume that redirection will be provided by "administrative
> entities" we did not feel that we have to be more explicit in
the
> standard and we could leave this to implementers/administrators.

I don't think that's sufficient, as this interop issue shows.

I agree with the argument that the redirector might not have the
secrets needed to do the authentication.  That's the argument for
issuing the redirect before completing the authentication.  And there
seems to be no security argument against this practice, just as you
also said.

But if that's reasonable, then the initiator is NOT "at liberty to
insist on authentication".  If it tries, then the redirector
is unable
to comply, and you have the failure that Bob described.

I don't feel it is acceptable for redirect to work only with some
initiators.  So the standard needs to be more explicit.  The
argument
you gave says to me that the initiators should be required to be more
tolerant, i.e., the rule needs to change to be "accept redirect even
without a complete authentication handshake".

The alternative is to require targets to complete the authentication
handshake before they announce a redirect -- that's a possible fix but
for some targets will be difficult to implement for the reasons you
gave.

                
paul