HP 635n - JetDirect IPv6/IPsec Print Server Operating instructions

1
How to Use 802.1X on HP Jetdirect Print Servers
May 2008
Table of Contents:
Introduction ..................................................................................................................................... 2
What is 802.1X?............................................................................................................................. 6
Public Key Infrastructure and Public Key Certificate Basics .................................................................... 7
What Equipment is Required for 802.1X?......................................................................................... 15
Installing the Internet Authentication Service (IAS) .............................................................................. 16
Installing a Certificate Authority (CA)................................................................................................ 18
Creating a Certificate Template ....................................................................................................... 24
Issuing a Certificate........................................................................................................................ 30
Creating a User for HP Jetdirect....................................................................................................... 37
Switch Configuration...................................................................................................................... 40
HP Jetdirect Certificate Configuration ............................................................................................... 41
IAS Configuration .......................................................................................................................... 48
HP Jetdirect 802.1X Configuration................................................................................................... 57
Understanding Certificate Chains..................................................................................................... 61
Utilizing the Server ID Field on Jetdirect ............................................................................................ 66
Wireless and 802.1X..................................................................................................................... 72
ProCurve Switches and Identity Driven Management .......................................................................... 74
Summary ...................................................................................................................................... 74
Appendix A: Troubleshooting 802.1X ..............................................................................................75
Appendix B: Importing a Certificate ................................................................................................. 88
white
p
a
p
er

2
Introduction
In many organizations, the properties assigned to a user determine the rights they have on the
network. For example, some generic user types are shown in Figure 1 – User Types:
Figure 1 - User Types
An Authorized User is a user that has authenticated to the network and been given authorization to
access certain resources. An Unauthorized User is a user that was unable to be authenticated and is
placed in a network where they can do no harm. A Guest is a user that has been authenticated and
given restricted privileges. These users can connect in a variety of ways: dial-in, VPN using
broadband, wireless in a conference room, and through a direct connection to a switch as shown in
Figure 2 – Connection Types.
Figure 2 - Connection Types

3
In many cases, the connection type determines what attempts are made to authenticate and authorize
users. For example, a wireless connection or dial-in connection may require more stringent
credentials than a wired connection. For wired networks, unfortunately, Authorized Users,
Unauthorized Users, and Guests may have network access to the same equipment because no
authentication and authorization is being done. Uncontrolled access can cause problems – for
example, an Authorized Server with a security vulnerability can be exploited by an Unauthorized
User. Instead, we would like the wired network architecture to help us isolate equipment to those
users that require access to it. Virtual LANs are a common way to accomplish this isolation. See
Figure 3 – Virtual LANs.
Unauthorized
Guest
Authorized
`
Ethernet Edge Switch
Ethernet Edge Switch
Access Point Ethernet Edge Switch
Authorized User’s Server
Figure 3 - Virtual LANs
In Figure 3, independent switches that are each responsible for a single VLAN are used. Each VLAN
is for a particular type of user. There is typically a one-to-one correspondence between a VLAN and
an IP Subnet. Inter-VLAN communication is routed.
There are a couple of problems with this approach: (1) it doesn’t really make sense to have an
Unauthorized User VLAN for wired connection and (2) an Unauthorized User can simply plug their
computer into the Authorized VLAN switch to circumvent security. It is also very inefficient to dedicate
one switch to one VLAN. We could use a single switch and create Port-Based VLANs – for example,

4
ports 1 through 8 are always assigned to a specific VLAN – but as before, security can be
circumvented simply by attaching a computer to the desired port.
For Port-Based VLANS, what we really need are three separate solutions: (1) A way to authenticate
users, (2) A way to grant authenticated users access to the network, and (3) A way to assign
authenticated users to specific VLANs with network access restrictions, bandwidth constraints, and
other controls. A Port-Based VLAN solution with dynamic authentication is shown in Figure 4 –
Dynamic VLANs.
Figure 4 - Dynamic VLANs
Here, users are dynamically authenticated and assigned to specific VLANs regardless of what switch
port they use. A user that cannot be authenticated is assigned a VLAN where they can do no
damage. This behavior is fine for users, but what about printers and MFPs? Well, the nice part
about 802.1X is that wired HP Jetdirect print servers support it. All we need to do is create users in
Active Directory that correspond to Jetdirect-based printers and printer management servers, and we
can do what is shown in Figure 5 – Printing and Imaging VLANs.

5
Figure 5 – Printing and Imaging VLANs
As shown in Figure 5, printers and MFPs become full-fledged authenticated users of the network and
are assigned parameters that help them participate in the security and protection of the network and
its resources. This whitepaper will discuss IEEE 802.1X Port Access Control, in relation to printing and
imaging environments.

6
What is 802.1X?
IEEE 802.1X Port Access Control is a generic framework that allows infrastructure devices to control
an end-node’s access to the network. From an Ethernet perspective, we can refer to Figure 6 –
802.1X Switch Port, and see the breakdown of the Ethernet switch.
Switch Port 2
Switch Port 3
Switch Port N….
Switch Port 1
802.1X
LAN PORT
Local Intranet
To Switch
Bus
Ethernet Switch
Switch Port Detail
Figure 6 - 802.1X Switch Port
The end-node device must authenticate itself to the network before the local switch will grant it access
to the network. The end-node device has a valid link to the switch, but the only frames the switch will
forward from the end-node to the network are 802.1X Extensible Authentication Protocol (EAP)
frames. The technical terminology for the devices involved is shown in Figure 7 – 802.1X Terms.
Figure 7 - 802.1X Terms
In reality, the authenticator (switch) repackages 802.1X EAP frames from the Supplicant and sends
them to an Authentication Server. Based upon the configuration in the Authentication Server and the
information supplied by the Supplicant, the Supplicant is authenticated (or not). The result of this
authentication determines whether the switch port is “opened up” to the network for the Supplicant to
send/receive non-EAP frames for normal network operation. With HP ProCurve switches, the
Authentication Server can return much more information, such as the VLAN the Supplicant should be
assigned, bandwidth restrictions on the Supplicant, etc., and the switch dynamically configures itself
to support those parameters.

7
Because Extensible is part of the name of EAP, there are multiple protocols that have been developed
under the EAP framework. All HP Jetdirect products supporting 802.1X also support Protected EAP or
PEAP. Many HP Jetdirect products also support EAP-Transport Layer Security or EAP-TLS. These two
EAP flavors are the most popular for wired 802.1X deployments. Both protocols utilize SSL/TLS
running under EAP to authenticate the Authentication Server which sets up a secure tunnel. When
shopping on the Internet, SSL/TLS is often used to protect the transaction over the network and to
establish trust that the web site being contacted is really that web site and not an imposter’s web site.
A cornerstone of trust in SSL/TLS is the digital certificate. For PEAP and EAP-TLS, the Authentication
Server sends over a digital certificate which the supplicant will attempt to validate. After a series of
checks are performed, the supplicant will need to establish that the digital certificate was created by a
trusted authority. If it passes that test, an SSL/TLS tunnel can be established. At this point, PEAP and
EAP-TLS diverge. PEAP uses the tunnel to securely pass credentials via another protocol, typically a
username and password, to the Authentication Server while EAP-TLS uses a client digital certificate for
authentication. Because how digital certificates are created and validated, we will need to cover them
in depth.
Public Key Infrastructure and Public Key Certificate Basics
Have you ever seen the warning dialog shown in Figure 8 when using https:// (e.g., going to any
secure web site, such as a login or shopping cart) in a web browser?
Figure 8 – Security Alert
This dialog is entitled “Security Alert” and it talks about something called a “security certificate”.
What is a security certificate?
NOTE: A security certificate, digital certificate, public key certificate, and identity certificate are
different terms which all refer to the same thing in this whitepaper.
Well, a security certificate is there to help identify the web site as one that can be trusted. However,
the Security Alert dialog is telling us that we may not want to trust this security certificate – which
indirectly means that this web site may not be the web site we think it is. There are two warning
icons associated with this dialog. The help text by the first warning icon prompts us to view the
certificate. Let’s click on “View Certificate”.

8
Figure 9 – Certificate Details
In Figure 9, we see there is a red X on the certificate, indicative of a security problem. In addition,
there is a very specific error message: “This certificate cannot be verified up to a trusted certification
authority.” Here we see that the “Issued By” is entitled “RootCA”. What the message is trying to say
is that “RootCA”, who issued the certificate “635n”, is not trusted.
A useful analogy is to think of the certificate issuer like a Department of Motor Vehicles (DMV). Each
state in the United States has a DMV run by the state’s government. The DMV issues driver’s licenses
which grant the privilege to drive in a given state. A person that goes to the DMV to get a driver’s
license must pass a series of tests that helps the DMV determine if they are fit to drive on the state’s
roads. The state’s Highway Patrol, a group which enforces the rules of the road, recognizes the
validity of the DMV to issue driver’s licenses. Therefore, if one violates one of the rules of the road
and is pulled over by a Highway Patrol officer, showing a driver’s license issued by the DMV is a
requirement. The Highway Patrol will not recognize a driver’s license issued by an institution other
than the DMV as being valid. In short, the DMV is a trusted third party that issues “certificates”
(driver’s licenses) to individuals. These “certificates”, issued by the DMV, are trusted by the Highway
Patrol.
The Security Alert dialog is troubling because it is indicative of a trust problem. In the terms of our
analogy, it would be like a driver, who has been pulled over by the Highway Patrol, handing the
officer a driver’s license that the driver’s mother wrote for him indicating that her son had been
granted the privilege to drive in the state. While a note from mom may be trusted by her sister, it isn’t
trusted by the Highway Patrol.
In essence, a digital certificate, one used by computers, binds an identity to a key and needs to be
issued by a trusted third party. What is a key? A key is a secret that is used in cryptographic
algorithms. There are public keys and private keys used for asymmetric cryptography and symmetric
keys used for symmetric cryptography. Let’s look at symmetric cryptography first.

9
Message Delivery
User
Encryption Performed
User
Decryption Performed
Unencrypted Message
Unencrypted Message
Figure 10 – Symmetric Cryptography
In Figure 10, the confidentiality provided to the message is done via a single key. Because the same
key is used for encryption and decryption, this process is known as symmetric cryptography.
Symmetric cryptography commonly has two attributes associated with it:
•It performs well – it is fast and easy to implement
•It has a key distribution problem – how do you get the symmetric key to everyone that needs
it in a secure way?
Asymmetric cryptography is also available and functions very different than symmetric cryptography.
It has two keys – one Public and one Private. The private key is not shared with anyone. The Public
key is like a public telephone number. You can share it with everyone. Let’s look at Figure 11 –
Asymmetric Cryptography.

10
Figure 11 – Asymmetric Cryptography
Here we can see the difference between asymmetric and symmetric cryptography. One key can be
used for encryption and then the corresponding key can be used for decryption. It appears that
asymmetric cryptography has solved the key distribution issue; however there are two new attributes
usually associated with asymmetric cryptography
•It is slow
•It has a trust problem. How do I know that this is John’s public key and not someone
pretending to be John?
To solve the first problem, asymmetric cryptography is usually used to securely distribute symmetric
keys and sign hash codes. In short, what is actually being encrypted and decrypted is usually much
smaller than actual messages. This has the nice benefit of solving the key distribution issue with
symmetrical cryptography. So, in essence, symmetric keys are sent securely using asymmetric
cryptography and the actual messages themselves are protected using symmetric cryptography.
Cool! We get the flexibility of asymmetric cryptography and the speed of symmetric cryptography.
Now we only have to solve the trust problem.
In order to solve the trust problem, five things will need to be discussed:
•A certificate authority – a trusted third party that creates digital certificates from certificate
requests
•A certificate request – a public key associated with identity information that will serve as the
basic building block for a digital certificate that the certificate authority will create and sign.
•A digital certificate – a public key associated with identity information that is digitally signed
by the certificate authority.
•A digital signature – the hash of the digital certificate encrypted by the private key of the
certificate authority.

11
•A hash – also known as a message digest. A hash is the output of a one way function that
attempts to ensure the integrity of the message (i.e., that the message has not been altered).
It is usually combined with authentication information to ensure that the message originator
can be authenticated and that the integrity of the message has not been disrupted. You can
think of a hash like an advanced checksum or an advanced cyclic redundancy check (CRC).
Let’s cover hashes and digital signatures first. We’ll assume that Jack wants to send John a message.
Jack wants to make sure that John knows the message came from him and that the message was not
altered in transit. However, Jack doesn’t care about confidentiality – in other words, the actual
message can be sent “in the clear” – but does care about authentication and integrity. We can
accomplish this through hashes and digital signatures as shown in Figure 12.
Figure 12 – Digital Signature
In Figure 12, Jack has sent John a message with a digital signature. Let’s see how John would
validate this message to make sure it came from Jack and was not altered. Refer to Figure 13.

12
Figure 13 – Digital Signature Verification
Here we see how John uses Jack’s public key to verify the message. Jack’s public key is the only key
that can decrypt the digital signature and obtain the hash value of the message that Jack calculated
before sending the message. Because the hash was encrypted with Jack’s private key, which no one
should know but Jack, John can be sure that Jack was the one that sent it.
We still have a problem – How does John know that Jack’s public key really belongs to the person
that he knows as “Jack”? There are many people in the world named “Jack” – how does John know
it isn’t one of them? We still need a trusted third party to provide Jack’s public key in a format John
can trust and we probably need Jack to provide a little more identity information too. Here is where
the Certificate Authority comes into play. Refer to Figure 14 – Certificate Authority.

13
Jack
Certificate Authority
(Also performs Identity Verification on Jack)
Jack’s Public Key
Jack’s Private Key
CA’s Public Key
CA’s Private Key
Certificate Request
Identity Info +
Jack’s Public Key
Jack
Jack’s Private Key
(Stays Private)
Jack’s Public Key
Jack’s Public Key
Certificate
Jack’s Public Key
Create
Key Pair
One-Way Function/Hash Function
Identity Info +
CA Info +
Encryption
Identity Info +
CA Info +
CA’s Digital
Signature
Preliminary Certificate
Figure 14 – Certificate Authority
Jack goes through a key pair generation process and creates a public and private key pair. The
private key is kept secret. The public key is associated with some identity information and is given to
a Certificate Authority. The certificate authority generates a certificate, usually specific to a purpose
such as email, and signs the certificate with its digital signature. Assuming there is a place where
these digital certificates are publicly available, as long as Jack and John can agree to trust a specific
certificate authority, they’ll be fine trusting certificates signed by that authority. Refer to Figure 15.

14
Figure 15 – Public Key Certificates
Here we can see that everyone’s public key certificate is, well – um, public. The important thing to
note is that the certificate authority also has a public key certificate that identifies itself. This certificate
is signed with its own private key and is a “self-signed” certificate. There is no “higher” level of trust
then the top level certificate authority. Therefore, John and Jack must choose a particular certificate
authority that they both trust. In most cases, there is a hierarchy of certificate authorities at customer
sites. This forms what is known as a certificate chain and there is a top level CA or Root CA where
the ultimate trust resides.
Also, we should take care to point out that there is usually a difference between Internet trust using
certificates and Intranet trust using certificates. Internet trust will involve well-known certificate
authorities like Verisign and Entrust. However, Intranet models usually revolve around Microsoft’s
certificate authority that comes with Windows 2003 server. Each company establishes their own
Public Key Infrastructure (PKI) that includes an entire policy around certificates.
Now that we have covered some basics around certificates, we can talk specifically about Jetdirect.
Jetdirect is an embedded system and as a result, has limited storage space for certificates. Jetdirect

15
can store one Identity certificate and one CA certificate. The CA certificate tells Jetdirect which
identity certificates should be trusted (i.e., must be signed by that CA) when Jetdirect is receiving a
certificate from another entity. Jetdirect’s Identity certificate is the certificate that is sent out when
another entity requests it. It is important to note that the CA certificate on Jetdirect is configured strictly
to provide the trust point for identity certificates that are sent to Jetdirect – the identity certificates
received from other entities must be signed by that CA or be part of a chain which ends in that CA.
Since Jetdirect only has one Identity certificate that can be configured, it must be capable of being
used in a variety of situations. Jetdirect can act as a client or a server, depending on the protocol
being used. For instance, if a web browser is using HTTPS to communicate to Jetdirect, Jetdirect will
return its Identity certificate as part of the SSL/TLS negotiation process, which will identify Jetdirect as
a server. In other cases, like EAP-TLS, Jetdirect will send its Identity certificate for client authentication.
By default, Jetdirect will create a “self-signed” certificate the first time it is powered on. This certificate
is not secure because it has not been signed by a trusted CA. An important step in the security of a
Jetdirect product is to replace the default self-signed Identity certificate with one that has been signed
by a trusted CA.
What Equipment is Required for 802.1X?
Essentially, we need the following:
•A printer or Jetdirect device (Supplicant) that supports 802.1X
•A switch (Authenticator) that supports port-based authentication via 802.1X
•A RADIUS server (Authentication Server), such as the Internet Authentication Service (IAS)
from Microsoft
Many HP Jetdirect devices can be upgraded for free to support 802.1X. Refer to
http://www.hp.com/go/webjetadmin_firmware for the latest firmware updates. HP Jetdirect products
that support 802.1X are as follows:
•J7934A/J7934G 620n EIO 10/100TX Print Server with the latest firmware available – PEAP
Support
•J7960A/J7960G 625n EIO 10/100/1000T Print Server with the latest firmware available –
PEAP support
•J7997G 630n EIO 10/100/1000T Print Server with the latest firmware available – PEAP &
EAP-TLS support
•J7961A/J7961G 635n EIO IPv6 & IPsec Print Server with the latest firmware available –
PEAP & EAP-TLS support
•J8007G 690n EIO Wireless 802.11b/g Print Server – PEAP & EAP-TLS & LEAP support
•Embedded Jetdirect products with the latest firmware available – PEAP & EAP-TLS support
•J7942A/J7942G en3700 USB External Print Server with the latest firmware available – PEAP
support.
Microsoft’s IAS comes with Windows Server 2003. This means that two of the three items needed for
802.1X authentication are potentially free! All that is needed is the switch (Authenticator).
Ethernet switches have long supported 802.1X. Check your switch documentation for information on
whether or not it is supported. The HP ProCurve line of edge devices support 802.1X with higher-end
edge switches supporting rich methods of assigning VLANs, bandwidth constraints, access control
lists, etc. Refer to http://www.hp.com/go/procurve
Rather than generically explain what is necessary to setup and configure 802.1X for HP Jetdirect, this
whitepaper will go through a step-by-step tutorial of sample installations and configurations of the
802.1X components.

16
NOTE: The following sections describe in detail the various steps to use 802.1X.
Various software programs are installed and configured. The installation and
configuration of these programs, such as Microsoft’s Certificate Authority, are done
for learning purposes and should not be considered as HP’s recommended
configurations or installations for production networks.
Installing the Internet Authentication Service (IAS)
Where are we?
Step 1 Installing Internet Authentication Service
Step 2 Installing a Certificate Authority
Step 3 Creating a Certificate Template
Step 4 Issuing a Certificate
Step 5 Creating a User for HP Jetdirect
Step 6 Switch Configuration
Step 7 HP Jetdirect Certificate Configuration
Step 8 IAS Configuration
Step 9 HP Jetdirect 802.1X Configuration
Microsoft ships a RADIUS server by default. This RADIUS server must be installed from the
Add/Remove Windows component wizard.
Using
Windows
2003, we can
simply go to
the Control
Panel and
select
“Add/Remove
Programs” and
then select
Windows
Components.

17
Select
Networking
Services and
press Details.
Then select
Internet
Authentication
Service and
press OK.
Complete the
wizard and
allow the
installation to
complete.

18
Installing a Certificate Authority (CA)
Where are we?
Step 1 Installing Internet Authentication Service
Step 2 Installing a Certificate Authority
Step 3 Creating a Certificate Template
Step 4 Issuing a Certificate
Step 5 Creating a User for HP Jetdirect
Step 6 Switch Configuration
Step 7 HP Jetdirect Certificate Configuration
Step 8 IAS Configuration
Step 9 HP Jetdirect 802.1X Configuration
Using Windows 2003 Enterprise Edition or Windows Server 2003 Datacenter Edition, we can simply
go to the Control Panel and select “Add/Remove Programs” and then select Windows Components.
Select
“Certificate
Services”,
then click
Next.

19
In this
example, we
are installing
an Enterprise
Root CA.
Click Next.
NOTE:
If you select
any other kind
of CA, the
certificate
template
functionality
described
below will not
be available.
Here is our
CA identity
information.
Click Next
and complete
the
installation.
Once the installation has completed, we can go to Start -> Run -> mmc

20
The Microsoft
Management
Console is a
framework that
allows various
“Snap-Ins” to
be loaded.
Each “Snap-In”
manages a
specific service.
For example,
there is a
“Snap-In” to
manage the
Certificate
Authority (or
Certification
Authority as
Microsoft
sometimes calls
it).
At this point, we want to load in separate Snap-Ins into the Microsoft Management Console (MMC).
Snap-Ins are modules that provide specific management functionality to the MMC. Go to the File
menu and select “Add/Remove Snap-In”.