[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[4]: Granularity of authentication in swIPe
Phil:
>>Also, I think that the SAID structure must support IP broadcast and IP
>>multicast. For this reason, I want a larger SAID (say, 32 bits for
>>compatabiltiy with the IEEE 802.10 Secure Data Exchange and Key Management
>>Protocol). Management of broadcast and multicast keys within the Internet
>>will require a large pool of SAIDs.
>
>As I think Perry already said, SAIDs logically include the IP
>addresses. They're just like TCP sockets - each connection is
>uniquely identified by the concatentation of the IP addresses and
>port numbers, which means you need many fewer port numbers than you
>otherwise would if everything was identified solely by port number.
I disagree. In pairwise communications, this might be true, but in
multicast it is not true.
I see multicast support like this: When an IPSP implementation comes up,
it contacts a key server to obtain the SAIDs and keys for the multicast
groups for which it is a member. The transfer of keys from the key server
to the IPSP implementation could be protected in a pairwise key formed
using D-H, or it could be protected in a pairwise key that was manually
distributed, or it could be protected in a pairwise key form Kerberos.
The key server would be charged with access control to the multicast keys.
It would not distribute them to IPSP implementation that were not part of
the multicast group.
Without the key server for multicast, I agree, you end up doing public key
operations on IP datagrams. And, I don't like this solution either.
Russ