[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE drfat - draft-ietf-ipsec-isakmp-oakley-08.txt
>
> On Mon, 27 Jul 1998 06:29:39 PDT you wrote
> >
> > Hi,
> >
> > I understand everyone is waiting for the IPsec drafts to advance
> > into RFCs. But, I am afraid, a serious flaw was uncoverd in the
> > IKE draft recently (late June). I believe, this flaw needs to be
> > corrected before the draft is advanced into an RFC. The issue
> > came up during a discussion between Bryan Gleeson, Vipul Gupta,
> > myself and others.
>
> It's seriousness is debatable. Also, this is not a recently uncovered
> issue. Way back in March of 1997, Shawn Mamros mentioned this in
> <199703171625.LAA21108@portal.ex.tis.com>. It was noted that version -02
> of the draft did not have this restriction while version -03 did. We're
> now on version -08.
>
I was not aware of the earlier finding. But, It is funny you think
that I was mentioning the recent finding to dramatize the effect :-)
> > I mentioned the problem on the ipsec mailing list briefly at that
> > time and have been trying to resolve this independently with Daniel
> > harkins via private e-mail. But, to no avail. Dan is opposed to
> > altering the draft. I would like the IESG to review the problem.
> >
> > Ref: Section 5.4. Phase I authenticated with Pre-shared-key
> >
> > Problem: While Main mode of negotiation and pre-shared-key based
> > authentication are independently stated as mandatory for
> > IKE draft compliance, together they do not work.
>
> The mandatory-to-implement options of IKE work just fine together. In fact,
> right now I'm accessing my mail remotely over an IPSec tunnel that was
> established by IKE in Main Mode and authenticated with a pre-shared key.
>
> > I.e., Pre-shared-key based authentication in Main mode
> > does not work or is seriously flawed in the way it is
> > stated to work.
> >
> > Explanantion + A possible fix:
> >
> > Section 5.4 states that pre-shared-key based authentication
> > in main mode requires either party to assume the source IP
> > address of the partner (found in IP header) as the ID of partner.
> >
> > This is because the SKEYID used to encrypt the ID payload is
> > based on pre-shared-key. And, the pre-shared-key couldnt be
> > known without knowledge of the ID of the partner. Clearly, the
> > draft cornered itself into a chicken-and-egg problem.
> >
> > If IP-Address type was the only valid ID type, we could take the
> > IP address in IP header (layer 3) as a replacement for IP address
> > in ID payload (layer 4), as the draft says. But, that would be a
> > layer violation (assuming layer 3 info in place of layer 4 info).
> > Even with the layer violation, this assumption is workable only
> > with an IP-address type ID. For an IP DOI, the ID can be many
> > different things, including a user-name, device-name, DER encoded
> > Distintinguished Name etc. IKE negotiation would simply not work
> > with these ID payloads.
>
> Given that the whole point of doing this IKE exchange is to do network
> layer security I fail to see this layer violation when using a network layer
> identifier in the protocol.
>
IKE is a UDP based end-to-end negotiation protocol. The negotiating
processes apparently process the UDP payload (i.e., transport data),
not IP header.
With the exception of PSK, no other auth. assumes knowledge of peer based
on peer's IP address. Take for example, encryption based auth. in main mode.
The initiator knows the peer it is trying to access and its public key.
But,the responder does not. The initiator sends nonce and ID payload
encrypted based on the public key of responder. The responder
knows the public key of initiator only after it decrypts the ID payload.
> I also take issue with the statement: "IKE negotiation would simply not work
> with these (not IP address) ID payloads." Main Mode and pre-shared keys,
> while being mandatory-to-implement, are not the only exchange and auth-
> entication method (respectively) defined in the draft.
>
I was refering to minimally compliant IKE application.
> > Suggestions that we should get around this by using aggressive
> > mode or use a different type of authentication mode only enhance
> > the argument that the protocol is inadequate for minimally
> > compliant IKE implementations(ie, Main mode + Pre-shared-key auth).
>
> I fail to see the inadequacy. I'm using IPSec right now whose SAs were
> established by IKE doing a Main Mode exchange and authenticated with
> a pre-shared key. It works just fine. No problem here.
>
I cannot make comments on your specific implementation.
The inadequacy is that the protocol assumes knowledge of pre-shared-key
(PSK) based on the IP address of peer, and not its ID.
There may be implementations that tie the IP address to an ID (like in
GW-to-GW negotiation), but that wouldnt work with IDentifiers that are
mobile and may not be tied to a single address.
> > One approach I could think of to fix this problem was to
> > disassociate authentication mechanism from key derivation
> > (SKEYID). I am not a cryptographer and I do not understand
> > why SKEYID is evaluated differently based on authentication
> > schemes used. I would suggest making derivation of SKEYID
> > uniform for all authentications, like
> > SKEYID = prf (hash(Ni_b | Nr_b), g^xy)
>
> Hugo Krawczyk (a cryptographer) suggested the -02 to -03 key derivation
> changes. His rationale was to _directly_ authenticate SKEYID. Therefore
> information known only to the peers should be included in the computation.
That somehow you could know the PSK without knowledge of ID is the oversight.
> For the encrypted nonce method of authentication, including the plain-text
> nonces in SKEYID satisfies this; in pre-shared key authentication, including
> the pre-shared key in SKEYID satisfies this. Signature based authentication
> does not have anything known only to the peers and Hugo said that it is
> weaker because of it.
>
And, Signature based authentication works.
> Since the nonces are passed in the clear the suggested method of derivation
> is open to a man-in-the-middle attack, at least for pre-shared key and
> encrypted nonce methods of authentiction.
>
I agree.
Authentication is the principal strength against a man-in-the-middle atack
for both PSK and signature based authentications. Nonces are encrypted only
for encryption based authentications.
> > At a minimum, I would suggest the above SKEYID key derivation
> > change to pre-shared-key based authentications. The
> > chicken-and-egg problem with pre-shared-key based authentication
> > is created because, SKEYID is derived as a function of
> > pre-shared-key. For all other types of athentications, SKEYID
> > derivation does not require peer ID info.
>
> This is incorrect. For both methods of encrypted nonce authentication one
> must know the identity of the peer prior to generation of SKEYID.
That's because the Nonces used to derive SKEYID were exchanged along
with ID, in messages 3 & 4.
> It is
> only signature-based authentication which does not have this limitation,
> and, as Hugo pointed out, it's probably weaker because of it. Lowering the
> security of all authentication methods to their lowest common denominator
> is an unwise thing to do.
>
If you need authentication prior to key derivation (in order to ensure
crypto strength of the derived key), the protocol should have been
designed keeping that in mind.
The protocol for both PSK based auth and signature based authentications
fail that sequence.
> > Authentication based distinctions could be restricted simply
> > to the way HASH_I and HASH_R are evaluated. For example,
> > HASH_I and HASH_R for pre-shared key authentication could have
> > been evaluated differently by concatenating pre-shared key to
> > the message argument (i.e., arg2) of prf.
>
> In this message, Suresh has characterized this as being a newly uncovered
> flaw. He states that one cannot use the full range of identities in IKE
> because of it. He also states that Main Mode and pre-shared keys do not
> work together. These are all startling statements and they have the
> desired effect: one sits up and takes notice. Unfortunately, all three
> statements are incorrect.
>
> There is a limitation in using Main Mode with pre-shared keys: the
> pre-shared key must be bound to the IP address of the peer. This limitation
> has been known for quite some time now. It does not mean that Main Mode
> authenticated with a pre-shared key does not work together. The numerous
> multi-vendor "bakeoffs" which all test Main Mode authenticated with a pre-
> shared key illustrate this. Nor does it mean that the full range of ID
> types cannot be used in IKE-- only that they cannot be used with Main Mode
> and pre-shared key authentication.
>
The limitation you cite essentially makes main mode with PSK auth.
contrived and unworkable in many situations. Most people dont bother
using the combination for this reason. This, in my opinion, is
unacceptable for a minimally compliant IKE implementation.
> The "fix" suggested here is insecure.
>
Well, given a choice between unworkable vs less-secure, I would go
with the latter.
Apparently, the protocol proposed for both signature and PSK based
authentication is insecure (prone to man-in-the-middle attack). But,
signature based authentication is more secure than the PSK based
authentication, by virtue of the strength of signature authentication.
May be, the draft could make aggressive mode mandatory for signature
and PSK based authentications.
> I hope the IESG does not delay advancement of the IPSec documents
> because of this.
>
> regards,
>
> Dan.
>
>
Regards,
suresh
References: