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

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

Suresh,

>
>However, Re-auth does make sense, for example, if the remote site's
>authentication becomes questionable based on some application specific
>payload (or) some policy that requires it. But, I digress.

I think we have another mis-communication here.  IPsec is an Internet layer
protocol.  When an SA is established it it fixed in its security
characteristics for the duration of the SA.  There is no notion that a
specific application payload, sent over an SA, should elicit a different
set of services.  So, for example, if an application performs some
operation for which a re-authentication is appropriate, that should be
provided via an application later security mechanism, not IPsec.

>
>Well, exchange-type authentication is a strong requirement for legacy
>verification schemes. To that extent, it is valuable. I was merely
>extrapolating the process to suggest that we could use the scheme to
>perform multiple authentications in succession (example - 2 very good
>methods, one after the other). Apparantly, I have not been able to
>articulate this well. So, I will drop that line of discussion for the
>time being.

A large part of this debate hinges on the desirability of accommodating
legacy user authentication mechansims in IPsec.  I have no objection to
this so long as it does not degrade the fundamental level of two-way
authentication that we get from IKE. I do not agree that the legacy support
goal is so important that it should cause us to degrade this critical
security feature.  Look at SSL.  It has a capability for client
certificates, which provides a user authentication facility analogous to
what IKE can do for IPsec.  However, most systems are still employing
static passwords protected by SSL encryption, which results in a number of
vulnerabilities.  I'd rather not see IPsec fall into the same trap.

>Say, the Certification Authoriy is down for some reason and noone can
>get certs from there. Wouldnt you agree, it would be a good idea to
>have a backup authentication scheme in such a case?

First, one does not retrieve a cert from a CA; one retrieves it from a
repository of some sort, and such repositories need to be highly available.
Second, IKE provides a facility to pass certs (and CRLs) as payloads, thus
avoinding the possibility that an unavailable repository will prevent
authentication.  In the systems we are engineering based on IPsec, we
require vendors to make use of this approach, to avoid such problems.

>
>No argument there. I agree, ISAKMP Authentication is key to ensuring
>intrinsic authentication to session based SAs. Having said that, I also
>believe, it is important that people have multiple options to pursue.
>Let the market place decide what auth. scheme they like in different
>scenarios.

Again, a disagreement over goals.  The marketplace has consistently chosen
weaker security mechanisms in the past.  In creating IPsec the intent was
to significantly raise the bar, not make minor, incremental improvements.


>Hmm, I am confused. By smart token cards, I am refering to cards like
>SecurID card. Why should they perform any crypto operations for IKE?
>SecurID cards do provide 1-way authentication (Card user is authenticated
>by card verifier). Why should the authentication be 2-way? Each party can
>be independently Authenticated in a different way, whichever works best.

Your suggestion is to employ two different authentication methods, one for
the user and one for the "system."  This requires the user code to be able
to parse certs and CRLs, so it has many of the capabilities needed for
support cert-based auth for the user.  Thus the addition of other user auth
capabilities adds complexity to the user code, increasing the likelihood of
errors.  That seems to be a downside to this proposal that has not been
addressed.

>
>I disagree. I dont believe, two-way auth. mechanism has anything to with
>the strength of authentication.

Oh come now!  Of course two-way auth is superior to one-way auth, so there
must be a deeper message you're trying to express here.

>The market place decides based on multiple criteria including ease of use,
>security requirements, legacy requirements, cost associated and so forth.
>For this reason, I would not restrict options to just one kind.

My comments above about the marketplace stand.

>
>Token card based auth. is independent of XAUTH.
>Token card based auth. simply requires an exchange-type-authentication.

Perhaps we've gotten confused over terminoloy here.  Let's skip this one.


>Oops.. I wasnt implying anything different. I guess, I just wanted the
>word "certificate" spelled out in the sentence :-)

OK.

>
>Say, the user chose an infinite lifetime option. When a user is disconnected
>from the network, the SAs are presumably still valid, right. In such a case,
>someone else could get on to the same machine and happily use the session
>SAs.  By limiting the SA lifetime to "network-connected-time", the SAs
>automaitcally become invalid when the user is not connected to the network.

I think you need to explain the assumptions underlying this example.  For a
remote (dialup) user, when I disconnect from the network, I expect the
IPsec implementation to clean up and the SA state to go away, thus removing
any chance of SA reuse. If the disconnect is the result of a crash, I
expect the state to go away at my end, even though the other end may still
have SAD entries for the SA(s).  This too renders the SAs useless.  The
primary circumstance in which your comments seem to apply would be a
multiuser machine with a faulty IPsec implementation, one that fails to
maintain the mapping between users and their SAs.  In my environment I see
few (actually, no) such machines, but I agree that under thise
circumstances, and IF re-auth were employed for extant SAs, then the use of
a separate user auth method would have some merit.  But, since I am leery
of actual use of re-auth, and since the example you provided above to
motivate it had problems, I don't find this a compelling argument. Maybe
with more detail it would be more persuasive.

Steve
Follow-Ups: References: