https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6348
Johannes Lange <jodd@xxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |jodd@xxxxxx
Resolution|FIXED |
--- Comment #5 from Johannes Lange <jodd@xxxxxx> 2011-11-13 12:39:51 CET ---
With the current changes NAS messages with the "null ciphering algorithm" EEA0
are not handled. I think the code before rev. 39096 tried to detect such
messages.
See TS 24.007 section 11.2.3.1 or TS 24.301 section 9.1:
1) if the message is a plain NAS message:
a) protocol discriminator;
b) EPS bearer identity or security header type;
c) procedure transaction identity;
d) message type;
e) other information elements, as required.
2) if the message is a security protected NAS message:
a) protocol discriminator;
b) security header type;
c) message authentication code;
d) sequence number;
e) plain NAS message, as defined in item 1.
With this a security protected NAS message using EEA0 will have a header of
type 2) with the security header type indicating a security protected message.
But it also contains 2e) which means that there is another header of type 1)
following where the security header type is 0b0000 (plain NAS message) and the
protocol discriminator is of type 0b0010 (ESM), 0b0111 (EMM) or 0b1111
(conformance tests).
The only issue in the handling before rev. 39096 is at line 4555:
pd = tvb_get_guint8(tvb,offset)&0x0f;
The masking removes the check for security header type == 0b0000 (plain NAS
message). It should work without the masking as intended.
There might be a small probability that a actually ciphered message is
misintepreted as null ciphered with this but as EEA0 is widely used for testing
it would make more sense to try to dissect the NAS message.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.