[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 
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.

  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.

  Dan.



Follow-Ups: References: