[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on "Hybrid Auth. mode for IKE"
>EAP Introduced to ipsec ? :), I don't want to be there when PKIX meets
>SPKI...
You make it sounds like a bad movie :)
>
>Anyway...
>When I thought of EAP-ISAKMP it was to increase security which was lacking
>in most of the other EAP mechanisms. Now it seems we want to hack ISAKMP to
>work with the 'lacking' EAP mechanisms, mostly token cards. Which come in
>two varieties, those based on DES, and those based on proprietary protocols.
>Putting aside the wisdom of DES and proprietary algorithms...
>
>The DES cards usually have a "Guess next Challenge" mode where they know
>what the next challenge will be based on the last. The proprietary card
>uses a time based scheme, and so at any moment in time you know the
>response, there is no challenge. You can take the response as the IKE
>shared secret. No Challenge is needed.
EAP can support any authentication mechanism. It can be viewed as a way to
tunnel an authentication protocol between two endpoints that may not have
direct connectivity (which is normally true when a client is trying to gain
access to the network).
It seems that it would be desirable to have the same (or a similar) model
for PPP, IKE, SOCKS and possibly other services such as IP Telephony. But I
agree that the exchange must be secure.
>
>Benefits -
>No changes to IKE.
>May increase security of DES based challenge/response cards since known
>plain text/cipher text never flows over the network. DES cards when used
>with protocols like RADIUS or TACACS do all the challenge/response in the
>open. $250K and 56-224 hours later you have the key. In this mode DES is
>combined with key hashes and no known text is transmitted over the network.
>Supports DES cards, Time based cards (OK they'll have to write some code on
>their server to give up the expected response based on ID, rather than a
>simple yes/no response, but nothing is for free), PAP/CHAP (no reason to do
>CHAP, just use the password as the secret...
Again, it just happens that *some* of the EAP proposal are based on DES. EAP
could also support biometrics, TLS and a whole slew of other more secure
schemes. EAP is not tied to DES in any way.
And there is no reason that one cannot protect the RADIUS or TACACS session
with IPSEC using strong crypto.
>
>Drawbacks
>Aggressive mode is the only practical choice.
>Initialization and resync. Initialization is easily handled, resync is
>doable.
>Backend server will be needed to track card state. Not really a drawback,
>every card manufacture I know offers a backend management server of some
>sort which already does this. Since the backend server is now essentially a
>key server you should probably run IPSEC over the link from the Gateway to
>the server.
>
>Anyway my point is that it is doable with the current spec, no changes to
>token hardware, maybe a little coding on the server side. Sure there are
>some drawbacks but you want to use 1980's technology...
>Later.
>----
>Greg Carter, Entrust Technologies
>greg.carter@entrust.com
>
>
>> ----------
>> From: Roy Pereira[SMTP:rpereira@TimeStep.com]
>> Sent: Wednesday, July 22, 1998 2:16 PM
>> To: Stephen Kent; suresh@livingston.com
>> Cc: moshe@checkpoint.com; ipsec@tis.com; suresh@livingston.com; Pat
>> Calhoun (E-mail)
>> Subject: RE: Comments on "Hybrid Auth. mode for IKE"
>>
>> FYI: A general common authentication protocol BOF is being planned for the
>> Chicago IETF. The agenda is to discuss combining among others, the PPP
>> EAP protocol and IPSec's XAUTH protocol, and producing an authentication
>> mechanism that can be migrated to any environment.
>>
>> I would worry that we are trying to on-the-fly build a protocol thru email
>> that would be better designed by teams dedicated to solving this problem.
>> Besides most of these issues were already brought up on this mailing list
>> previously when XAUTH was released and again when PPP EAP was introduced
>> to the IPSec mailing list.
>>
>> > -----Original Message-----
>> > From: Stephen Kent [ mailto:kent@bbn.com]
>> > Sent: Tuesday, July 21, 1998 10:26 PM
>> > To: suresh@livingston.com
>> > Cc: moshe@checkpoint.com; ipsec@tis.com; suresh@livingston.com
>> > Subject: Re: Comments on "Hybrid Auth. mode for IKE"
>> >
>> >
>> > Pyda,
>> >
>> > > 1. The ID payload is not good enough for remote access user
>> > > authentication. What we need is new type(s) of ISAKMP
>> > > payload(s) - something like ID_EXCHANGE_INITIATE,
>> > > ID_EXCHANGE_IN_PROGRESS and ID_EXCHANGE_COMPLETE.
>> > > (There may be variations to the ID_EXCHANGE types,
>> > > like challenge/response, token card, OTP etc..)
>> >
>> > This assertion needs to be justified. Perhaps the argument
>> > is support of
>> > legacy auth systems, but it certainly is not security. We
>> > can do a better
>> > job of user auth with certs than any of these other
>> > approaches. The certs
>> > (and associated crypto processing) could be in a personal
>> > token, not just
>> > in software, thus providing very high quality user auth.
>> > Also, one might
>> > argue that IPsec provides an impetus to switch away from
>> > transient user
>> > auth, to continuous user auth, from passwords to keys, etc.
>> > That's why I
>> > think this first premise needs to be much better justified
>> > than what I've
>> > seen so far.
>> >
>> > > 3. The authentication mechanisms suggested are
>> > asymmetrical between
>> > > edge device and remote user. Edge device is authenticated with
>> > > a public key, whereas remote user is authenticated
>> > with token card
>> > > and CHAP(Challeng/Response) mechasims.
>> >
>> > Why? I'd much rather use a cert for user auth, as provided
>> > in SSL with
>> > client certs, than these other mechanisms. Again, you need
>> > to justify this
>> > assertion.
>> >
>> > > However, it doesnt have to be that way. If desired, the remote
>> > > user could run the same token card/CHAP mechanisms to
>> > authenticate
>> > > the edge device.
>> >
>> > That's definately a step down in security! Why even suggest this?
>> >
>> > > 4. SA lifetime:
>> > >
>> > > The current metrics of "time-bound" and "Data-bound" for an
>> > > SA lifetime do not seem adequate for remote access users.
>> > > I would like to see a new metric like "network-connected-time"
>> > > for SA lifetime. This new metric may be used in
>> > conjunction with
>> > > other metrics (if the crypto algorithms mandate such
>> > a limiting
>> > > criteria) or by itself.
>> >
>> > Why is not SA lifetime close enough to net sonnect time? Why
>> > is the latter
>> > metric preferable?
>> >
>> > > Keeping an SA valid for the lifetime of network connection,
>> > > makes the administratve overhead on remote user and
>> > edge device
>> > > simpler. I can see this new metric being valuable even in
>> > > GW-GW type VPN connections. (SA rekeying is a lot of overhead
>> > > and has lots of scope for confusion and
>> > inconsistencies between
>> > > vendors).
>> >
>> > See questions above.
>> >
>> > Steve
>> >
>> >
>> >
>>
>>
Follow-Ups: