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

Re: Photuris, once more

> From: Hilarie Orman <ho@cs.arizona.edu>
>    Each party selects 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 including authentication transforms, and/or
>    authenticated encryption transforms, in its transform list.
>
> How does the initiator indicate that it wants MD5 as a K-transform and
> does not want AH from the responder?
>
Hmmm, have you read the latest draft?  You are using earlier terms....
Don't bother now, I'll have a new one out by Monday.


First, the exchange of packets is not a "negotiation".  It is a
statement of capabilities.  If the initiator supports MD5, and the
responder picks it, then that's just the way it is!

Assume the responder makes an MD5 SPI, but the initiator merely put the
MD5 in its attribute list to use for a Key-Transform.  The responder
also made a SHA SPI.  There is no reason the initiator cannot just use
the SHA SPI for sending traffic, ignoring the MD5 SPI.

But, as the quoted text already states, if the responder made only a MD5
SPI and the initiator ignored it, sending without an AH at all, then
the responder just tosses it into the bit-bucket!


Second, the responder picks the Key-Transform, not the initiator.

4.2.  Key_Response

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Reserved    |      Responder-LifeTime       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Responder-Transform                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key-Transform                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Key-Transform    variable.  Although the field is depicted as 32-bits
                    for convenience, the size may be shorter or longer,
                    as indicated by its Length field.

                    A cryptographic hash function is selected by the
                    Responder from the intersection of the two lists of
                    Attributes, and is used to calculate the session-
                    key.  This transform is not necessarily the same as
                    either SPI Transform in use.

Note, the responder can only pick a Key-Transform that both parties
support.

I had the responder pick, since I assume that the initiator is a more
likely attacker.

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