[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: Main mode using pre-shared keys
Hello Jianying,
Is the peer's IP address derived from the payload (i.e. the
HASH_I/R) or just the source defined in the IP header of the
packet?
If it is derived from the HASH_I/R...does that have to be
the same as the IP Header's source address?
Also, if the HASH gets the IP address from the ID, that is
used in the hashing process, why can't
it search the shared secret based on some of the other
attributes available in the ID?
Here is the issue. I have read the RFCs inside and out,
books and more books. But I can seem to only get so deep
until I think I'm missing a basic point.
If some one could shed some light on this:
Zhou> In fact, there is no identity protection in main mode with pre-shared
Zhou> key for authentication. The peer's IP address has to be used to select
Zhou> pre-shared key.
No identity protection in MM or AM (?) I thought ID
protection WAS available? I understand that AM does not
provide any, but MM? Is this because there is no signature
process like with the other authentication types?
I feel like I'm missing something obvious and it's effecting
my ability to increase my knowledge of IKE and IPSec in
general. To be frank...I don't have anyone to really discuss
this with on a regular basis. So, I humbly request the
assistance of the kind folk of this mail list.
Thank you in advance for your time.
-jim
P.S.
Just so you know, I have been reading everything on this
list for the past three months in an attempt to learn as
much as I can prior to asking poor question. I fear that
this may be a poor question.
Wednesday, October 27, 1999, 8:43:13 PM, you wrote:
Zhou> In fact, there is no identity protection in main mode with pre-shared
Zhou> key for authentication. The peer's IP address has to be used to select
Zhou> pre-shared key.
Zhou> One solution is to re-define SKEYID. We may not use pre-shared key for
Zhou> the generation of SKEYID. Instead, we can use the definition of SKEYID
Zhou> for digital signature, i.e.
Zhou> SKEYID = prf (Ni_b|Nr_b, g^xy)
Zhou> We only need to use pre-shared key for authentication of IKE exchanges.
Zhou> So we can replace HASH_I and HASH_R with AUTH_I and AUTH_R respectively
Zhou> in the protocol, where
Zhou> AUTH_I = prf (pre-shared-key, HASH_I)
Zhou> AUTH_R = prf (pre-shared-key, HASH_R)
Zhou> Jianying
Zhou> 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
>> >
>> >
>> >
>>
>>