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

Re: More questions on ID types

> 
> On: Wed, 01 Jul 1998 10:59:38 PDT you wrote
> [snip]
> > >   A "reserved mode" (I like that) can be written up in a draft but Main
> > > Mode is not changing at this point in time. Sorry Bryan but this point was
> > > discussed about a year ago and the resolution is what you see today. If
> > > you want to allow remote access with pre-shared keys use Aggressive Mode.
> > > If you don't want to expose a meaningful identity use ID_KEY_ID as the
> > > identity to which the pre-shared key is bound.
> > > 
> > >   Dan.
> > > 
> > 
> > It is good to note that the issue came up earlier and was discussed, 
> > even though I dont like the alternative you suggest. In order to not expose 
> > the actual identities, the vendors would have to agree on an out-of-band
> > encryption by which to encrypt the ID in the vendor specific ID_KEY_ID.
> > This is yet another encryption, and yet another out-of-band requirement
> > in addition to the pre-shared key. Also, as Bryan pointed out, it
> > is a layer violation in that a pre-shared key has to be assusmed based 
> > on the src address (in IP header) rather than ID payload.
> 
>   What encryption? An ID is not encrypted "in the vendor specific ID_KEY_ID".
> 
>   The vendors have to agree on the pre-shared key out-of-band so in the same 
> out-of-band channel they agree to bind the key to an opaque blob. e.g. the 
> pre-shared key is "mekmitasdigoat" and the blob is "geukghisohfewh". That 
> blob is not encrypted it is just meaningless outside the two peers. When 

What could have been a meaningful ID (such as foobar@foo.bar.com) is now
having to be turned into a blob like "geukghisohfewh" by the vendors. This 
is what I meant by having to encrypt the ID.

> someone presents and ID (whose type is ID_KEY_ID) of "geukghisohfewh" and 
> provides proof of knowledge of the pre-shared-key associated with that then 
> you've authenticated that party. The pre-shared key is based on the contents 
> of the ID payload _not_ on address.

OK. 

> 
>   If you don't like the solution then write up yet another authentication
> method for IKE and let us all throw darts at it. What is there now is not
> changing. Period. Full stop. End of discussion.
> 

You misunderstood what I said. I wasnt saying I did not like the solution 
you proposed in the draft. Rather, I was asking for a rationale, because I 
was not present at the earlier IPsec meetings and am not privy to discussions
on the subject otherwise. Hope you understand.

>   Dan.
> 
> 

cheers,
suresh
Follow-Ups: References: