[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Photuris questions
> From: "Angelos D. Keromytis" <kermit@forthnet.gr>
> There is also another problem: since a K-transform HAS to be in the
> list of transforms sent in the COOKIE_RESPONSE/KEY_REQUEST packets, the
> remote can't distinguish mere inclusion of it as a K-transform or as a request
> to use authentication. So it'll always try to use authentication (when the
> algorithms are supported of course).
>
Clearly, the language needs further clarification, as I know that you are
implementing, and that you are not a native English speaker. It is very
important that the spec can be easily implemented directly from the
language, particularly with our US international export problem (can't
just export the source). I will shorten the paragraphs and wording, and
add a note there. Further suggestions for text are welcomed.
Yes, a hashing algorithm _HAS_ to be supported. Indeed, every
implementation MUST support MD5! It may be used for either/both
K-Transform and I/R-Transform.
However, the authentication policy is in the receiver. Therefore, even
though the Initiator MUST list MD5 in its attributes, and the Responder
might choose MD5 for the K-Transform, there is no requirement that it
choose _anything_ for authentication, unless it _wants_ authentication!
----
Selection among several different attributes is needed to enable
future implementation changes without affecting the basic protocol.
Each party specifies a list of the attributes supported.
The attribute list includes authentication, compression, encryption
and signature types. These are mixed in the same list for
simplicity. The implementation can easily distinguish between the
separate uses of each supported attribute, as indicated in the
"Attribute List" Appendix.
This is not a "negotiation". The sender indicates the attributes
that it supports, and the receiver selects from that list.
Each party may select an authentication function from the list of
mechanisms supported by the other party. Authentication policy is in
the receiver direction.
Only the receiver can determine that arriving traffic is authentic.
It indicates its need for authentication by choosing authentication
attributes, and/or authenticated encryption attributes, when
creating each SPI. It enforces the authentication through the simple
expedient of dropping all datagrams that don't arrive with
authentication.
Each party may additionally select an encryption mode, from the list
of mechanisms supported by the other party. Encryption policy is in
the transmitter direction.
Only the sender knows whether each datagram needs privacy
protection, and it uses an encryption SPI created by the receiver,
in addition to an authentication SPI (as needed). In the case that
the sender needs privacy protection for a datagram, and its peer
(the receiver) has not yet created an encryption SPI, an
Error_Message listing encryption attributes is sent to the peer, and
the datagram is silently discarded.
Implementation Notes:
Support for some attributes is required (MD5 and DES-CBC), and
MUST be present in every Offered-Attributes list. It is not
required that a Security Association be created including every
such attribute.
The authentication, compression, encryption and signature
mechanisms, as well as the encapsulation mode (if any), need not
be the same in both directions.
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: