[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ISAKMP Extended Authentication
I should point out that the application I am looking at is a Network
Computer which could be powered down at any point in time. Such a host is
not necessarily trusted to the same extent that a CA would be. The approach
Tero recommends would also permit the host to fabricate a user certificate
since the host could easily make up a public/private key pair and ignore the
smart card altogether. I don't think turning all these host systems into
CA's is prudent. If every host had the authority of a CA, the trust
associated with a CA would disappear. Given that this level of trust is not
acceptable when deploying 100's of such systems, I would think that the
extended authentication mechanism I suggested may be cleaner - presuming it
could be adapted to this role. What are your thoughts on the use of this
mechanism?
Clipping from my original email:
>>> It would appear that the methods specified in the IPSEC Draft
>>> "Extended Authentication Within ISAKMP/Oakley",
>>> <draft-ietf-ipsec-isakmp-xauth-03.txt>, could be extended to facilitate
a
>>> public key challenge/response authentication mechanism, permitting the
user
>>> to be authenticated after the Phase 1 negotiation was complete. The
current
>>> draft does not address the use of a public key signature for
authenticating
>>> a user. In the absence of a certificate distribution mechanism, the
>>> authentication mechanism would need to permit the user's certificate to
be
>>> passed with the response.
------------
>Hi Tero,
>
>While a neat idea I don't see how this could scale, as well tuning every
>host system into a CA seems problematic. How do you enforce the identity
in
>the temporary cert when the 'authority' is the host, the host can claim the
>'user' identity is anyone? Is the gateway obligated to verify the info in
>the temp cert matches the one in the 'permanent' cert? What about access
to
>the crl repository, typically it would be behind the gateway, so how does
>the host gain access to post the crl?
>Bye.
>----
>Greg Carter, Entrust Technologies
>greg.carter@entrust.com
>
>
>> ----------
>> From: Tero Kivinen[SMTP:kivinen@ssh.fi]
>> Sent: Monday, November 23, 1998 5:41 PM
>> To: John Irish
>> Cc: IPSEC
>> Subject: ISAKMP Extended Authentication
>>
>>
>> So the hierarchy will be like this:
>>
>> CA Root ----------------------------------.
>> | \
>> Host key |
>> | |
>> Temporary user certificate permanent user certificate
>>
>> Here "Temporary user certificate" and "permanent user certificate"
>> are both certificates for the private key in the smart card. If only
>> user authentication is needed then we use the "permanent user
>> certificate", and if the both user and host authentication is needed
>> then we have to create that "temporary user certificate" and use that.
>>
>>
Follow-Ups: