Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC25C1E7239 for ; Thu, 21 Nov 2024 03:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMZcfIsP-Eaa for ; Thu, 21 Nov 2024 03:50:08 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47BCC1DFD25 for ; Thu, 21 Nov 2024 03:50:07 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-53dccdcb583so702266e87.3 for ; Thu, 21 Nov 2024 03:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732189805; x=1732794605; darn=ietf.org; h=thread-index:content-language:mime-version:message-id:date:subject :in-reply-to:references:to:from:from:to:cc:subject:date:message-id :reply-to; bh=wyQIq2M5aaJguywKSO0jfrgTtOO6mX5JMELxFV05PKw=; b=cIDuUJL4ogSa9H+JP4KkQ8l3zoDkgOsD39UK7dzELdzNrB9Fg157NelCWLy0aZ1d8T cjWwp5v+35c66izQiBL9zO7cAB4RCtOKzhVXkqCR3xB7yd727ExFG5Y5tLqlp1ifMgUZ PJfqhMiud/2pQEogQXoTNjaWQLfiIDCTzi64wwri1CkQiy2udtRM7DLnvu7DjouHBfVx Qo41+O3bmYetEoDbXZF+SaOoU52/Z0TnDPAk0UZ49ofHYQpzW+GvSfKn48534wnSOrWy 3rvvMycnHE+0kwK9ygBPV8UAW0nU19fQOwUXP+/dTqA6euHOuOevYZKcx5PJdCHvmVzh r1tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732189805; x=1732794605; h=thread-index:content-language:mime-version:message-id:date:subject :in-reply-to:references:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wyQIq2M5aaJguywKSO0jfrgTtOO6mX5JMELxFV05PKw=; b=ro6HknE9ikpdYy/XShO/5QOvyCYJPYQ5K7T/e0Xo2P7D8cMwATgBx02bRRMZcCyMbo Q9/kqjOOqVH1DMKPPa1Arnq5G9tAb9rgyZVN4aotzDxZHNJ78BGwcV9hubT4BFBlFn8s mZ1Lmmo7Jigql/I07TOTOaO4cMP9ujLyNEOrcOyTEqHtNQ5kCWXaeYX06lV7WxSnkYwm W+U41yrsfDvZBUCPdz0AmZTgZHS3TF8UgvzFD+PNegBljurAtuGzVtn0IIwAPZsRz/Xk JZ/xOLMbWtrSHVw2JVwDiw69gVKx9stWtHafBtzVkCeUSCPhJCY6T1kI+jl/CRJzb5tl MGXA== X-Forwarded-Encrypted: i=1; AJvYcCWv2KW54qr8FvYOoMrRMrdsuK5vt/uuF9qOWA93IVc12JfciyaA5AqW8dNzqu5Nx1riB/arJw==@ietf.org X-Gm-Message-State: AOJu0YyWS/+b6Wd3nKWNbUZRYJcp0OEbEbWGsnaNTv4GbQf3UOD1JeQT 2L2LDli2W2gJG37+C5DQf3b7V2x538usqSyI4SvfF/dfmIStGIn5q2GYSw== X-Gm-Gg: ASbGncv1vxWhjroP/uahmG5qsyvTYQzoPHgmdEGrkNq2oM8OscPQsykcCro0rk3u6wr 8zipQ8m1ZnJLWR0JgwvON1eGDawqARMSoOVVa6RA7XelSyy0buCTERibd/ll7S659YDXaNpPDzy 6xOE0Pgf3VNvpkhW+r/+c9QwV4XUsk32G1R91wp/pvZOqJgE8kFQayl9cdjWKBQflgqtCBgLloD w3RsbrSSI+KRRC6KETgal5JRhpXC7nKZTAEeSFl4jDbFHIFLmSkZp188g== X-Google-Smtp-Source: AGHT+IExNIYUSW5m6k7iDU0sakNP9yG12akLWqYfNjHXRjU1F97QCXaCp+Zs8xeY0EydXSlMho1QJw== X-Received: by 2002:a05:6512:2314:b0:53d:cee1:df89 with SMTP id 2adb3069b0e04-53dcee1e024mr494914e87.13.1732189804778; Thu, 21 Nov 2024 03:50:04 -0800 (PST) Received: from BuildPC ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-53dbd4671adsm975235e87.114.2024.11.21.03.50.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2024 03:50:04 -0800 (PST) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" , References: In-Reply-To: Date: Thu, 21 Nov 2024 14:50:02 +0300 Message-ID: <01a901db3c0b$80cc2190$826464b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AA_01DB3C24.A61A6B00" X-Mailer: Microsoft Outlook 16.0 Content-Language: ru Thread-Index: AQIJUIa+v/R9eO6rT8WiO5Zh+d7/l7JlGeqw Message-ID-Hash: 7N2G27GS4UWFFDSFOI76BFLN7F36HZHT X-Message-ID-Hash: 7N2G27GS4UWFFDSFOI76BFLN7F36HZHT X-MailFrom: smyslov.ietf@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipsec.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BIPsec=5D_Re=3A_Comments_on_draft-ietf-ipsecme-ikev2-qr-alt?= List-Id: Discussion of IPsec protocols Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_01AA_01DB3C24.A61A6B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Scott, thank you for your comments. Please see inline. I just went through the ikev2-qr-alt draft, and have these comments: - The last paragraph of 3.1 worries about the case where the two sides agree on a PPK, but after authenticating, it turns out that they're not configuring for using that PPK with the peer's identify. Thoughts: o Is this a real security issue? After all, I believe that the PPK is designed to enhance privacy, not authentication (and while it can does add some authentication, I do not believe that's its main role). o If we get to this step, both sides know the same PPK, however they're not configured to use it in that context. What would the security issue be if we were to ignore that? o If that is an issue, then we should have a better way of addressing it than "fail the connection". Perhaps we could pass some identity information in the IKE_INTERMEDIATE, so that both sides could make a better decision. While the primary goal of PPKs was enhance privacy, they affected authentication too - with both RFC 8784 and this specification mismatched PPKs would result in authentication failure. RFC 8784 assumed that PPKs are relatively static. With this assumption pairwise PPKs for each pair of peers in most cases have scalability issues, thus we explicitly said there that group PPKs are OK. This specification assumes that PPKs can be changed frequently (the means for this are out of scope, e.g. QKD), thus a situation with pairwise PPKs may change. Consider the following example. Alice and Carol both can connect to Bob with PPK and digital signature authentication. Alice is configured with PPK_a, Carol is configured with PPK_c. Bob obviously has both these PPKs. If Malory somehow knows PPK_a (e.g just stole it) and is equipped with CRQC, then she obviously gets access to all past communications between Alice and Bob and she also is able to impersonate Alice to Bob in future. But if Bob skips the check above (that Alice may only use PPK_a and Carol may only use PPK_c), then Malory can also impersonate Carol using PPK_a, if she breaks Carol's signature. Thus I believe that this is a security issue (depending on responder's policy, it is not an issue with group PPKs). What about the identity in IKE_INTERMEDIATE. We have PPK_ID there and it is responder's local security policy, that links PPK_IDs with IKE IDs. Thus we don't decrease identity protection (PPK_IDs can be made looking random and be changed frequently, and we do not expose IKE ID to an attacker who doesn't possesses a valid PPK). - In the PPK_IDENTITY_KEY notify, you have a variable length PPK_ID field followed by a fixed length PPK Confirmation field (and the parses is expected to deduce the length of the PPK_ID field). In my opinion, it would be cleaner if the fixed length field came first. Just a suggestion. The current format was inspired by typical authenticated message format, where a fixed-length ICV is usually appended to a variable-length message. I have no problem to swap them, if other vendors, who already implemented this draft, agree with you. But actually, the difference in the code would be minimal. - In 3.2, you omit the existing messages in the CREATE_CHILD_SA messages "for brevity". I believe it would explain how the new payloads would integrate into the existing exchange by listing the full exchange. Done. Regards, Valery. ------=_NextPart_000_01AA_01DB3C24.A61A6B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Scott,

 

thank you for your comments. Please see = inline.

 

I just went through the = ikev2-qr-alt draft, and have these comments:

 

-        = The last paragraph of = 3.1 worries about the case where the two sides agree on a PPK, but after = authenticating, it turns out that they’re not configuring for = using that PPK with the peer’s identify.  = Thoughts:

o   Is this a real security issue?  After all, I believe = that the PPK is designed to enhance privacy, not authentication (and = while it can does add some authentication, I do not believe that’s = its main role).

o   If we get to this step, both sides know the same PPK, = however they’re not configured to use it in that context.  = What would the security issue be if we were to ignore = that?

o   If that is an issue, then we should have a better way of = addressing it than “fail the connection”.  Perhaps we = could pass some identity information in the IKE_INTERMEDIATE, so that = both sides could make a better decision.

<= o:p> 

W= hile the primary goal of PPKs was enhance privacy, they affected = authentication too - with both RFC 8784 and this specification = mismatched PPKs would result in authentication = failure.

R= FC 8784 assumed that PPKs are relatively static. With this assumption = pairwise PPKs for each pair of peers in most cases have scalability = issues, thus we explicitly said there that group PPKs are = OK.

T= his specification assumes that PPKs can be changed frequently (the means = for this are out of scope, e.g. QKD), thus a situation with pairwise = PPKs may change.

<= o:p> 

C= onsider the following example. Alice and Carol both can connect to Bob = with PPK and digital signature authentication. Alice is configured with = PPK_a,

C= arol is configured with PPK_c. Bob obviously has both these PPKs. If = Malory somehow knows PPK_a (e.g just stole it) and is equipped with = CRQC,

t= hen she obviously gets access to all past communications between Alice = and Bob and she also is able to impersonate Alice to Bob in = future.

B= ut if Bob skips the check above (that Alice may only use PPK_a and Carol = may only use PPK_c), then Malory can also impersonate Carol using PPK_a, = if she breaks Carol’s signature.

T= hus I believe that this is a security issue (depending on = responder’s policy, it is not an issue with group = PPKs).

<= o:p> 

W= hat about the identity in IKE_INTERMEDIATE. We have PPK_ID there and it = is responder’s local security policy, that links PPK_IDs with IKE = IDs.

T= hus we don’t decrease identity protection (PPK_IDs can be made = looking random and be changed frequently, and we do not =

e= xpose IKE ID to an attacker who doesn’t possesses a valid = PPK).

<= o:p> 

-        = In the = PPK_IDENTITY_KEY notify, you have a variable length PPK_ID field = followed by a fixed length PPK Confirmation field (and the parses is = expected to deduce the length of the PPK_ID field).  In my opinion, = it would be cleaner if the fixed length field came first.  Just a = suggestion.

<= o:p> 

T= he current format was inspired by typical authenticated message format, = where a fixed-length ICV is usually appended to a variable-length = message.

I= have no problem to swap them, if other vendors, who already implemented = this draft, agree with you. But actually, the difference in the code = would be minimal.

<= o:p> 

-        = In 3.2, you omit the = existing messages in the CREATE_CHILD_SA messages “for = brevity”.  I believe it would explain how the new payloads = would integrate into the existing exchange by listing the full = exchange.

<= o:p> 

D= one.

<= o:p> 

R= egards,

V= alery.

------=_NextPart_000_01AA_01DB3C24.A61A6B00--