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

Photuris meeting discussions

Because we were not allotted enough time to adequately discuss the
Photuris points during the IPSec meetings, a number of lunch, dinner,
hallway, and terminal room BOFs occurred.  Here is a synopsis of the
results:

 1) The burgeoning security analysis is getting in the way of the
    reading for implementors, and needs to be in a separate document.
    This has the advantage that new progress in the field can be
    documented without republishing the main Photuris specification.

    Because of her extensive textual contributions to the Photuris
    draft, Hilary Orman has been asked to join with us in co-authoring
    the separate draft.

 2) The user-oriented keying has also been moved to a separate draft.
    As noted in an earlier message, I have asked both Sommerfeld and
    Spatscheck to combine their ideas.

 3) It is becoming clear that we need an API draft which lists minimum
    application and kernel requirements for support of user-oriented
    keying.  This could be based on the current IPv6 MacDonald draft for
    a starting point.

    No consensus was reached on details, except that it should not delay
    progress of the Photuris draft.

 4) Bellovin suggests that the prose section before each pair of
    messages needs to be made more stylized, re-written as pseudo-code,
    as in the IETF tradition of TCP, RIP, etc.

    Also, the Attributes and other field sections need more repetition
    and more cross-referencing to avoid forgetfulness.  While this is a
    matter of style (I prefer to remove repetition), there is no
    substantive reason (other than my fingers, and the amount of extra
    pages) why it cannot be done.

 5) The Offered-Attributes are unclear when one or more attributes can
    be used for more than purpose.  This principly applies to such
    things which are not well specified, such as the label, the OUI, and
    other multipurpose attributes.

    Also, having more than one AH and/or ESP transform for a single SPI
    is not well defined.

    The solution is two-fold.  Each Attribute number will be used for
    only one purpose, which will be included in its name.  This means
    that there will be 3 OUI Attributes, for example.  Offered-Attributes
    will be split into 3 lists, Identification-Attributes,
    Authentication-Attributes, and Encryption-Attributes; the lists will
    be separated by new AH and ESP "header attributes".

 6) The mandatory attributes need to be specified earlier than the
    appendix.  The '*' in the Appendix isn't visually distinguishable
    from the '+'.

 7) More Numbered Headers to provide better cross-referencing.

 8) A complete Example including full-sized cookies, public-values, and
    hash results to help in debugging.  This is a lot of work....

If there are other topics I missed, please remind me.  I don't have the
Photuris discussion list at hand.  I assume that will be in the minutes.

As this is a major reorganization, Phil and I will be busy on it for
several days.  Please have patience.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2