[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.
> 

OK. 

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 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.
> 

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.

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? 

> >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.
> 

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.

> >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?
> 

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.

> 
> >> >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.
> 

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

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.

> >> >> >       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.
> 

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

> >> 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.
> 

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

> >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.
> 

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.

> Steve
> 
> 

cheers,
suresh
Follow-Ups: References: