Subject: [Ieprep] Security Requirements for SIPPING SEC-1 to SEC-5

From: "King, Kimberly S." <[email-masked]>
Date: Tue, 15 Oct 2002 08:06:23 -0400

"SEC-1: More rigorous: Prioritized access to network and end
             system resources imposes particularly stringent
             requirements on authentication and authorization
mechanisms
             since access to prioritized resources may impact overall
             system stability and performance, not just result in theft
             of, say, a single phone call.

             The authentication and authorization requirements for ETS
             calls are, in particular, much stronger than for emergency
             calls (112, 911), where wide access is the design
             objective, sacrificing caller identification if necessary."

We talked about this one before.  In reality, you aren't asking for anything
stronger than what is used in some commercial systems today, right?  I think
the "more rigorous" might cause some confusion.

       " SEC-2: Attack protection: Under certain emergency conditions,
             the network infrastructure, including its authentication
             and authorization mechanism, may be under attack. Thus,
             authentication and authorization must be able to survive
             such attacks and defend the resources against these
             attacks."

       " SEC-3: Independent of mechanism: Any indication of the resource
             priority mechanism must be independent of the
             authentication mechanism, since end systems will impose
             different constraints on the applicable authentication
             mechanisms. For example, some end systems may only allow
             user input via a 12-digit keypad, while others may have the
             ability to acquire biometrics or read smartcards."

        "SEC-4: Non-trusted end systems: Since ETS users may use devices
             that are not their own, systems should support
             authentication mechanisms that do not require the user to
             reveal her secret to the device."

An example acceptable solution might help to clarify here.  If a person
enters a PIN or simple password (yes, I know these things are weak security)
is that considered revealing the secret to the device?

       " SEC-5: Subversion of authentication infrastructure: Attackers
             may attempt to subvert the ETS infrastructure by
             overloading it with authentication attempts. Thus,
             mechanisms to delegate authentication and to authenticate
             as early as possible are required. In particular, the
             number of packets and the amount of other resources such as
             computation or storage that an unauthorized user can
             consume needs to be minimized. In general, unauthorized
             users must not be able to block CN resources, as they are
             likely to be more scarce than packet resources.  This
             implies that authentication and authorization must take
             place on the IP network side rather than using, say, a CN
             circuit to authenticate oneself via a DTMF sequence.

             Given the urgency during emergency events, normal
             statistical fraud detection may be less effective, thus
             placing a premium on reliable authentication."

It appears that statements on the number of packets or amount of resources,
or prevention of unauthorized users to block CN resources are policy
statements intended to motivate this requirement that says (redundantly?)
that SEC-2 must hold.  
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Ian Brown <[email-masked]>
Date: Tue, 15 Oct 2002 13:16:28 +0100

Kimberly asked:
> enters a PIN or simple password (yes, I know these things are
> weak security) is that considered revealing the secret to the device?

Yes.

You ideally want support for something like a smartcard or SIM that can
authenticate itself to the challenger without revealing the secret it uses
to do so to intermediate points (including the device such as a telephone
that it is working with).

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Oct 2002 11:07:35 -0400

> the "more rigorous" might cause some confusion.

Clearly, some commercial systems already satisfy this requirement. 
However, the requirement, discussed at the last meeting, I believe, was 
that since priority calls can do more harm than "normal" calls (by 
blocking resources, say), the requirements are in general, more strict. 
I suspect that this requirement won't make much difference in the 
design, but given previous discussions, I'd rather not re-open this one.

> is that considered revealing the secret to the device?

Yes. Note the 'should' - this may not be feasible or necessary in all cases.

> statements intended to motivate this requirement that says (redundantly?)

I agree that the two can be merged.