Project

General

Profile

Actions

Bug #2872

open

OsmoMSC doesn't check if CIPHER MODE COMPLETE contains cipher that matches REQUEST

Added by laforge about 6 years ago. Updated over 4 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
A interface (general)
Target version:
-
Start date:
01/24/2018
Due date:
% Done:

0%

Resolution:
Spec Reference:

Description

When the MSC requests a cipher from a set of ciphers as stated in the BSSMAP CIPHER MODE REQUEST, we should check if the (bsc-)chosen cipher actually is within that set.

Care must be taken as the 'chosen algorithm' IE is optional.

A corresponding TTCN-3 test case should be developed, trying to COMPLETE with a cipher that's not in the set of those REQUESTed

Actions #1

Updated by laforge almost 6 years ago

  • Assignee changed from 4368 to stsp
Actions #2

Updated by stsp over 5 years ago

"BSSMAP CIPHER MODE REQUEST" doesn't seem to exist.
You probably meant BSSMAP CIPHER MODE CMD instead?

Actions #3

Updated by stsp over 5 years ago

  • Status changed from New to In Progress
Actions #4

Updated by stsp over 5 years ago

This proposed patch adds a TTCN3 test for this issue:
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/12332

At present the MSC responds with a LU reject after receiving a CIPHER MODE COMPLETE with an invalid cipher.
The test looks for this LU reject and passes when it is received.

Is this the correct behaviour? Should the MSC respond in some other way?

Actions #5

Updated by neels over 5 years ago

re "command" vs "request": the things can be named differently on the layers, e.g. there's the Cipher Mode Command on BSSMAP, but Cipher Mode Request on 04.08...

Actions #6

Updated by stsp about 5 years ago

The above test has been merged. neels says the current osmo-msc behaviour which the test checks for (expect a LU reject) is correct as it is.
Can this issue be closed?

Actions #7

Updated by neels about 5 years ago

this issue says that osmo-msc should check that the cipher matches the request,
and the issue implies that osmo-msc doesn't check that.
If it turns out that osmo-msc does indeed reject a mismatch already, that's nice.

How about the side thing there, if the chosen algorithm is not provided in the response?
I guess osmo-msc should accept then. Does it? (If they mismatch then, the ciphered data will not be decipherable anyway.)
Maybe duplicate the test for that situation.

Actions #8

Updated by stsp about 5 years ago

See https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/12347 for additional tests,
and https://gerrit.osmocom.org/c/osmo-msc/+/12349 for related osmo-msc changes.

The tests are not complete yet -- they pass both with and without the osmo-msc changes
because they don't verify which cipher the MSC really ends up using. Could you suggest
a good way of doing that?

Actions #9

Updated by laforge over 4 years ago

  • Status changed from In Progress to Feedback
  • Assignee changed from stsp to neels

the patch back then was not merged. neels: Is this still an issue in the "new msc" ?

Actions #10

Updated by neels over 4 years ago

IIRC there were some problems in those patches.
Current OsmoMSC doesn't verify the chosen cipher AFAIR, only stores it. So it should still be an open issue.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)