Yesterday I mentioned the constraints being found to use PEM RFC 1422
in the context of EDIFACT.
Today, Ill give feedback on the experices NASA/Sterling have had on
deploying telnet and ftp authentication and key distribution protocol
options, using the RFC 1422 infrastructure.
Bascially its very simple - we had problems with naming things which
are really services, and in the Internet are represented and
communtiated as hosts addresssed network ports.
We have ftp and telnet clients on UNIX, Mac and PCs which exchange a
signed token, which must specify the intended recipient. Unix servers
verify claimed identity by verifying an accompanying RFC 1422
Certificate Path, which authenticates the invoking user of the
telnet/ftp client process.
Now we currently use "<o=Internet;
presentationAddress=Internet=123.456.789.0ab>" as the distinguishedName
conveyed in the token. The authenticated client identity is relatively
normal - <c=US; o=NASA; ou=ARC; cn=Steve Schoch>, and is an identity
also used by that user when signing as the originator of PEM messages.
The problem comes on signing the return token, which to effect
authentication procedures needs to the same as the intendedRecipient
contained in the 1-way token.
And there of course lies the problem, that unless we form a CA
especially for telnet servers, named o=Internet, we immediately break
the name subordination rules again, upon verification of the 2-way
token by the client.
An option obviously is to name service addresses in the local name
space, and to name telnet services beneath those points.
<c=US; o=NASA; ou=ARC; presentationAddress=Internet=123.456.789.0ab>.
Any suggestions or comments willingly received. Otherwise the
integration of RFC 1422 with the IETF draft-telnet authentication and
secure-ftp protocols seems fine. We just all need to decide how to name
things.... as usual. The NASA intends to deploy these protected
services widely to Aeronautics companies.
Peter.