Subject: [Ieprep] RE: Folts' stated requirements: security

From: Fred Baker <[email-masked]>
Date: Thu, 04 Apr 2002 15:50:57 -0800

At 01:43 PM 4/4/2002, Folts, Harold wrote:
>For GETS in the PSTN a basic credit card authentication process is used.

OK, so one issue is the authentication method. Presumably, 
GETS-in-the-Internet wants to use the same card.

The IETF isn't going to standardize the US Government's credit card 
(presumably it doesn't have to), but there should be an appropriate 
mechanism that the credit card information could be fed into to identify 
the device to a network that has an appropriate contract with the US 
Government.

This sounds to me like some variation on a AAA question. There is either 
going to be a standard RADIUS/DIAMETER/whatever protocol exchange between a 
specified application on the laptop for the purpose, or there is going to 
be a web page that the laptop displays that has the relevant fields.

Is it fair to say that the US Government's requirement is that one of those 
two mechanisms exist for any business that it writes such a contract with? 
Is it fair to then write a requirements document (a short one) that 
specifies the expectations so that it can be referred to by (a) the AAA 
Working Group, which is writing the DIAMETER-based protocols, and (b) a 
business that chooses to contract with the US Government?

Could we identify someone to write that hopefully-short internet draft, 
specifying the information that AAA WG needs, and pointing to the USG 
document for further detail?

>This needs keying of some 32 digits to establish a call. Hopefully in the
>future new technology can be applied that will streamline this process.

gee whiz; I use a program called "soft-token", to which I authenticate 
using a PIN, and which then gives me a one-time password. I click on 
something and it gets copied to the clipboard, I select where I want it to 
go, and I click something else to make the clip-board contents be there. 
That's a UI issue. What the IETF works on are protocol issues; I would 
assume that the 32 digits are functionally the same; all we need is an 
appropriate attribute in DIAMETER that can carry the digits, right?

>The ETS intrusion security issues are spoofing, impeding ETS traffic 
>(Denial of service), changing content, as well as non-traceability and 
>prevention of eavesdropping for sensitive and confidential traffic for 
>some government officials.

Again, this sounds like a combination of UI, service, and protocol issues. 
IPSEC Authentication and Encryption, TLS encryption, SSL, MIME, and so on 
already exist. If we can identify the requirements for the protocol part 
(does it need to work through a NAT, for example?), our part should be 
fairly straightforward. The service issues become issues such as: does AOL 
or whoever have to implement encryption within Instant Messenger, and does 
that have to extend to the blackberry or whatever? Those, we can write an 
internet draft to specify, but at the bottom line they are contract issues 
between the US Government and its contractor networks.

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Ian Brown <[email-masked]>
Date: Fri, 5 Apr 2002 11:39:12 +0100

> GETS-in-the-Internet wants to use the same card.

There needs to be authorisation of at least the following, from most basic
to more complex:

(1) That an emergency worker's IP device be allowed to use a given network
(eg a local 802.11 net). If a remote network has a roaming agreement with
the emergency worker's home network, it can use AAA to authenticate the
device. The necessary secrets can be stored on the device (say in a SIM) or
be user-entered (such as a GETS-type PIN).

(2) That a user is authorised for particular layer 7 priority mechanisms in
a server (such as a telephony gateway). This is relatively simple if a
device just connects to servers within its home domain. The authorisation
could be done as part of the user registration, or even just using the exact
same method per-call as GETS (user calls a non-geographical number which is
recognised by the telephony gateway or an element in the PSTN, which then
verifies the GETS PIN). This gets trickier if we want roaming devices to be
able to get this type of priority in servers on remote networks.

(3) That a given device is authorised to use (ie has paid for) particular
layer 2/3 priority mechanisms (such as a given AF queue). This would most
likely happen as part of the DIAMETER exchange in (1). So we might need to
ask the AAA group to support this functionality. This would be useful for
any kind of roaming QoS support.

> document for further detail?

I can write this, or add it to the security draft.

> appropriate attribute in DIAMETER that can carry the digits, right?

(or ideally something that reveals the PIN to as few intermediate elements
as possible).

Ian.

---

From: Fred Baker <[email-masked]>
Date: Fri, 05 Apr 2002 08:23:32 -0800

>I can write this, or add it to the security draft.

please do