HP 680n - JetDirect Print Server White Paper page 7

PC: Okay, so we've established a secure SSL connection which has authenticated the device and the
management station to each other, how does the web service determine what to do next?
SD: We use user authentication. We have Single Sign On capability. You send us your domain
credentials, we validate them and determine what group you belong to and then grant you rights off
of that group.
PC: What?
SD: Yes – that way you don't have to remember multiple usernames and passwords. It works just
like logging into the domain.
PC: Um – I don't think so. The only two things that know my username password are myself and the
Key Distribution Center that is part of the Domain Controller in my Active Directory environment.
When I'm authenticating myself, I'm sending over Kerberos Tickets, not my username/password
pair. Why on earth would I want to send your device my domain credentials?
SD: Um – for ease of use?
PC: Does your web service support Kerberos tickets to authenticate a user over the SSL channel?
SD: Um – no.
PC: Well, unless my domain credentials are converted into some form of security token before being
sent to your device, I'm really not interested. Do you have any alternatives?
SD: Well, we support Role based authentication where an Administrator can specify a username,
password, and role.
PC: Perfect. How do the Administrator credentials get configured?
SD: Well, we have defaults for the Administration credentials. You could have your outsourcer
configure them too.
PC: Give my outsourcer my device's administration credentials?
SD: ahhhhhhhhhhhhhhhh!!! (Runs screaming from the room)
In short, trust anchors are those things that need to be in place before security can even begin. As you
can see, having trust anchors for security can really impact things like ease-of-use and ease-of-
configuration. It is very important to understand what needs to be configured in order to establish
these trust anchors for the security of a given solution. Also, not only what needs to be configured,
but also, who is going to be configuring these items on the device in question.
the trust anchors in the previous solution?
• A secure Public Key Infrastructure (PKI). Easily the most overlooked and hardest part of using
SSL with digital certificates. Many corporations who have implemented a PKI have a team of
experts that do nothing but manage the PKI and maintain its security. It is non-trivial to do
correctly.
The configurations on both the device and management structure needed to support digital
•
certificates (e.g., the trusted CA certificate).
The implementation of SSL – is it implemented correctly on the management station and
•
device (e.g., a well tested and supported version of OpenSSL for instance?).
The implementation of the application that is using SSL – is it using SSL correctly, is the proper
•
SSL version being used, insecure cipher suites eliminated, enforced CRLs, correct time, and so
on.
The configuration of administration credentials on the device.
•
All of these things need to happen before secure device management can even begin! Hence, why
we call them trust anchors. Note that we can also ask the same trust questions about SSL – after all,
why should you trust the SSL protocol? Ultimately, it will come down to the type of answers you are
satisfied with. Let's examine SSL.
Used in the industry several years and has gone through 4 different revisions – SSLv1.0,
•
SSLv2.0, SSLv3.0, and TLS 1.0/1.1
• Standardized by the Internet Engineering Task Force
Widely deployed via OpenSSL and has been reasonably analyzed.
•
Supports open encryption and hashing algorithms such as AES and Triple DES.
•
These seem reasonable answers, but we will talk about this more in the section called The Verification
Problem. Back to our potential customer (PC) and security developer exchange (SD), you can see,
7
What are some of