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

Re: More questions on ID types


Ooops... Clarification to my last e-mail
> 
> > 
> > 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 main mode of exchange is permitted with pre-shared keys, the draft does
state (section 5.4)  that the pre-shared key can only be identified by
initiator based on the IP address of the responder and not his ID payload. 
And, pre-shared keys MUST be permitted in Main mode because:

      Main mode is a MUST; Aggressive mode is a SHOULD.
      Authentication via pre-shared keys is a MUST.

Pre-shared keys could be used in aggressive mode, as you say.
But the ID type is in the clear. Vendors may need to transform the 
actual IDs (like foo@foo.com) into some undecipherable blobs and use 
ID_KEY_ID type IDs if they need to conceal real identity.


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

cheers,
suresh
References: