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

Re: Comments on "Hybrid Auth. mode for IKE"

Sures,

>There may be a mis-understanding here. What I was saying was not what
>you were alluding to. Re-authentication may be done any number of times,
>if so desired, independent of what the authetication type is. CHAP allows
>re-authentication. But, Re-authentication arguments you allude to apply
>to existing authentication schemes as well as the exchange-type
>authentication scheme being proposed.

The re-auth issue seems to be a red herring at this point and I brought it
up only because you cited it as a feature of XAUTH. I don't think it has a
place in the usual IKE exchange, so I don't think it's true that it applies
to all existing auth schemes.

>I am drawing a distinction between an authentication mechanism that is
>exchange oriented (starting with a ID_EXCH_START type payload, and
>ending with a ID_EXCH_DONE payload) as opposed to a single-payload-type
>authentication (ex: signature authentication).
>
>Within an exchange-type authentication, you could authenticate a
>client in more than one-way. For example: Challenge/response
>authentication, followed by smart token card authentication.
>In general, the exchange type authentication could combine multiple
>authentications and hence is a stronger mechanism for auth than a
>single-payload-type authentcation.

I don't agree.  Several mediocre or poor methods are not necessarily as
good much less better than one very good method.

>Why do you call the current auth. mechanism continuous auth? They
>authenticate each side just once using a single ID payload from either
>side.

Each IPsec packet is authenticated upon receipt (if one follows the
recommendations in the IPsec arch doc) via AH or via ESP.  That is
continuous (data origin) authentication of the traffic.  The keying
material used to validate each packet is the product of an IKE D-H
exchange, but that provides no intrinsic authentication.  The exchange of
certs and the demonstration of possesion of the corresponding private keys
to sign selected data ties the IKE key material exchange to the continuous,
per-packet autentication.

>I dont quite parse you last sentence right. I am arguing for using smart
>token cards for IKE authentication.

I don't get that from your message. IKE works fine with a smart card or PC
card that is used to perform the crypto in support of IKE.  We need no
changes to accommodate such use.  The thrust of this discussion seems to be
to accommodate legacy technology that operates in an offline mode, e.g., a
SecurID card, that  cannot perform the crypto operations needed for IKE.
Such technologies don't provide two-way authentication, since the user's
token is not prepared to validate any challenge from the other end of the
SA.  That would seem to make such techniques intrinsically less secure,
right?


>> >Lastly, certificate based authentication you suggests requires a vast
>> >deployment of CA infrastructure, which is not in place yet. Many of the
>> >ISP consortiums have to go with what is commonly available as opposed to
>> >what a single enterprise or a limited no. of ISPs have. Would you rather
>> >that remote access applications not utilize the benefits of IPsec until
>> >the certificate deployment is common place? I would think not.
>>
>> Not true.  I have personal experience establ;ishing PKIs that were derrived
>> from name/password baselines.  It can be done easily, especially for
>> intranets and for closed user communities. Since I'm in the PKI business I
>> may me accused of being biased ;-), but I also have some ammount of
>> experience proving assertions of this sort to be false.
>>
>
>You may be right in that there are CA deployments, based on name/password
>baselines. But, CA deployment is still very small compared to RADIUS based
>deployments for CHAP and token card authentications.

I agree, but that does not make these technologies equivalent in terms of
security nor desirable as alternatives.  IPsec is a new, better technology
and to fulfill its potential we should be making use of precisely the
two-way auth mechanisms for which it was initially engineered.

>> >> >       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?
>> >
>> >Well, not really. It is just an extension of the authentication
>> >mechanism to both parties.

Now I don't understand what you're saying.  Either the token can do the
crypto for IKE or it cannot.  If it can, we are done aond don't need XAUTH.
If not, I don't see how this is "an extension of the authentication
mechanism to both parties."  Both parties have an auth mechanism in IKE
already.

>> If we have authenticated end points using good keys associayted with certs,
>> it's not at all clear that use of additional, weaker mechanisms adds to the
>> strength of the system, while it certainly adds to the complexity of design
>> and management!  My clients want fewer user auth databases to manage, not
>> more, and moving these databases to certs is the best approach from a
>> security perspective, in most cases.
>>
>
>Hmm... Seems to me, you have the logic the other way around. Certificate
>based authentication is lot more complex to design, implement and manage
>than CHAP type authentication. Certificate based CAs are yet another
>infrastructure and auth database to deloy and manage. So are secure-DNS,
>Kerberos and so forth.

I say this again, slightly differently: If one has a password-based auth
system, it can become the basis for user registration for a PKI.
Registration is the most expensive part of PKI management.  Steady state
management is relatively easy.  By the way, you use the phrase "Certificate
based CAs" in your comment above, suggesting that there are CAs that are
not cert based.  I find that puzzling since a CA is a Certification
Authority.  Please explain what you meant by this phrase.

>Customers want fewer databases. But, only time will tell which database
>they would want to keep. In the mean time, it is important to support the
>existing databases while trying to leap frog into other databases.

I already explianed how one can do that.

>> >> >    4. SA lifetime:

>Let us say, there is a way to determine the connect time of a remote
>user into enterprise network. I am refering to such a network-connected-time
>as the metric. I was suggesting to keep the negotiated SAs alive for the
>whole of network-connected-time, as opposed to an arbitrary time-bound
>or data-bounbd lifetime. Of course, Network-connected-time could in
>itself be combined with time-bound and/or data-bound lifetimes.

Yes, one could do that, but in practice these two are likely to converge.
I expect most SAs using reasonable algorithms to have an SA lifetime longer
than the time one would be connected as a remote user (vs. an SG-SG
tunnel).  So, as I said before, why do you think a net connect time metric
is needed.

Steve
Follow-Ups: References: