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

Re: Photuris, once more



> From: Hilarie Orman <ho@cs.arizona.edu>
> Can the initiator indicate which transforms it will accept for the K-transforms
> and which it will accept for the AH transforms?
>
The initiator indicates the transforms which it can handle.  Some of
these transforms can be used for key hashing, some can be used for AH,
some for both, as indicated in Appendix B.

The responder chooses the key transform from the list of functions.

If the responder wants an AH, the responder separately chooses an AH
transform as well.

The initiator does not restrict transforms on its own.  The initiator
must implement the functions as defined in the Photuris specification.
Such restrictions are made _now_, after careful community examination
and testing, not willy-nilly by clueless operators.


> The architecture rfc, as I read it now, through a glass more clearly,
> indicates that in the case that the ESP transform provides both auth and priv,
> then two keys must be indicated in the SA.  How does Photuris derive
> the two keys (I know, you don't think ESP should do this, but if it did ...).
>
Well, as none exists now, when you define an ESP transform which _does_
do this, you will also need to define how its keys are derived.

Photuris can supply rather a large amount of keying material, depending
on the key-transform chosen.


> Can the initiator indicate to the responder that ESP in the resp-init direction
> is a requirement?
>
As specified, the initiator chooses the transforms which will be used
for SPIs in the incoming direction.  If it always wants ESP to be used,
it will always specify a transform which can only be used with ESP.

These transforms are described in separate drafts, and are outside the
scope of Photuris.

But its peer chooses which SPI (among many) to use, or whether to use a
SPI at all....

This is rather a fundamental principle of the Security Architecture, and
is already mentioned in the "Attributes" section.


> Could there be an auth-only transform for ESP?
>
Seems rather a non-sequitor to me, as this has nothing to do with Photuris.

ESP defines an "opaque" payload.  If you have an auth-only transform
which provides opacity, then I guess we'll take it up when you write the
draft describing it....

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


Follow-Ups: