| Component |
Specification |
Status |
|
A = Adopted
R = Recommended
U = Under review
F = For future consideration
|
|
Hypertext transfer protocols |
RFC 2616, Upgrade mechanism
in HTTP/1.1 to initiate Transport Layer Security (TLS) over an
existing TCP connection |
A |
E-mail Transport
|
E-mail products that
support interfaces that conform to the SMTP/MIME for message transfer.
This includes RFC 2821, RFC 2822, RFC 2045, RFC 2046, RFC 2646,
RFC 2047, RFC 2231, RFC 2048, RFC 3023, RFC 2049
Note: e-mail attachments may conform to the file types for browsers
and viewers as defined for the specific delivery channel, see
Section 7 – e-Services access and
Channels
|
A |
E-mail transport security |
Unless security requirements
dictate otherwise, e-mail products that provide secure mail transport
facilities shall as a minimum conform to RFC 3207 |
A |
E-mail content security |
Unless security requirements
dictate otherwise, and only when appropriate, S/MIME v3 will be
used for pan-government messaging security when end-to-end security
is required. This includes RFC 3369, RFC 2631, RFC 2632, RFC 2633 |
A |
Mailbox access
|
Unless security requirements
dictate otherwise, e-mail products that provide mail access facilities
shall as a minimum conform to POP3 for remote mailbox access.
This includes RFC 1939, RFC 1957 and RFC 2449.
Where additional mail facilities are required, unless security requirements dictate otherwise, e-mail products that provide advanced mail access facilities shall conform to IMAP for remote mailbox access. This includes RFC 3501, RFC 2342, RFC 2971, RFC 3502, RFC 3503 and RFC 3510.
Interfaces for e-mail systems are to conform to POP3 for mailbox
retrieval |
A |
Secure mailbox access |
Mailbox access over insecure
networks shall use HTTPS, conforming to the Transport security
standards listed below. This includes RFC 2595 when using TLS
with IMAP, POP3 and ACAP to access mailbox. |
A |
Directory |
GSI Notice 1/2003 Information
GSI Directory Schema.
LDAP v3 is to be used for general purpose directory user access |
A |
Domain name services |
DNS (RFC 1035)
The UK
Government domain naming guidelines are at policy. GSI domain-naming
follows these guidelines as far as possible. GSI e-mail addressing
specifications are defined in GNC Technical Notice 2/2001 (Domain
Names, DNS and E-mail Addressing) |
A |
File transfer protocols |
FTP (RFC 959) (with restart
and recovery) and HTTP
(RFC 2616) for file transfer |
A |
Newsgroup services |
NNTP (RFC 977) where required,
subject to security constraints |
A |
Real-time messaging services |
The Model and Requirements
for Instant Messaging and Presence Protocol (impp) are defined
by the IETF RFC 2778, RFC 2779* |
R |
Extensible Messaging and Presence
Protocol (XMPP) is a series of IETF Internet drafts for a standard
protocol for streaming XML elements in order to exchange messages
and presence information in close to real time |
U |
Session Initiation Protocol
(SIP) for Instant Messaging RFC 3428 is a standard for Instant
Messaging that focuses on the application of RFC 3261 (SIP) to
the suite of services collectively known as instant messaging
and presence (IMP). The aim is to produce an interoperable standard
for these services outlined in RFC 2779
The IETF
WG SIMPLE (Session Initiation Protocol (SIP) for Instant Messaging
and Presence Leveraging Extensions) have series of Internet drafts
for real time messaging services |
U |
*Real
time messaging. At the current time there are numerous real time
messaging protocols in use, largely as components of commercial
instant messaging services (for example: AIM, ICQ, MSN and Yahoo
Messenger). Interoperability between services based on the various
protocols is limited. A number of Internet drafts are currently
in production to define common profiles and common services for
gateways between real time messaging systems. Also, end-user desktop-based
utilities are available that combine the functionality of the
commercial instant messaging services and support connectivity
between users of the various commercial instant messaging services. |
LAN/WAN interworking
|
IP v4 (RFC 791)
Departments are to interconnect using IP v4 and plan for migration
to IP v6 in due course |
A |
Security |
Central government departments
should refer to the Manual of Protective Security.
Other parts of the public sector should refer to the e-Government
strategy framework and guidelines on security
|
A |
The following specifications
are to be used to meet the requirements of the e-Government Security
Framework where appropriate: |
IP security
(Authenticated header) |
IP-SEC (RFC 2402/2404) |
A |
IP encapsulation security
(for VPN requirements) |
ESP (RFC 2406) |
A |
Transport security |
SSL v3/TLS (RFC 2246) |
A |
|
Encapsulation security |
CMS (RFC3369) |
A |
Timestamp token |
TSP (RFC 3161) |
A |
Secure Shell |
Departments requiring
Secure Shell (SSH) support should reference the following Internet Drafts:
SSH File Transfer Protocol
SSH Transport Layer Protocol
SSH Authentication Protocol
SSH Connection Protocol
SSH Protocol Architecture
Generic Message Exchange Authetication for SSH
For further information see the IETF SHH WG
|
U |
Certain e-government information
is ‘sensitive’ in that it might contain personal or
commercially confidential information, but it does not fall within
the definitions of government classified information. For the
protection of such information, e.g. data and private keys, the
following specifications are advised: |
Encryption algorithms |
3DES, AES (FIPS 197), Blowfish
|
A |
For signing |
RSA, DSA, DSS (FIPS 186-2)
|
A |
For key transport |
RSA, DSA |
A |
For hashing |
SHA-512, SHA-256 (FIPS 180-2), for backward compatibility SHA-1 and MD-5 should also be supported.
|
A |
The above is not exhaustive
and is intended as a guide. For advice on specific implementations
or specific algorithms please contact CSIA |
Transport |
TCP (RFC 793)
UDP (RFC 768) where required, subject to security constraints |
A |
Bookmark
this section
