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

Re: (IPng) Re: Proposed message on perfect forward security

Steve,

Yes, you are right about :

>                                                       I thought I saw the
>  suggestion that one of the reserved SAID values could be assigned the role
>  of indicating the presence of in-packet keying material.  

The problems with this are :

 o  The existing security architecture I-D explicitly deprecates the use
    of in-band keying. While we know that it can be made to fit into
    the existing formats, those who read the documents without the benefit
    of reading all of the email on this subject that has appeared on the
    IPng list would legitimately conclude that in-band keying is outside
    the standard.

 o  One of the reserved SAID values could be used, but right now they are
    "reserved for future use." Those who are interested in using one of
    them for in-band keying can't just unilaterally pick one and use it,
    since sometime in the future the IETF may pick it to be used for
    something else. I have emailed to the list a suggested value to use
    for this purpose (i.e., SAID = 1) and proposed that the existing
    security drafts be changed to include it. (Of course, I don't care
    if the value is 1, 4 7 or whatever, I just picked 1 as a concrete
    proposal).

 o  Picking an SAID value for in-band keying still leaves the problem of
    parsing the remaining information. This problem has two parts. One is
    how the software will know which in-band keying algorithm is used,
    and the other is what data format is being used for the algorithm
    specific data. The first problem is solved by defining a standard
    way to indicate which algorithm is being used and where the algorithm
    specific data will go. I have suggested ways in which the current
    security I-Ds could be changed to do this (but am open to other ways).
    The second problem is solved on an algorithm by algorithm basis, probably
    in the form of an RFC per algorithm (much as Photuris will have its
    own RFC).


While your suggestion :

>							Alternatively, you
>  could use an option in a Destination (formerly End-to-End) Options header
>  preceding the AH or ESP header to carry the in-packet key stuff.

is possible, it would effectively mean that there would be two AH
and ESP header formats (although, they might be called something different).
The kind of data in the new option would be pretty much like that
in the AH and ESP headers. This seems wasteful, since an IPv6 packet would
not carry both an AH or ESP header formated according to the existing
definitions as well as the in-band Destination Options header.

Your other suggestion, i.e.,

>									Is it
>  simply the lack of a spec that defines either of those alternatives that
>  leads you to say "In-band keying will not work with the present IPv6 specs."?
>  If so, feel free to write such a spec.

I have tried to avoid, since it would mean taking 95% of the text from the
existing security I-Ds, change it in the way I have suggested in previous
email to the list and putting it out as separate drafts. Not only would
this be rude to Ran (i.e., stealing someone's text is a somewhat hostile act),
it would mean that there would now be two sets of drafts for the already
streched people on the list to read and evaluate.

Dan