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

Re: IPSRA and "legacy systems"



David,

you say

> 
> Yet, I'm disappointed that the current drafts don't explicitly show the full
> range of potential here.  I'd like to encourage people to think about 
> better ways to realize the full potential of IPSEC, and public-key
> technology in general.

You may be disappointed with the way the WG has defined its scope,
but given that definition why you should be disappointed by the technical
solutions offered in the WG drafts.
These drafts are providing solutions to a very specific problem:
bootstrap ipsec (or ike) authentication via a legacy authentication 
service WITHOUT changing the interface of that service to the existing
(legacy) passowrd-related database.

As for realizing the "full range of potential here", as you say, take into
account that full potential also means additional
protocol/specification/implementation complexity, and this WG, being
a descendant of ipsec, has learned a hard lesson on adding complexity
via accomodating everyone's list of desirable features (and it wasn't
generally the case that the features did not make sense, it is just that
you have to compromise with the feature/complexity trade-off).  
So whenever you come to offer an extended definition of the problem 
that the WG is trying to solve, or to offer extended capabilities 
to the proposed solutions, keep in mind that you need to make your 
proposal SIMPLE (or at least to make it appear that way).

One of the things that I believe can be valuable at this point is to
build the short-term solutions in ways that may be easier to extend later
when people feel it necessary. Any comments on improving the current drafts
towards easier extensibility are welcome.
Certainly, if you have technical objections or improvements to offer 
to the drafts in the context of the WG charter please let the WG know.

Another point that may deserve more discussion is the "validity" of
assuming that the remote machine and/or user have ways to verify the 
public key of the authentication server. Atleast in the Bellovin/Moskowitz
and PIC drafts this is an assumption.

Hugo