[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Main mode using pre-shared keys
Exactly. I suggested this last week in my message "Shared Secret mismatch in
AM3/MM5". The problem I was having with using the pre-shared key to generate
SKEYID is that it makes a shared secret mismatch too difficult to diagnose,
but the restriction on id types is also important.
Andrew
_______________________________________________
Beauty without truth is insubstantial.
Truth without beauty is unbearable.
> -----Original Message-----
> From: Jianying Zhou [mailto:jyzhou@krdl.org.sg]
> Sent: Wednesday, October 27, 1999 9:43 PM
> To: Qiang Zhang
> Cc: ipsec mailling list
> Subject: Re: Main mode using pre-shared keys
>
>
> In fact, there is no identity protection in main mode with pre-shared
> key for authentication. The peer's IP address has to be used to select
> pre-shared key.
>
> One solution is to re-define SKEYID. We may not use pre-shared key for
> the generation of SKEYID. Instead, we can use the definition of SKEYID
> for digital signature, i.e.
> SKEYID = prf (Ni_b|Nr_b, g^xy)
>
> We only need to use pre-shared key for authentication of IKE
> exchanges.
> So we can replace HASH_I and HASH_R with AUTH_I and AUTH_R
> respectively
> in the protocol, where
> AUTH_I = prf (pre-shared-key, HASH_I)
> AUTH_R = prf (pre-shared-key, HASH_R)
>
> Jianying
>
>
> On Wed, 27 Oct 1999, Qiang Zhang wrote:
>
> > At 10:24 AM 10/27/99 -0700, CHINNA N.R. PELLACURU wrote:
> > >RFC 2409
> > >
> > >5.4 Phase 1 Authenticated With a Pre-Shared Key
> > >
> > > Initiator Responder
> > > ---------- -----------
> > > HDR, SA -->
> > > <-- HDR, SA
> > > HDR, KE, Ni -->
> > > <-- HDR, KE, Nr
> > > HDR*, IDii, HASH_I -->
> > > <-- HDR*, IDir, HASH_R
> > >
> > > When using pre-shared key authentication with Main Mode
> the key can
> > > only be identified by the IP address of the peers since
> HASH_I must
> > > be computed before the initiator has processed IDir.
> Aggressive Mode
> > > allows for a wider range of identifiers of the
> pre-shared secret to
> > > be used. In addition, Aggressive Mode allows two
> parties to maintain
> > > multiple, different pre-shared keys and identify the
> correct one for
> > > a particular exchange.
> > >"
> > >
> > >
> > >"identified by the IP address of the peers"
> > >
> > >Does this mean that the ID payload content must be an IP
> Address, and it
> > >should be the same as the source IP address on the IKE
> packet that the
> > >peers are using?
> > >
> > >If the source IP address on the packet is used to search
> the pre-shared
> > >key, then we authenticate the peer, by the fact that the
> peer knows the
> > >shared secret associated with the IP address he is using.
> Inspite of that,
> > >is the RFC also advicing that we enforce, the ID payload
> content is the
> > >source IP address that was used to search the shared secret?
> >
> > Chinna, notice that the HASHi computation HAS to use the
> peer-address to
> > search the preshared secret thus I think at least in this
> circumstance, the
> > ID payload won't work. Further one thing to worry about is
> that the
> > source address is not trustable due to all kinds of IP
> routing scheme.
> >
> > This is something I think the WG should give a solution.
> >
> > Qiang
> >
> >
> > >
> > >If so, the confidentiality part of the Identity protection
> is not there,
> > >when using pre-shared keys.
> > >
> > >What are the consequenses of not enforceing the above
> requirement? We are
> > >authenticating the peer using the IP source address he is
> using, because
> > >we search the pre-shared key based on it, but we accept
> his ID to be
> > >anything.
> > >
> > >TIA, chinna
> > >
> > >chinna narasimha reddy pellacuru
> > >s/w engineer
> > >
> > >
> > >
> >
> >
>