[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (IPng) Re: Proposed message on perfect forward security
Dan Nessett says:
> In regards to your questions :
> > Technical Questions:
> > 1. To reveiw: Will in-band keying work with the present IPv6 specs
> > (Rans work) without changes to the specifications? Not just SKIP
> > (see next question).
> No. In-band keying will not work with the present IPv6 specs. This issue
> is independent of SKIP. The problem is there is no place to indicate in
> either the AH or ESP that in-band keying is being used.
Thats not true.
The reserved SAIDs were envisioned for doing things like this. It
wasn't thought that we'd actually *want* to use them, but we did leave
in the flexibility just in case.
So far as I can tell, using one of the reserved SAIDs, as has been
repeatedly proposed, would work just fine for you. This is not to say
that the mechanism is being encouraged, but it is possible. Given the
inability to reuse most of the rest of the protocol machinery,
however, I really don't see, overall, why you would even want to try
to get the round SKIP peg to fit into a square IPSP hole -- you need
all your own transforms, you don't use the SAIDs per se, etc, etc --
for the most part, you aren't using the IPSP mechanisms at all.
> > 2. Are there multiple ways to use in-band keying besides SKIP?
> > I am asking this because I believe in-band keying should be
> > something vendors should be able to build as a key-management
> > solution. I am assuming SKIP is only one way to use in-band keying
> > and others can exist too?
> SKIP is only one way to do in-band keying. Other possibilities
However, none have been proposed as serious contenders for IETF
> As far as I know, SKIP is the only
> widely publicized in-band keying method proposed for IPv6,
...which you seem to realize.
> > 3. Can't we discuss this without mention of SKIP so that we can
> > make sure either in-band or out-band can be used? I think its
> > important we get to the heart of the architectural issues
> > technically of the in/out modes and not get hung up on actual
> > mechanisms? Or is this not a good idea?
> I agree 100% that we should focus on the issue of in-band and out-of-band
> keying and not concentrate on SKIP.
Given that different hacks and kludges are probably needed for each
similar method proposed, I would say that trying to ignore the
specifics of the SKIP proposal, which is the only one currently on the
table of its kind, would be foolish.