[cPP Comment 29 - 32] connections using an out-of-band provisioned pre-shared key (PSK)

[kr15tyk]

Location: NDcPP: p123, B.3.1.1, FCS_DTLSC_EXT.1. NDcPP: p128, B.3.1.1 , FCS_DTLSS_EXT.1.10 NDcPP: p143, B.3.1.5 ,FCS_TLSC_EXT.1.8 NDcPP: p147, B.3.1.5, FCS_TLSS_EXT.1.7

Comment: Sentence 1 seems to be conditional since the TSF may not support DTLS 1.3. Should be its own SFR. Sentence 2 seems to be a different requirement than the first.

Suggested change: None

[kenji-lightship]

I see a few potential ways to address this, none of which seem too hard:

1. Edit this so is is something like "The TSF shall [selection: not use PSKs, only use PSKs in TLS1.3 session resumption with forward secrecy]." With the app note clarify that "only use PSKs..." means out of band-provisioned PSKs are not allowed.
2. Make the PSK selection-based, based on the TOE supporting TLS1.3

[KSinitski]

PP-Module for WLAN Access System (https://www.niap-ccevs.org/Profile/Info.cfm?PPID=464&id=464) includes TLS_PSK* ciphers in FCS_RADSEC_EXT, as such introducing "only use PSKs in TLS1.3" would result in a conflict with the base PP.

[kenji-lightship]

Currently NDcPPv2.2e does not allow PSK ciphersutes and says no other ciphersuites are allowed. FCS_RADSEC_EXT.1.2 clearly ties the RadSec channel to either FCS_TLSC_EXT.2 (X.509 auth) from the NDcPP or FCS_RADSEC_EXT.2 (PSK auth); so the PP-Module addresses the potential conflict with SFRs.

[KSinitski]

Currently NDcPPv2.2e does not allow PSK ciphersutes and says no other ciphersuites are allowed.

Did you intend to say "base NDcPPv2.2e does not include PSK TLS ciphersuites" ? Because my understanding that PSK ciphersuites are not explicitly prohibited in NDcPPv2.2e.

[sheepbaron]

TL;DR - I think agree with @KSinitski here. TLS_PSK* cipher suites 'seem' to be allowed when WLAN MOD is introduced...

1. WLAN MOD refines FTP_ITC.1.1 to include RADsec, which, if you follow the chain of selection-based SFRs leads to the inclusion of TLS_PSK* ciphersuites. The chain of selection (when WLAN MOD is included) how I currently see it is as follows:

_FTP_ITC.1.1 (WLAN MOD refined SFR) > FCS_RADSEC_EXT.1 (were .1.2 element allows for the selection of "pre-shared keys") > must then select FCS_RADSEC_EXT.2 (where the TLS_PSK cipher suites are introduced) and FIA_PSK_EXT.1 (further associates the selection of PSK cipher suites in RADsec with PSK generation requirements) > FCS_RADSEC_EXT.3 (required if TLSPSK* is selected; no impact the current argument).

2. In addition, the following statement in WLAN MOD supports the notion that TLS_PSK cipher suites are allowed in the ND+WLAN PP configuration:

"This SFR defines the implementation of RadSec when pre-shared key authentication with RSA is used. This functionality is outside the original scope of the Base-PP, but it relies on the TLS client protocol implementation, cryptographic algorithms, and random bit generation functions defined by the Base-PP."

3. While the app note for RADsec in the WLAN MOD states "The above ciphersuites are only for use when the TSF is acting as a RADIUS over TLS client, not for other uses of the TLS protocol"... that statement does not negate the fact that TLS_PSK* ciphersuites, when WLAN MOD is included in the evaluation, can be selected for any TSF associated with Trusted Channels, for example, audit server can be selected and a TLS_PSK cipher suite can be used in that context.

Conclusion: If we accept the above argument, then, to @kenji-lightship 's point, the statement of "and no other ciphersuites" in the base PP must be qualified when WLAN MOD is included.

This is how I currently see things. I am always open to be corrected :D

[plughy2]

I would agree with Michael's conclusion. Additionally, AUTHSRV MOD v1.0 contains an optional allowance for (D)TLS 1.2 PSK ciphersuite. From the App Note for FIA_PSK_EXT.1/AuthSvr:

"RadSec is claimed in FIA_PSK_EXT.1.1/AuthSvr, if RadSec is selected in FTP_ITC.1/NAS and the (D)TLS implementation in RadSec allows server-only authentication or supports a PSK ciphersuite."

[kenji-lightship]

Currently all the refinements and explanations to allow PSKs are contained in the MODs that support PSK. Why would we change that for NDcPPv3.0? While WLAN MOD section 6.1.4 says "This functionality is outside the original scope of the Base-PP, but it relies on the TLS client protocol implementation...defined by the Base-PP," this appears to be inconsistent with FCS_RADSEC_EXT.2 which appears to be a TLS client protocol implementation independent of the definition in the Base-PP.

@sheepbaron Re # 3 FCS_RADSEC_EXT.2.1 says "when acting as a RADIUS over TLS client," so I don't see you would apply this SFR to an audit server.

Since this is not a change from NDcPPv2.2e and a conscious decision to not support out of band PSKs was made when developing the requirements (so we did not need to consider the security implications); this should be a future enhancement, not a change during the comments phase.

[KSinitski]

NDcPPv2.2e did not explicitly prohibit PSK use with TLS, it only limited TLS to a defined set of allowed ciphersuites, which cold be amended via MOD to add TLS_PSK ciphers. NDcPPv3 was intentionally altered to explicitly disallow that for unclear reasons.

[kenji-lightship]

It is not possible to use a PSK without a PSK cipher suite. NDcPP2.2e does not allow PSK ciphersuites; therefore, the base PP does not allow PSKs.

[sheepbaron]

this appears to be inconsistent with FCS_RADSEC_EXT.2 which appears to be a TLS client protocol implementation independent of the definition in the Base-PP.

I don't see where the TLS implementation/protocol as described in MOD_WLAN is defined to be or expected to be independent from that of its description in the NDcPP. Maybe I am overlooking something?

My understanding of RadSec, as it pertains to TLS, is that RadSec can be directly compared to HTTPS; where in HTTPS - HTTP is encapsulated by TLS, whereas in RadSec - RADIUS is encapsulated by TLS....and in both cases, TLS is implemented as per the typical TLS RFCs. This conclusion is supported by the following SFR chain from MOD_WLAN:

_FCS_RADSEC_EXT.1.1 (do RadSec according to RFC 6614) >> RFC 6614 (do TLS according to RFC 5246 [TLS 1.2] -or- RFC 4346 [TLSv1.1] - these are the same TLS RFCs referenced in NDcPP and MODWLAN).

In addition: _FCS_RADSEC_EXT.2.1 (same thing; do TLS according to RFC 5246 [TLS 1.2] -or- RFC 4346 [TLSv1.1]) >> if a 'TLS_RSA_PSK' cipher suite is selected here, then FCS_RADSECEXT.3 is required (I found nothing supporting or discounting this argument in this SFR).

[kenji-lightship]

To summarize my position:

1. I'm not fundamentally against PSK support if someone wants to add it. I just don't think it adds much value and is more likely to have unintended consequences.
2. This is not a new inconstancy (due to current 2.2e ciphersuite limitations). It seems like projects have been able to navigate this without a problem. It seems understood that RADSEC PSK SFRs are independent from the base TLS claims.
3. Adding/changing SFRs to support PSK and consider their implications is a larger change than I think should be made in the comments phase. This seems like it should be a future enhancement
4. The discussion of adding support for PSKs is unrelated to the initial issue raised

[kenji-lightship]

I think I have a simple solution to clarify PSKs with a minimal risk of unintended consequences.

Edit List 1 to include [assignment: module specific ciphersuites]

Edit the PSK SFRs to read: The TSF shall not permit (D)TLS connections using PSKs with the following exceptions: [selection:

• none
• PSKs in (D)TLS1.3 session resumption with forward secrecy
• [assignment: module specific uses] ].

For both edits, include an app note: "module specific uses/ciphersuites" is for modules to assign module specific uses of ciphersuites and PSKs. The ST author shall not use tee assignment to add uses/ciphersuites that are not specified by a module. The module specific uses/ciphersuites may only be used with the trusted channel(s) specified by the module. The module author is responsible for ensuring testing exists for "module specific uses/ciphersuites" added by the module.

Thoughts?

[jhallf5]

Is there a specific nomenclature we can use to refer to the “modules” that is used consistently elsewhere to make this restriction clear? For example, does the CC standard refer to them as “Protection Profile Modules” or is there some other name that’s consistent and specific?

[sheepbaron]

I think I have a simple solution to clarify PSKs with a minimal risk of unintended consequences.

Edit List 1 to include [assignment: module specific ciphersuites]

Edit the PSK SFRs to read: The TSF shall not permit (D)TLS connections using PSKs with the following exceptions: [selection:

• none
• PSKs in (D)TLS1.3 session resumption with forward secrecy
• [assignment: module specific uses] ].

For both edits, include an app note: "module specific uses/ciphersuites" is for modules to assign module specific uses of ciphersuites and PSKs. The ST author shall not use tee assignment to add uses/ciphersuites that are not specified by a module. The module specific uses/ciphersuites may only be used with the trusted channel(s) specified by the module. The module author is responsible for ensuring testing exists for "module specific uses/ciphersuites" added by the module.

Thoughts?

Brilliant! I would endorse this.

[sheepbaron]

Is there a specific nomenclature we can use to refer to the “modules” that is used consistently elsewhere to make this restriction clear? For example, does the CC standard refer to them as “Protection Profile Modules” or is there some other name that’s consistent and specific?

Yes; I can see something along the lines of the following:

• [assignment: PP-module specific uses]
• [assignment: PP-module specific uses consistent with an appropriate PP-Configuration for the Base-PP]

[KSinitski]

I think modifying cipher list to include [assignment: module specific ciphersuites] would work.

Also, as the stated concern is "The use of out-of-band provisioned pre-shared keys creates a potential security concern since the entropy used to generate the PSK is outside of the control of the TOE. " adapting FIA_PSK_EXT.1 Pre-Shared Key Composition from WLAN modules as a selection-based SFR would be a cleaner solution, as PSKs also used in IPSEC.

[kr15tyk]

I agree with @KSinitski that modifying cipher list to include [assignment: module specific ciphersuites] would work.

Adding PSK SFRs to NDcPPv3.0 has larger implications and is a change I don't think should be made in this final editorial phase. I agree with @kenji-lightship that this seems like it should be a future enhancement.

[plughy2]

The set of requirements covering signature_algorithms extension should be examined to determine the impact of using a PSK ciphersuite. There needs to be application notes in the cPP and the Supporting Document explaining the signature_algorithms extension is not required for PSK ciphersuite. Otherwise, it's confusing. The cPP and SD define the signature_algorithms extension to be optional / conditional. It doesn't explain why but it appears this was done for a different reason.

In looking at the cPP and SD in regards to the signature_algorithms extension, this has revealed a separate issue. The cPP and SD currently requires that the [D]TLS client does not need to present the signature_algorithms extension. I believe this was done because RFC 5246 does not require it. If a client does not include the signature_algorithms extension then it will use SHA-1 as the hash function (page 47, RFC 5246). However cPP v3.0 deprecated use of SHA-1 and there are no signature algorithms that use SHA-1 in the NDcPP. In other words, the [D]TLS client needs to include the signature_algorithms extension.

[kr15tyk]

SInce Kenji has already addressed NIAP comments 29-32 with his edits in PR#312, I'm going to move forward with merging his work. If there are separate comments or issue that need to be addressed, please open a separate issue or PR to do so.