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

No Subject



with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id H1FW48L1; Mon, 20 Mar 2000 15:28:57 -0600
Date: Mon, 20 Mar 2000 16:28:15 -0500
From: Jim Tiller <jtiller@lucent.com>
X-Mailer: The Bat! (v1.36) S/N 569FD297
Reply-To: Jim Tiller <jtiller@lucent.com>
Organization: Lucent
X-Priority: 3 (Normal)
Message-ID: <18686.000320@lucent.com>
To: Dan Harkins <dharkins@Network-Alchemy.COM>
CC: pau@watson.ibm.com, ipsec@lists.tislabs.com
Subject: Re[2]: IKE Public Key Encryption
In-reply-To: <200003202042.MAA02747@potassium.network-alchemy.com>
References: <200003202042.MAA02747@potassium.network-alchemy.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

DH>   There is only ambiguity when the responder has more than one public
DH> key. If that's the case then the hash will indicate which one to use and
DH> get rid of the ambiguity.

Completely understood, however, how does the initiator know to send
the HASH to accommodate the responder? Hence - should it be included
by default?

DH> I've done interoperability testing with this 
DH> authentication method before but each time the peer only had one public 
DH> key.
Yep - you nailed it:)...
I should add that I have only tested with a single key pair.
But once I began to apply multiple certificates the point came quite
clear. If the initiator does not send the HASH, the responder is out
of luck in decrypting the messages unless all keys are tried - but
success is only known until the ID payload is parsed and is deemed
unintelligible.

Given this conversation...should it be mandatory?  (as much as I would
hate to reduce options)

DH>   It's hashed to retain identity protection which is a feature of Main 
DH> Mode.
Pau-Chen reminded me too... I feel a bit silly. As soon as I hit the
'send' button I realized what a stupid question. Thanks or reminding
me and not bashing me :) Which I deserved, I knew better - - very obvious.

-jim

DH>   Dan.

DH> On Mon, 20 Mar 2000 14:01:20 EST you wrote
>> Thankx for answering...
>> 
>> Is this becoming common practise for most vendors? Although optional,
>> are most including it to avoid complexity and ambiguity? I'm certain
>> this has come up in the VPNC and interpretability seminars.
>> 
>> Also, one more question, if it is a certificate, why hash it? I'm
>> assuming to reduce the size of the payload, but this comes at a cost
>> of processing when the responder is responsible for many certificates.
>> I might add that I'm assuming alot here and just expressing my
>> curiosity to the group.
>> 
>> thankx
>> -jim
>> 
>> Monday, March 20, 2000, 11:25:12 AM, you wrote:
>> 
>> pwic> I would agree. At least our own experience showed that this makes
>> pwic> it much less ambiguous.
>> 
>> pwic> Pau-Chen
>> 
>> 
>> 
>> 





Follow-Ups: