[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: matching GW addr to ID payload (fwd)

On Thu, 2 Dec 1999, Bronislav Kavsan wrote:
> All I am saying - having 204.12.57.121 as a source-ip-address and in
> ID_IPV4 - has exactly the same level of insecurity as having 204.12.57.121
> as a source-ip-address and "cisco-gateway.com" in ID Payload. Neither
> scheme is trustworthy, as you said, and therefore the question "How would
> you know that I was NOT 'kivinen@iki.fi'?" is irrelevant.
> 
I suppose. I think that's what I was pointing out to begin with. The question
can not be answered.

> The point I am making is one of the convienience for people who already
> have this code in place (and not of security) to continue to use ID
> Payloads for selecting the key and work through NAT.

Huh? If using MM with pre-shared keys, you can't use the ID payload to select
the key.

> Or recognize the fact
> that ID Payloads in this scenario just useless bunch of bits and get rid of
> it in the standards - both ignoring ID Payload or changing standards to not
> use ID Payload - requires code changes in existing products.
> 
Getting rid of your check that checks the ID_IPV4 against the
source-ip-address seems to me to be rather simple (I seem to recall you
saying it's a one-liner). Neither is illegal according to the rfc, as far as
I can tell, but DOING that check, which is unnecessary, since it doesn't buy
you anything, breaks some situations, so your implementation is not as
flexible as one that simply ignores the ID payload.

Whether or not we rewrite the rfc to exclude the ID from MM/pre-shared is
irrelevant in that case.

Bottom-line: ID payload in MM/pre-shared doesn't give you any usefull
information and can not be checked for validity. So actually checking it is
counter-productive.

Unless someone can point out a fallacy in my thinking.

Here's another approach: If we agree that it's valid to send ID_FQDN in
MM/pre-shared, and you don't check this, then what do you gain by checking
the ID payload when it's ID_IPV4?

jan



> Jan Vilhuber wrote:
> 
> > On Thu, 2 Dec 1999, Bronislav Kavsan wrote:
> > > Jan,
> > >
> > > You said "How would you know that I was NOT 'kivinen@iki.fi'?"
> > > That's true - but the similar question could be asked: "How would you know
> > > that my IP Address is  NOT 204.12.57.121"?
> > >
> > Do you mean ip-address as in 'source-ip-address' or 'ID_IPV4'? There's a big
> > difference. One selects the key, and one does not.
> >
> > > Both schemes have exactly the same level of insecurity (though changing IP
> > > Address on my machine is much easier than changing the content of the ID
> > > Payload :).
> > >
> > No, they don't, but I may be missing something: If you change your
> > ip-address (barring NAT) I would pick a key based on the source-ip-address.
> > So this does have implications.
> >
> > If you change the ID, nothing changes, except the string of bits that goes
> > into the hash. There's a difference.
> >
> > > But at least using "cisco-gateway.com" allows me to ALWAYS check ID Payload
> > > and get through the NAT and do not make the special case for not checking
> > > ID Payload when using pre-shared key in MM.
> > >
> > What does checking the ID payload give you? I can't CHECK that you are
> > 'cisco-gateway.com'. And I personally don't care if your ID payload claims
> > you are 1.1.1.1. Neither pieces of information enlighten me in any way, nor
> > are they particularly reliable, since you could be lying about them, and I
> > have no way of knowing. So I ignore them, and pick the key based on
> > source-ip-address (the only thing I CAN).
> >
> > > Another option in the new draft could be to remove ID Payload altogether
> > > for MMs with pre-shared keys.
> > >
> > Either way, I don't get your points above. The problem is solved if you
> > simply ignore the ID payload in this situation. Pay no attention to it. I
> > carries no relevant information.
> >
> > jan
> >
> > > Jan Vilhuber wrote:
> > >
> > > > On Fri, 3 Dec 1999, Tero Kivinen wrote:
> > > > > Jan Vilhuber writes:
> > > > > > I would argue that it doesn't and that you can safely ignore the ID payload
> > > > > > in the MM/pre-shared scenario, since it adds no value anyway.
> > > > >
> > > > > For pre shared keys it doesn't offer anything. You have to know the
> > > > > identity before ID payload anyways, because you need to select the
> > > > > correct pre shared key before you can decrypt the ID payload. You can
> > > > > use ID payload as a key to select correct policy for the quick mode,
> > > > > but I don't think there is any use to require it to match the IP
> > > > > address of the policy. This only applies for the pre shared keys.
> > > >
> > > > But if you don't 'authenticate' the ID payload in any way, I would think it's
> > > > insecure to select policy with it. Since PC-clients (or at least the one I'm
> > > > familiar with) generally have the ID field as a configuration option, I could
> > > > put in an ID of 'kivinen@iki.fi'. Would you then use this to select policy?
> > > > How would you know that I was NOT 'kivinen@iki.fi'?
> > > >
> > > > Personally, I feel the ID in MM/pre-shared is pretty much superfluous and
> > > > should be ignored and not used for anything at all.
> > > >
> > > > Aggressive mode is different, since I have the option of picking the shared
> > > > secret based on the ID, so I can use it for policy selection (or whatever).
> > > >
> > > > jan
> > > >  --
> > > > Jan Vilhuber                                            vilhuber@cisco.com
> > > > Cisco Systems, San Jose                                     (408) 527-0847
> > >
> > >
> > >
> >
> >  --
> > Jan Vilhuber                                            vilhuber@cisco.com
> > Cisco Systems, San Jose                                     (408) 527-0847
> 
> 
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847
Follow-Ups: References: