[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Photuris questions
> From: Hilarie Orman <ho@cs.arizona.edu>
> The initiator cannot indicate that it is willing to use MD5 or SHA for
> the key hash but will only use SHA for the security association.
> Is this a deliberate design decision?
>
Yes, it is. For one thing, since MD5 is required to be supported, while
SHA is not, no initiator will _EVER_ be able to to "indicate" any such
thing. Perhaps you used a poor example?
A major purpose of Photuris is to _eliminate_ user configuration and
allow scaling to millions of interconnections. Rather pointless to have
to user configure the thing which is designed to eliminate user
configuration.
If you have a user situation where configuration to use SHA is required,
then of course you have to fall back to user configuration. User
configuration is required to be supported (see Security Architecture).
But this has nothing to do with Photuris.
In summary, please get out of the "user configuration" mind-set. Think
automated. Think implementable. Think interoperable.
> As Bill Sommerfield points out, the responder can choose AH even if it
> is capable of supporting ESP. The initiator should be able to
> indicate early on that this will not be acceptable. The initiator
> might be capable of supporting ESP, but chooses AH; possibly the
> responder should be able to indicate to the responder "although you
> seem to be capable of supporting ESP, you aren't using it, please do so."
>
Maybe you missed "authentication policy is in the receiver, encryption
policy is in the sender"?
Perhaps you are confused by the fact that the initiator and responder
can each both send and receive? Let's use "sender" and "receiver" in
the remaining discussion.
If the sender isn't sending anything encrypted, then it will only use
AH headers. No matter that the receiver is capable of receiving ESP.
This is axiomatic, not theoretic. And not specific to Photuris.
However, as you previously requested, if the sender _needs_ to send
encrypted material, and the receiver hasn't indicated that it can
receive encrypting transforms by generating a SPI with such attributes,
then there is a Photuris error message that indicates this to the peer
(#4).
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: