[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate
well since nobody else seems to care where the packet came from I suppose it's fine.
At 07:48 AM 9/11/98 -0700, you wrote:
>
>Actually, this raises an interesting question wrt the recent A6 RR type being
>proposed in the IPv6 group. The plan is to compose the IP address on the fly,
>depending on where you are. How would IPSEC deal with that model?
>
>>
>> If you used a dynamically assigned address you wouldn't have had an IP address in your cert because you, your network manager, and your CA wouldn't have chosen to do that anyway.
>>
>> The validity checking is only a part of the picture, it's not a whole answer by itself.
>>
>> I changed the text (my current plan is to resubmit Monday) so all that stuff is 'MAY' and a few 'SHOULD's so it should line up with the rough consensus we're seeing here.
>>
>> At 12:35 AM 9/11/98 -0700, you wrote:
>> >What if that stolen router is instead your stolen mobile IKE laptop?.
>> >What kind of binding between SubjectAltName to
>> >smtp or ipaddress or dns prevents the above scenario?
>> >
>> >
>> >--Rizwan Mallal
>> >Raptor Systems Inc
>> >
>> >
>> >
>> >-----Original Message-----
>> >From: Rodney Thayer <rodney@tillerman.nu>
>> >To: Greg Carter <greg.carter@entrust.com>
>> >Cc: ipsec@tis.com <ipsec@tis.com>
>> >Date: Thursday, September 10, 1998 7:53 PM
>> >Subject: RE: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names
>> >
>> >
>> >>So this means that what we are trusting is that the CA signed a certificate
>> >which represented some identification that the CA found acceptable.
>> >>
>> >>It seems to me that all this "but the CA said it was ok" logic ignores the
>> >possibility that the private key might be stolen. I am not arguing with the
>> >fact the CA said it was ok, I am thinking about the case where the situation
>> >has changed, and, for example, the private key got stolen (i.e. the router
>> >was stolen and is now sitting on some other network with a different IP
>> >address.)
>> >>
>> >>
>> >>
>> >>At 11:37 AM 9/10/98 -0400, you wrote:
>> >>>
>> >>>> but you're saying ignore the legitimacy of the identities relative to
>> >the
>> >>>> rest of the world...
>> >>>>
>> >>>>
>> >>>Hi Rodney,
>> >>>If the rest of the world is not secure then yes. You trust that your CA
>> >>>only allowed valid names, whether or not those names can be resolved via
>> >DNS
>> >>>(or whatever) is not important. What is important is that your policy
>> >>>database contain an entry for the name. If it does then apply the rules
>> >>>found. You know that the other end is who they say they are because your
>> >CA
>> >>>allowed the identity in the certificate. You allow the connection because
>> >>>you found relevant policy for that identity.
>> >>>
>> >>>If the name can be resolved then that may be a good sanity check, but
>> >unless
>> >>>its secured it hasn't gained you much.
>> >>>
>> >>>So I am in agreement with Tero.
>> >>>----
>> >>>Greg Carter, Entrust Technologies
>> >>>greg.carter@entrust.com
>> >>>
>> >>
>> >
>>
>>
>
>
>--
>--bill
>
Follow-Ups:
References: