Re: The remaining IKEv2 issues

[Yoav Nir <ynir@CheckPoint.com>]

Hi Uri,

Re: XAUTH.  There was nothing particularly wrong with XAUTH.  The 
fiasco is that the original IKE proved to be unusable in the 
remote-access scenario, because customers demanded authentication using 
RADIUS servers, OS passwords and SecurID tokens.  This led vendors like 
Cisco and Check Point to develop XAUTH which is not quite standard, so 
that remote-access becomes useable.  With IKEv2, we want to avoid 
making it necessary to develop such an add-on.

Re: not using kg methods.  SecurID belongs to a certain vendor, and 
they can create a kg method that suits them.  In fact, they have, but 
they won't publish the spec, so I can't implement it.  I could install 
their add-on (not yet available) on the client, and then the gateway 
only needs to channel the EAP messages between SecurID server and IKE 
client.  However, if we do that, we lose all the advantages of having a 
kg method, because the gateway does not know the shared secret.  Of 
course, you could implement something like you do in 802.1x where the 
server sends the shared secret to the gateway, but that's bad ( a 
shared secret isn't ).

Now let's take another example.  A customer keeps all his 
username/passwords on the mainframe, because that's the only computer 
they trust.  The only access our IKE gateway has to the mainframe is 
running something called a RACINIT, that allows you to pass the 
username and the password, and get a yes/no response.  How can we get 
this to work, if the gateway never knows what the password is?  Even 
MD5-Challenge won't work here.  Passing the password "in the clear" 
through GTC is the only way to go here.  Now if we could come up with 
some method that generates keys and passes the password from the client 
to the gateway, we'd have a solution, but here we can't use 
challenge-response as in MD5-Challenge or MSCHAPv2.

On Thursday, August 21, 2003, at 11:10 PM, Uri Blumenthal wrote:

> On 8/21/2003 3:04 PM, Paul Hoffman / VPNC wrote:
>>> If we are expecting that people are going to implement these methods 
>>> and
>>> customer are going to make use of these methods, I would much rather 
>>> see
>>> a standards-based way of doing so, and have this method be tested at
>>> bakeoffs.
>>
>> Fully agree.........
>> Saying "'MUST NOT' or 'SHOULD NOT' do the things
>> that your customers are demanding" is a really good way to cripple
>> IKEv2 deployment.
>
> Well yes, I agree too. What I don't understand if why we
> cannot create kg methods using the same credentials? It
> seems to be the only way to satisfy both the customers
> who need to use devices like SecureID (hey, I'm one
> of those), and the security requirements.
>
>> One of the main goals of IKEv2 was to avoid re-creating
>> the XAUTH fiasco.
>
> Please educate me - I didn't keep track of XAUTH. Why did
> it fail? What was wrong with it?
>
> Thanks!
>
>