[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACT ION :draft-ietf-pkix-scvp- 00.txt))
Stephen,
>>>5) My PC uses one of the approaches above, but once authentication via the
>>>certificate is complete, enforces a secondary authentication. This
>>>authentication is under the control of the server, and so can't be cracked
>>>off-line. If an attack is mounted, the VPN server will receive 'warnings'
>in
>>>the form of authentication failures (I hope). The authentication
>>>information provided in this secondary phase MUST NOT be part of the VPN
>>>client's automatic function.
>
>>What exaclty is an example fo the second phase authentication here? If one
>>assumes use of a SecurID card, for example, why not postulate that it was
>>tolen at the same time as the smart card? If a password is used, then we
>>have all the usual password-related problems that make guessing possible.
>
>I like 'guessing possible', provided that the guessing can only be done
>on-line. If I am using a SecureID card, for example, the card itself can not
>help you know when you have the right pin number, only the server in the
>head office knows which pin number goes with which card. To crack-in using
>IKE XAUTH, I need to go on-line and interface directly with the server. If
>the server get suspicious that I'm guessing, it can take action. I agree
>that badly chosen passwords/pin-numbers will be a problem, but apart from
>that, it does give the server a way of keeping a secret that is not (should
>not) be recorded in any place other than the users head, and the server's
>database.
Depends on what form of SecurID card you are talking about. Most of these
cards do not require a PIN to actuve them; the PIN is just used as a static
password to help counter the threat posed by theft of a card. Under that
model there are various ways I may have acquired the PIN, especially if I
can spoof the server (which would not happen if one authenticated the
server prior to transmitting the PIN). In more traditional SecurID usage,
the passive wiretapper has access to valid challenge/response pairs and
would be able to search the PIN space even when the PIN is entered into the
card as part of activation. So, under the best circumstances, yes, the use
of a card like SecuID and a full fledged 2-way authenticated IPsec SA is an
improvement, as you noted.
>If 'normal' smartcards can be dismantled and interrogated as you suggest,
>then that is a worry that secondary authentication seems to help with.
>Maybe 'normal' Smartcards are not enough? We need super, FIP-140 level-4
>type devices that can defend themselves against all manor of creepy
>crawlies? Fortezza?
Fortezza is not evaluated vs. 140-1, but it would not meet level 4, or
probably even level 3 criteria, for a variety of reasons, some of which are
orthogonal to the discussion here.
>On a related point, since IKE XAUTH is typically one-way (server
>authenticating client), secondary authentication does leave the problem of
>the server being spoofed with a compromised key!
I thought it was one way the other way, i.e., server is authenticated to
client via a cert, but client uses only "legacy" auth to server. If it
were the other way around it would be awful, as it would open a variety of
attacks against the legacy systems which could diminish their
effectiveness. For example, S/Key is very vulnerable to active server
spoofing attacks.
Steve
References: