[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should Alice say who she wants to talk to?
So, I guess we should rename the draft in the draft-ietf-ipsec-*
workspace, fill in the few blanks (explicitly show where the suggested
ID is included in the HASH) and be done with this ?
One question I have: how would current implementations handle receiving an
IKEv1 message 3 which had an extra payload ? Would they ignore it, or loudly
complain and refuse to proceed ? The draft says that the Responder may ignore
the suggested ID (so the Initiator cannot depend on the suggested value being
returned), which is great if implementations ignore extra payloads.
(I'm trying to avoid having to bump the minor version number.)
-Angelos
In message <2E33960095B58E40A4D3345AB9F65EC102EE6972@win-msg-01.wingroup.windep
loy.ntdev.microsoft.com>, "William Dixon" writes:
>The idea in the draft that Angelos & Bill have proposed is very much
>needed for proper responder policy processing based on ID. If I have 2
>IPSec aware services on the same box, the responder needs to use the
>right MM configuration to reply, at a minimum the right credential to
>reply based on the ID requested/expected by the initiator. Yes Radia,
>we should design to accommodate a better credential system for web
>service use. I think there is sufficient support for a DOS mode that
>prevents attacks on DH. So we should do the DH first to protect against
>passive listening ID exposure. That is the bigger threat I see.
>
>Say that one service uses a Public PKI Root/credential for trust, and
>the other service uses a corporate root/credential for trust - then you
>would need to know the initiator's intended service ID early, so the
>proper CRP negotiation could be sent by the responder, allowing the
>initiator to pick the right credential.
>
>As I said in in my comments at the mike, we need to be able to do
>responder authentication first if it's a published service, or initiator
>authentication first if it's a private service.
>
>A structure/usage specified for the ID will ensure interoperability of
>policy systems - so you can distinguish between a request to
>authenticate machine, service or user. Example use cases that achieve
>specific scenarios is also needed to ensure interop. Note that
>selection of auth method may be dependent on the ID requested, because
>that ID may only have 1 auth method available to it.
>
>Perhaps there is some part of trust negotiation research that is not
>encumbered could be useful here.
>
>-----Original Message-----
>From: Radia Perlman - Boston Center for Networking
>[mailto:Radia.Perlman@Sun.COM]
>Sent: Wednesday, December 19, 2001 10:23 AM
>To: ipsec@lists.tislabs.com
>Subject: Re: Should Alice say who she wants to talk to?
>
>
>
>Angelos Keromytis said:
>>> Actually, this is precisely what the "suggested ID" draft Bill
>Sommerfeld
>>> and I have, which Bill discussed briefly on the Wednesday
>session.
>>The
>name
>>> is draft-keromytis-ike-id-00.txt.
>
>>> This was for IKEv1, and mostly intended for bidirectional
>>>user-keying,
>but it
>>> can be used for what you want it.
>
>Yup. Great draft! I like short. But I printed it double-sided and went
>searching through other people's bins to see what happened to the rest
>of my printout :-) Never before saw a draft that fit on one page.
>
>Radia
>
Follow-Ups:
References: