RE: Comments on CRACK

>>Vipul Gupta wrote:
>>> In message <3815F49E.BFABF7C9@cisco.com>, Roy Pereira writes:
>>>
>>> >
>>> > Let me ask everyone who is interested; How do we support existing
>>> > legacy user authentication within IKE without using a PKI ?
>>>
>>> With a protocol that lets the customer download an encrypted private key/
>>> certificate pair from a server, followed by ordinary IKE.
>>>
>>>               --Steve Bellovin
>>>
>> A perfect lead-in for what I've been thinking about for some time
>> now :-)
>>
>> How about using an HTML forms based interaction over HTTPS between
>> a webserver and a user to accomplish what you state.
>>
>>           Internet                           Intranet
>>
>>                               |
>>                               |          +--> Legacy Auth server
>>           SSL/TLS protected   |         /
>>     user =================== HTTPS <---+
>>                              server
>>                               |
>>                               |
>>
>>   This interaction can easily accomodate legacy user auth mechanisms
>>   like SecureID, DES Gold, OTP, CHAP because the HTTPS server has access
>>   to authentication tokens in the clear. Even multiple rounds don't
>>   pose a problem. After the Auth server responds with "OK", the
>>   HTTP server can squirt out a special MIME datatype and the browser
>>   could be set up to automatically invoke the IKE daemon (or companion
>>   software) to handle that MIME type. The HTTPS may need to coordinate
>>   with the IPSec gateway on the Intranet side.
>>
>>   This could be a reasonable solution for the road warrior VPN scenario.
>>   I've heard Paul Hoffman use the term "user authentication in Phase 0.5"
>>   for an approach like this (in contrast to Hybrid's Phase 1.5).
>>
>>   (Maybe now's a good time to go look for that fire extingusher :-)).
>>
>>   vipul
>>
>>That's not a bad idea in itself, although I'd rather not have the requirement
>>to implement HTTPS just to be able to implement legacy authentication
>>support in IKE!
>

It need not be just for legacy authentication. It can also be used
for transporting configuration information, temporary certificates
(as you describe below) or even attribute certificates (if that
takes of).

>
>(as you d
>>However, let me quote an earlier email that I sent:
>>
>>There's another architectural thing you should consider. What about modifying
>>the protocol so that when the server starts believing in the authenticity of the
>>client, the server issues the client's public key a certificate? This certificate
>>would have a very limited life-time, just enough for the purpose at hand.
>>It would be transported to the client in the 'last' message, whatever that is.
>>
>>Although this creates more public key operations, the legacy authentication
>>functionality could be located on a different physical box than the actual
>>security gateway.. This achieves a very similar function to the Kerberos ticket
>>granting server, and the certificate is similar to Kerberos tickets. You'd of
>>course have to set up the trust relations appropriately.
>>
>>There could also exist "one time certificates" that can be used only once
>>during their life-time to gain access, similar to one time passwords. Some
>>way or another they would be revoked the moment they are used.
>

One of the question is

Should legacy authentication and configuration be part of IKE?
or should IKE remain just a key exchange protocol?

The way I see it is if legacy authentication is an intermediate
step towards a PKI world then

1) There must already legacy mechanisms in places to distribute
per-peer secret keys, and protocols to use it. It could be either
SSL/TLS or some other homegrown protocol. Otherwise what
are the legacy methods through which these legacy authentication
mechanisms are currently used? Why not continue to use them as they are
instead of retrofitting it into IKE?.

2) configuration - configuration is independent of key exchange
and thus should be separate from IKE.

I hope that if IPSRA move towards supporting legacy authentication and
and configuration mechanisms in IKE, it would spell out the reasons
for doing it in IKE versus implementing it as a separate protocol.

>>
>>If you wanted, you could transport such a certificate through HTTPS to the client.
>>Although, as said, I'd rather not have HTTPS in the picture.
>>
>>--
>>Ari Huttunen                   phone: +358 9 859 900
>>Senior Software Engineer       fax : +358 9 8599 0452
>>
>>Data Fellows Corporation       http://www.DataFellows.com
>>
>>F-Secure products: Integrated Solutions for Enterprise Security
>>