Bug #2958
OsmoSGSN doesn't authenticate on second/further ATTACH REQUEST
50%
Description
When a new/unknown MS performs an ATTACH REQUEST for the first time, it is authenticated.
However, if that same MS later performs a second ATTACH REQUEST, even with new P-TMSI/TLLI, it is not authenticated and we simply send an ATTACH ACCEPT. This is a security problem, as it means anyone can impersonate other known-existing IMSIs.
Related issues
History
#1 Updated by laforge over 1 year ago
- Assignee changed from sysmocom to lynxis
#2 Updated by lynxis over 1 year ago
- Status changed from New to In Progress
#3 Updated by lynxis over 1 year ago
- Status changed from In Progress to Stalled
- % Done changed from 0 to 50
I've started to refactor the whole GMM Attach Request handling into one fsm.
This issue is already fixed in the new fsm implementation.
I've created the ttcn3 testcase
SGSN_Tests.TC_attach_second_attemptfor this.
#4 Updated by lynxis over 1 year ago
- Related to Bug #3302: implement a FSM for GMM Attach Request added
#5 Updated by laforge over 1 year ago
- Tags set to TTCN3
#6 Updated by lynxis over 1 year ago
#7 Updated by lynxis about 1 year ago
The test is failing again, even under the new FSM.The HLR integration into the test must be rewritten.
At the moment, the TTCN test case SGSN_Tests.TC_attach_second_attempt still fails, but this is fails, because the
second attach does not proceed, because TTCN explicit expect to see an Insert Subscriber Data Request.
This request will be never sent from the SGSN, because it has still valid key data.
