[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ISAKMP Extended Authentication
Some of you interested in this topic may be interested to know that there will
be an EAP BOF in Orlando. EAP is documented in RFC 2284 and specifies a method
to encapsulate authentication protocols. This would be an ideal candidate to
use in an IKE exchange. Although the RFC is very PPP specific, some of us have
been working to make this protocol more generic (the protocol itself is in no
way PPP specifc, but the RFC is document as a PPP extension).
PatC
>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.
>>
>>