RE: FW: Redirection (was UNH Plugfest 5)

["Rod Harrison" <rod.harrison@windriver.com>]

I haven't seen this via the ips reflector, I guess it's having problems but
apologies if this reply is now out of date.

I still agree with Paul that we should choose a mechanism but I disagree the
options are equivalent, at least from the point of view of an admin trying to
figure what is going on.

Consider in the redirect before authentication case target A is impersonated by
A'. A' redirects to B' which redirects to A' etc. There is nothing in the spec
about how many redirects are valid, and of course implementations will impose
arbitrary upper limits but this sort of bouncing around is going to be hard to
debug. In the redirect after authentication case the admin sees a nice big red
box indicating authentication failed because A' doesn't have the appropriate
credentials. This seems more desirable to me.

Again, let me stress that I don't have a strong opinion about which way this
should go, only that it should be specified.

- Rod

-----Original Message-----
From: Paul Koning [mailto:pkoning@equallogic.com]
Sent: Friday, January 17, 2003 4:00 PM
To: rod.harrison@windriver.com
Cc: Julian_Satran@il.ibm.com; Black_David@emc.com; ips@ece.cmu.edu
Subject: RE: FW: Redirection (was UNH Plugfest 5)


>>>>> "Rod" == Rod Harrison <rod.harrison@windriver.com> writes:

 Rod> I agree with Paul that the spec should be specific on this. At
 Rod> this weeks plugfest none of the 16 companies present had the
 Rod> ability to configure this behaviour so the reality is the first
 Rod> set of products are going to go out hard coded in this manner
 Rod> and some are not going to interoperate. Right now many products
 Rod> are ready to go when the RFC is published and it's too late to
 Rod> rework GUIs, configuration databases and config app to device
 Rod> protocols. The result is going to be that authentication will be
 Rod> unusable with targets that redirect.

 Rod> I personally would like to see the spec say authentication MUST
 Rod> complete before redirection can occur, but like Paul I can
 Rod> accept either choice.

 Rod> A possible way out here is to go with the same approach chosen
 Rod> for the extension digests, that is mandate either redirection
 Rod> before or after authentication unless there has been explicit
 Rod> administrator intervention. That gives interoperability with
 Rod> implementations that can't configure this behaviour, and gives
 Rod> an out for those that want the choice the standard doesn't
 Rod> mandate if they are prepared to do the configuration work.

I hadn't considered that approach.  I'd prefer not to do this.  The
reason is that I see no reason for this behavior to be configured in
the first place.  There is no conceivable reason why an admin should
care about the way it is done; it simply must be done in a way that
works.  Either behavior is perfectly fine; either behavior has
equivalent security properties.

Putting a management knob on this feels like an admission that the
standards process is unable to make any decisions.

     paul