.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH XX XXXXXX 2001
+.ds RH 13 November 2001
.ds CH
.na
.hy 0
.in 0
.nf
-Network Working Group P. Riikonen
+Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-silc-spec-04.txt XX XXXXXXX 2001
-Expires: XXXXXXX
+draft-riikonen-silc-spec-04.txt 13 November 2001
+Expires: 13 May 2002
.in 3
2.3 Communication in the Network .............................. 6
2.4 Channel Communication ..................................... 7
2.5 Router Connections ........................................ 7
- 2.6 Backup Routers ............................................ 8
-3 SILC Specification ............................................ 10
- 3.1 Client .................................................... 10
- 3.1.1 Client ID ........................................... 10
- 3.2 Server .................................................... 11
- 3.2.1 Server's Local ID List .............................. 12
- 3.2.2 Server ID ........................................... 13
- 3.2.3 SILC Server Ports ................................... 14
- 3.3 Router .................................................... 14
- 3.3.1 Router's Local ID List .............................. 14
- 3.3.2 Router's Global ID List ............................. 15
- 3.3.3 Router's Server ID .................................. 15
- 3.4 Channels .................................................. 16
- 3.4.1 Channel ID .......................................... 17
- 3.5 Operators ................................................. 17
- 3.6 SILC Commands ............................................. 18
- 3.7 SILC Packets .............................................. 18
- 3.8 Packet Encryption ......................................... 19
- 3.8.1 Determination of the Source and the Destination ..... 19
- 3.8.2 Client To Client .................................... 20
- 3.8.3 Client To Channel ................................... 21
- 3.8.4 Server To Server .................................... 22
- 3.9 Key Exchange And Authentication ........................... 22
- 3.9.1 Authentication Payload .............................. 22
- 3.10 Algorithms ............................................... 24
- 3.10.1 Ciphers ............................................ 24
- 3.10.2 Public Key Algorithms .............................. 25
- 3.10.3 Hash Functions ..................................... 26
- 3.10.4 MAC Algorithms ..................................... 26
- 3.10.5 Compression Algorithms ............................. 26
- 3.11 SILC Public Key .......................................... 27
- 3.12 SILC Version Detection ................................... 29
-4 SILC Procedures ............................................... 30
- 4.1 Creating Client Connection ................................ 30
- 4.2 Creating Server Connection ................................ 31
- 4.2.1 Announcing Clients, Channels and Servers ............ 32
- 4.3 Joining to a Channel ...................................... 33
- 4.4 Channel Key Generation .................................... 34
- 4.5 Private Message Sending and Reception ..................... 34
- 4.6 Private Message Key Generation ............................ 35
- 4.7 Channel Message Sending and Reception ..................... 35
- 4.8 Session Key Regeneration .................................. 36
- 4.9 Command Sending and Reception ............................. 37
- 4.10 Closing Connection ....................................... 37
-5 Security Considerations ....................................... 38
-6 References .................................................... 38
-7 Author's Address .............................................. 40
+3 SILC Specification ............................................ 8
+ 3.1 Client .................................................... 8
+ 3.1.1 Client ID ........................................... 9
+ 3.2 Server .................................................... 10
+ 3.2.1 Server's Local ID List .............................. 10
+ 3.2.2 Server ID ........................................... 11
+ 3.2.3 SILC Server Ports ................................... 12
+ 3.3 Router .................................................... 12
+ 3.3.1 Router's Local ID List .............................. 12
+ 3.3.2 Router's Global ID List ............................. 13
+ 3.3.3 Router's Server ID .................................. 14
+ 3.4 Channels .................................................. 14
+ 3.4.1 Channel ID .......................................... 16
+ 3.5 Operators ................................................. 16
+ 3.6 SILC Commands ............................................. 16
+ 3.7 SILC Packets .............................................. 17
+ 3.8 Packet Encryption ......................................... 17
+ 3.8.1 Determination of the Source and the Destination ..... 17
+ 3.8.2 Client To Client .................................... 18
+ 3.8.3 Client To Channel ................................... 19
+ 3.8.4 Server To Server .................................... 20
+ 3.9 Key Exchange And Authentication ........................... 20
+ 3.9.1 Authentication Payload .............................. 20
+ 3.10 Algorithms ............................................... 22
+ 3.10.1 Ciphers ............................................ 22
+ 3.10.2 Public Key Algorithms .............................. 23
+ 3.10.3 Hash Functions ..................................... 24
+ 3.10.4 MAC Algorithms ..................................... 24
+ 3.10.5 Compression Algorithms ............................. 25
+ 3.11 SILC Public Key .......................................... 25
+ 3.12 SILC Version Detection ................................... 27
+ 3.13 Backup Routers ........................................... 28
+ 3.13.1 Switching to Backup Router ......................... 29
+ 3.13.2 Resuming Primary Router ............................ 30
+ 3.13.3 Discussion on Backup Router Scheme ................. 32
+4 SILC Procedures ............................................... 33
+ 4.1 Creating Client Connection ................................ 33
+ 4.2 Creating Server Connection ................................ 34
+ 4.2.1 Announcing Clients, Channels and Servers ............ 35
+ 4.3 Joining to a Channel ...................................... 36
+ 4.4 Channel Key Generation .................................... 37
+ 4.5 Private Message Sending and Reception ..................... 38
+ 4.6 Private Message Key Generation ............................ 38
+ 4.7 Channel Message Sending and Reception ..................... 39
+ 4.8 Session Key Regeneration .................................. 39
+ 4.9 Command Sending and Reception ............................. 40
+ 4.10 Closing Connection ....................................... 41
+5 Security Considerations ....................................... 41
+6 References .................................................... 42
+7 Author's Address .............................................. 44
Every router has their primary route which is a connection to another
router in the network. Unless there is only two routers in the network
must not routers use each other as their primary routes. The router
-connections in the network must form a circular.
+connections in the network must form a ring.
The issue of router connections are very important especially with SILC
broadcast packets. Usually all router wide information in the network is
-distributed by SILC broadcast packets.
-
-
-.ti 0
-2.6 Backup Routers
-
-Backup routers may exist in the cell in addition of the primary router.
-However, they must not be active routers and act as routers in the cell.
-Only one router may be acting as primary router in the cell. In the case
-of failure of the primary router may one of the backup routers become
-active. The purpose of backup routers are in case of failure of the
-primary router to maintain working connections inside the cell and outside
-the cell and to avoid netsplits.
-
-Backup routers are normal servers in the cell that are prepared to take
-over the tasks of the primary router if needed. They need to have at
-least one direct and active connection to the primary router of the cell.
-This communication channel is used to send the router information to
-the backup router.
-
-Backup router must know everything that the primary router knows to be
-able to take over the tasks of the primary router. It is the primary
-router's responsibility to feed the data to the backup router. If the
-backup router does not know all the data in the case of failure some
-connections may be lost. The primary router of the cell must consider
-the backup router being normal router server and feed the data
-accordingly.
-
-In addition of having direct connection to the primary router of the
-cell the backup router must also have connection to the same router
-the primary router of the cell is connected. However, it must not be
-active router connection meaning that the backup router must not use
-that channel as its primary route and it must not notify the router
-about having connected servers, channels and clients behind it. It
-merely connects to the router. This sort of connection is later
-referred as being passive connection. Some keepalive actions may be
-needed by the router to keep the connection alive.
-
-The primary router notifies its primary router about having backup
-routers in the cell by sending SILC_PACKET_CELL_ROUTERS packet. If
-and when the primary router of the cell becomes unresponsive, its
-primary router knows that there exists backup routers in the cell.
-After that it will start using the first backup router sent in the
-packet as router of that cell.
-
-In this case the backup router must notify its new primary router about
-the servers, channels and clients it has connected to it. The primary
-router knows that this server has become a router of the cell because
-of failure of the primary router in the cell. It must also cope with
-the fact that the servers, channels and clients that the new backup
-router announces are not really new, since they used to exist in the
-primary router of the cell.
-
-It is required that other normal servers has passive connections to
-the backup router(s) in the cell. Some keepalive actions may be needed
-by the server to keep the connection alive. After they notice the
-failure of the primary router they must start using the connection to
-the first backup router as their primary route.
-
-It is RECOMMENDED that there would be at least one backup router in
-the cell. It is NOT RECOMMENDED to have all servers in the cell acting
-as backup routers as it requires establishing several connections to
-several servers in the cell. Large cells can easily have several
-backup routers in the cell.
-
-The order of the backup routers are decided at the primary router of the
-cell and servers and backup routers in the cell must be configured
-accordingly. It is not required that the backup server is actually
-active server in the cell. Backup router may be a spare server in the
-cell that does not accept normal client connections at all. It may be
-reserved purely for the backup purposes. These, however, are cell
-management issues.
-
-If also the first backup router is down as well and there is another
-backup router in the cell then it will start acting as the primary
-router as described above.
+distributed by SILC broadcast packets. This sort of ring network, with
+ability to have other direct routes in the network cause interesting
+routing problems. The [SILC2] discusses the routing of packets in this
+sort of network in more detail.
.ti 0
connection to router on same port. Normal server MUST NOT connect to other
cell's router except in situations where its cell's router is unavailable.
-Servers and routers in the SILC network are considered to be trusted.
-With out a doubt, servers that are set to work on ports above 1023 are
-not considered to be trusted. Also, the service provider acts important
-role in the server's trustworthy.
-
.ti 0
3.2.1 Server's Local ID List
-
-
-
-
-
.ti 0
3.3.3 Router's Server ID
packets are what actually makes the protocol. Packets in SILC network
are always encrypted using, usually the shared secret session key
or some other key, for example, channel key, when encrypting channel
-messages. The SILC Packet Protocol is a wide protocol and is described
+messages. It is not possible to send packet in SILC network without
+encryption. The SILC Packet Protocol is a wide protocol and is described
in [SILC2]. This document does not define or describe details of
SILC packets.
-
-
-
.ti 0
3.8 Packet Encryption
server to become server operator. In this case, Authentication Payload is
used.
-
-
-
-
-
-
-
-
-
-
The format of the Authentication Payload is as follows:
o Public Data (variable length) - This is defined only if
the authentication method is public key. If it is any other
- this field does not exist and the Public Data Length field
- is set to zero (0).
+ this field MAY include a random data for padding purposes.
+ However, in this case the field MUST be ignored by the
+ receiver.
When the authentication method is public key this includes
128 to 4096 bytes of non-zero random data that is used in
If the authentication method is password based, the Authentication
Data field includes the plaintext password. It is safe to send
plaintext password since the entire payload is encrypted. In this
-case the Public Data Length is set to zero (0).
+case the Public Data Length is set to zero (0), but MAY also include
+random data for padding purposes. It is also RECOMMENDED that maximum
+amount of padding is applied to SILC packet when using password based
+authentication. This way it is not possible to approximate the length
+of the password from the encrypted packet.
If the authentication method is public key based (or certificate)
the Authentication Data is computed as follows:
Additional public key algorithms MAY be defined to be used in SILC.
-
-
.ti 0
3.10.3 Hash Functions
Additional MAC algorithms MAY be defined to be used in SILC.
+
+
.ti 0
3.10.5 Compression Algorithms
use compression which is the mode that must be supported by all SILC
implementations.
-
-
The following compression algorithms are defined:
.in 6
Protocol version MAY provide both major and minor version. Currently
implementations MUST set the protocol version and accept the protocol
-version as SILC-1.0-<software version>.
+version as SILC-1.0-<software version>. If new protocol version causes
+in compatibilities with older version the the <minor> versio number MUST
+be incremented. The <major> is incremented if new protocol version is
+fully incompatible.
Software version MAY provide major, minor and build version. The
software version MAY be freely set and accepted.
.in 3
+.ti 0
+3.13 Backup Routers
+
+Backup routers may exist in the cell in addition of the primary router.
+However, they must not be active routers and act as routers in the cell.
+Only one router may be acting as primary router in the cell. In the case
+of failure of the primary router may one of the backup routers become
+active. The purpose of backup routers are in case of failure of the
+primary router to maintain working connections inside the cell and outside
+the cell and to avoid netsplits.
+
+Backup routers are normal servers in the cell that are prepared to take
+over the tasks of the primary router if needed. They need to have at
+least one direct and active connection to the primary router of the cell.
+This communication channel is used to send the router information to
+the backup router. When the backup router connects to the primary router
+of the cell it MUST present itself as router server in the Connection
+Authentication protocol, even though it is normal server as long as the
+primary router is available. Reason for this is that the configuration
+needed in the responder end requires usually router connection level
+configuration. The responder, however must understand and treat the
+connection as normal server (except when feeding router level data to
+the backup router).
+
+Backup router must know everything that the primary router knows to be
+able to take over the tasks of the primary router. It is the primary
+router's responsibility to feed the data to the backup router. If the
+backup router does not know all the data in the case of failure some
+connections may be lost. The primary router of the cell must consider
+the backup router being actual router server when it feeds the data to
+it.
+
+In addition of having direct connection to the primary router of the
+cell, the backup router must also have connection to the same router
+the primary router of the cell is connected. However, it must not be
+active router connection meaning that the backup router must not use
+that channel as its primary route and it must not notify the router
+about having connected servers, channels and clients behind it. It
+merely connects to the router. This sort of connection is later
+referred as being passive connection. Some keepalive actions may be
+needed by the router to keep the connection alive.
+
+It is required that other normal servers have passive connections to
+the backup router(s) in the cell. Some keepalive actions may be needed
+by the server to keep the connection alive. After they notice the
+failure of the primary router they must start using the connection to
+the first backup router as their primary route.
+
+Also, if any other router in the network is using the cell's primary
+router as its own primary router, it must also have passive connection
+to the cell's backup router. It too is prepared to switch to use the
+backup router as its new primary router as soon as the orignal primary
+router becomes unresponsive.
+
+All of the parties of this protocol knows which one is the backup router
+of the cell from their local configuration. Each of the entity must
+be configured accordingly and care must be taken when configuring the
+backup routers, servers and other routers in the network.
+
+It must be noted that some of the channel messages and private messages
+may be lost during the switch to the backup router. The announcements
+assures that the state of the network is not lost during the switch.
+
+It is RECOMMENDED that there would be at least one backup router in
+the cell. It is NOT RECOMMENDED to have all servers in the cell acting
+as backup routers as it requires establishing several connections to
+several servers in the cell. Large cells can easily have several
+backup routers in the cell.
+
+The order of the backup routers are decided at the configuration phase.
+All the parties of this protocol must be configured accordingly to
+understand the order of the backup routers. It is not required that
+the backup server is actually active server in the cell. Backup router
+may be a spare server in the cell that does not accept normal client
+connections at all. It may be reserved purely for the backup purposes.
+These, however, are cell management issues.
+
+If also the first backup router is down as well and there is another
+backup router in the cell then it will start acting as the primary
+router as described above.
+
+
+.ti 0
+3.13.1 Switching to Backup Router
+
+When the primary router of the cell becomes unresponsive, for example
+by sending EOF to the connection, all the parties of this protocol MUST
+replace the old connection to the primary router with first configured
+backup router. The backup router usually needs to do local modifications
+to its database in order to update all the information needed to maintain
+working routes. The backup router must understand that clients that
+were orignated from the primary router are now originated from some of
+the existing server connections and must update them accordingly. It
+must also remove those clients that were owned by the primary router
+since those connections were lost when the primary router became
+unresponsive.
+
+All the other parties of the protocol must also update their local
+database to understand that the route to the primary router will now go
+to the backup router.
+
+The servers connected to the backup router must announce their clients,
+channels, channel users, channel user modes and channel modes to the
+backup router. This is to assure that none of the important notify
+packets were lost during the switch to the backup router. The backup
+router must check which of these announced entities it already have
+and distribute the new ones to the primary route.
+
+The backup router too must announce its servers, clients, channels
+and other information to the new primary router. The primary router
+of the backup router too must announce its informations to the backup
+router. Both must process only the ones they do not know about. If
+any of the announced modes does not match then they are enforced in
+normal manner defined later in this specification.
+
+
+.ti 0
+3.13.2 Resuming Primary Router
+
+Usually the primary router is unresponsive only a short period of time
+and it is intended that the original router of the cell will reassume
+its position as primary router when it comes back online. The backup
+router that is now acting as primary router of the cell must constantly
+try to connect to the original primary router of the cell. It is
+RECOMMENDED that it would try to reconnect in 30 second intervals to
+the primary router.
+
+When the connection is established to the primary router the backup
+resuming protocol is executed. The protocol is advanced as follows:
+
+ 1. Backup router sends SILC_PACKET_RESUME_ROUTER packet with type
+ value 1 the primary router that came back online. The packet
+ will indicate the primary router has been replaced by the backup
+ router. After sending the packet the backup router will announce
+ all of its channels, channel users, modes etc. to the primary
+ router.
+
+ 2. Backup router sends SILC_PACKET_RESUME_ROUTER packet with type
+ value 2 to its current primary router to indicate that it will
+ resign as being primary router. Then, backup router sends the
+ SILC_PACKET_RESUME_ROUTER packet with type value 1 to all
+ connected servers to also indicate that it will resign as being
+ primary router.
+
+ 3. Backup router also send SILC_PACKET_RESUME_ROUTER packet with
+ type value 2 to the router that is using the backup router
+ currently as its primary router.
+
+ 4. Any server and router that receives the SILC_PACKET_RESUME_ROUTER
+ with type value 1 or 2 must reconnect immediately to the
+ primary router of the cell that came back online. After they
+ have created the connection they MUST NOT use that connection
+ as active primary route but still route all packets to the
+ backup router. After the connection is created they MUST send
+ SILC_PACKET_RESUME_ROUTER with type value 3 back to the
+ backup router. The session ID value found in the first packet
+ MUST be set in this packet.
+
+ 5. Backup router MUST wait for all packets with type value 3 before
+ it continues with the protocol. It knows from the session ID values
+ set in the packet when it have received all packets. The session
+ value should be different in all packets it have send earlier.
+ After the packets is received the backup router sends the
+ SILC_PACKET_RESUME_ROUTER packet with type value 4 to the
+ primary router that came back online. This packet will indicate
+ that the backup router is now ready to resign as being primary
+ router. The session ID value in this packet MUST be the same as
+ in first packet sent to the primary router. During this time
+ the backup router should still route all packets it is receiving
+ from server connections.
+
+ 6. The primary router receives the packet and send the
+ SILC_PACKET_RESUME_ROUTER with type value 5 to all connected servers
+ including the backup router. It also sends the packet with type
+ value 6 to its primary router, and to the router that is using
+ it as its primary router. The Session ID value in this packet
+ SHOULD be zero (0).
+
+ 7. Any server and router that receives the SILC_PACKET_RESUME_ROUTER
+ with type value 5 or 6 must switch their primary route to the
+ new primary router and remove the route for the backup router, since
+ it is not anymore the primary router of the cell. They must also
+ update their local database to understand that the clients are
+ not originated from the backup router but from the locally connected
+ servers. After that they MUST announce their channels, channel
+ users, modes etc. to the primary router. They must not use the
+ backup router connection after this and the connection is considered
+ to be passive connection. The implementations SHOULD be able
+ to disable the connection without closing the actual link.
+
+After this protocol is executed the backup router is now again normal
+server in the cell that has the backup link to the primary router. The
+primary router feeds the router specific data again to the backup router.
+All server connections in the backup router are considered passive
+connections.
+
+When the primary router of the cell comes back online and connects
+to its primary router, the remote primary router must send the
+SILC_PACKET_RESUME_ROUTER with type value 20 indicating that the
+connection is not allowed since the router has been replaced by an
+backup router. The session ID value in this packet SHOULD be zero (0).
+When the router receives this packet it must not use the connection
+as active connection but to understand that it cannot act as primary
+router in the cell. It must wait that the backup router connects to
+it, and the backup resuming protocol is executed.
+
+The following type values has been defined for SILC_PACKET_RESUME_ROUTER
+packet:
+
+ 1 SILC_SERVER_BACKUP_START
+ 2 SILC_SERVER_BACKUP_START_GLOBAL
+ 3 SILC_SERVER_BACKUP_START_CONNECTED
+ 4 SILC_SERVER_BACKUP_START_ENDING
+ 5 SILC_SERVER_BACKUP_START_RESUMED
+ 6 SILC_SERVER_BACKUP_START_GLOBAL
+ 20 SILC_SERVER_BACKUP_START_REPLACED
+
+If any other value is found in the type field the packet must be
+discarded. The SILC_PACKET_RESUME_ROUTER packet and its payload
+is defined in [SILC2].
+
+
+.ti 0
+3.13.3 Discussion on Backup Router Scheme
+
+It is clear that this backup router support is not able to handle all
+possible situations arrising in unreliable network environment. This
+scheme for example does not handle situation when the router actually
+does not go offline but the network link goes down temporarily. It would
+require some intelligence to figure out when it is best time to switch
+to the backup router. To make it even more complicated it is possible
+that the backup router may have not lost the network link to the primary
+router.
+
+Other possible situation is when the network link is lost temporarily
+between two primary routers in the SILC network. Unless the routers
+notice the link going down they cannot perhaps find alternative routes.
+Worst situation is when the link goes down only for a short period of
+time, thus causing lag. Should the routers or servers find alternative
+routes if they cannot get response from the router during the lag?
+When alternative routes are being found it must be careful not to
+mess up existing primary routes between routers in the network.
+
+It is suggested that the current backup router scheme is only temporary
+solution and existing backup router protocols are studied further. It
+is also suggested that the backup router specification will be separated
+from this SILC specification Internet-Draft and additional specification
+is written on the subject.
.ti 0
The router MUST also announce the local servers by compiling list of
ID Payloads into the SILC_PACKET_NEW_ID packet.
+Also, clients' modes (user modes in SILC) MUST be announced. This is
+done by compiling a list of Notify Payloads with the
+SILC_NOTIFY_UMODE_CHANGE nofity type into the SILC_PACKET_NOTIFY packet.
+
+Also, channel's topics MUST be announced by compiling a list of Notify
+Payloads with the SILC_NOTIFY_TOPIC_SET notify type into the
+SILC_PACKET_NOTIFY packet.
+
The router which receives these lists MUST process them and broadcast
the packets to its primary route.
distribute the message to all clients on the channel by sending the
channel message destined explicitly to a client on the channel.
+See the [SILC2] for description of channel messege routing for router
+servers.
+
See [SILC2] for description of channel message encryption and decryption
process.
MUST be protected with the new key.
-
-
.ti 0
4.9 Command Sending and Reception
on the security and the integrity of the servers and administrators that
are running the service. It is recommended that some form of registration
is required by the server and router administrator prior acceptance to
-the SILC Network. The clients must be able to trust the servers they
-are using.
+the SILC Network. Even though, the SILC protocol is secure in a network
+of mutual distrust between clients, servers, routers and adminstrators
+of the servers, the client should be able to trust the servers they are
+using if they whish to do so.
-It must also be noted that if the client requires absolute security by
-not trusting any of the servers or routers in the SILC Network, this can
+It however must be noted that if the client requires absolute security
+by not trusting any of the servers or routers in the SILC Network, it can
be accomplished by negotiating private keys outside the SILC Network,
-either using SKE or some other key negotiation protocol, or to use some
+either using SKE or some other key exchange protocol, or to use some
other external means for distributing the keys. This applies for all
-messages, private messages and channel messages. It is important to note
-that SILC, like any other security protocol is not full proof system and
-cannot secure from insecure environment; the SILC servers and routers could
-very well be compromised. However, to provide acceptable level of security
-and usability for end user the protocol uses many times session keys or
-other keys generated by the servers to secure the messages. If this is
-unacceptable for the client or end user, the private keys negotiatied
-outside the SILC Network should always be used. In the end it is always
-implementor's choice whether to negotiate private keys by default or
-whether to use the keys generated by the servers.
+messages, private messages and channel messages.
+
+It is important to note that SILC, like any other security protocol is
+not full proof system and cannot secure from insecure environment; the
+SILC servers and routers could very well be compromised. However, to
+provide acceptable level of security and usability for end user the
+protocol use many times session keys or other keys generated by the
+servers to secure the messages. This is intentional design feature to
+allow ease of use for end user. This way the network is still usable,
+and remains encrypted even if the external means of distributing the
+keys is not working. The implementation, however, may like to not
+follow this design feature, and always negotiate the keys outside SILC
+network. This is acceptable solution and many times recommended. The
+implementation still must be able to work with the server generated keys.
+
+If this is unacceptable for the client or end user, the private keys
+negotiatied outside the SILC Network should always be used. In the end
+it is always implementor's choice whether to negotiate private keys by
+default or whether to use the keys generated by the servers.
It is also recommended that router operators in the SILC Network would
form a joint forum to discuss the router and SILC Network management
Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
.ti 0
7 Author's Address
EMail: priikone@silcnet.org
-This Internet-Draft expires XXX
+This Internet-Draft expires 13 Nay 2002
projects / crypto.git / blobdiff