--- /dev/null
+.pl 10.0i
+.po 0
+.ll 7.2i
+.lt 7.2i
+.nr LL 7.2i
+.nr LT 7.2i
+.ds LF Riikonen
+.ds RF FORMFEED[Page %]
+.ds CF
+.ds LH Internet Draft
+.ds RH 2 February 2004
+.ds CH
+.na
+.hy 0
+.in 0
+.nf
+Network Working Group P. Riikonen
+Internet-Draft
+draft-riikonen-presence-attrs-03.txt 2 February 2004
+Expires: 2 August 2004
+
+.in 3
+
+.ce 2
+User Online Presence and Information Attributes
+<draft-riikonen-presence-attrs-03.txt>
+
+.ti 0
+Status of this Memo
+
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC 2026. Internet-Drafts are
+working documents of the Internet Engineering Task Force (IETF), its
+areas, and its working groups. Note that other groups may also
+distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time. It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html
+
+The distribution of this memo is unlimited.
+
+
+.ti 0
+Abstract
+
+This document defines set of attributes that can represent the online
+user's presence in a network, and to provide general information about
+the user. The purpose is to provide a generic mechanism to share
+online presence and status, and general information about the user
+to be used in several kind of network protocols and applications.
+These attributes could be used by for example chat and conferencing
+protocols (such as Instant Message protocols), network games, and
+other similar network protocols and applications that has online
+users in a network.
+
+
+
+
+
+
+
+.ti 0
+Table of Contents
+
+.nf
+1 Introduction .................................................. 2
+ 1.1 Requirements Terminology .................................. 2
+2 Attributes Concept ............................................ 3
+ 2.1 Requesting Attributes ..................................... 3
+ 2.2 Replying Attributes ....................................... 3
+ 2.3 Attribute Data Types ...................................... 4
+ 2.4 Attribute Payload ......................................... 4
+ 2.5 Attributes ................................................ 5
+3 Security Considerations ....................................... 11
+4 References .................................................... 12
+5 Author's Address .............................................. 13
+6 Full Copyright Statement ...................................... 13
+
+
+.ti 0
+1. Introduction
+
+This document defines set of attributes that can represent the online
+user's presence in a network, and to provide general information about
+the user. The purpose is to provide a generic mechanism to share
+online presence and status, and general information about the user
+to be used in several kind of network protocols and applications.
+These attributes could be used by for example chat and conferencing
+protocols (such as Instant Message protocols), network games, and
+other similar network protocols and applications that has online
+users in a network.
+
+This document does not define these attributes to be used in any
+specific protocol, but assumes that they can be used generally in
+any kind of online network protocol. Furthermore, the document
+pays attention to special needs of various protocols, such as
+mobile network protocols, which requires the attributes to be
+both robust and compact. The attributes are also considered to be
+easily implementable and for this reason a clear and robust structure
+was chosen for the attributes.
+
+This document is strongly influenced by Wireless Village Initiative
+where similar attributes are defined, and credits for the ideas are
+due there. However, they are defined only in the context of the
+Wireless Village, and the format of the attributes used is not
+suitable for general purpose usage.
+
+
+.ti 0
+1.1 Requirements Terminology
+
+The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+MAY, and OPTIONAL, when they appear in this document, are to be
+interpreted as described in [RFC2119].
+
+
+.ti 0
+2 Attributes Concept
+
+Many network protocols needs a way to transfer and retrieve status
+information about users in a network. For example, many chat and
+conferencing protocols such as IRC, and all Instant Message (IM)
+protocols, such as ICQ has a way to retrieve presence and status
+information about the users in the network. This could be added to
+several other kind of network protocols as well, and for this reason
+a defined mechanism to provide these informations is needed.
+
+The attributes are usually requested by an entity in the network
+from other entity, usually a user or end user's device in the network.
+The recipient then replies to each of the requested attributes and
+sends the reply to the requester.
+
+This document does not define the actual transport for requesting and
+providing the replies to the requests, since this is irrelevant.
+This document defines a payload for requesting, and providing the
+information, but how the payload is transported is not defined in
+this document. In a client-server network model the user requesting
+attributes usually destine the request to a remote user and the
+server relays the attributes to the remote user. It is also possible
+that the concept is not user-to-user, but the server replies to the
+requested attributes on behalf of the user.
+
+
+.ti 0
+2.1 Requesting Attributes
+
+When an entity requests attributes from a user in the network,
+it assembles a list of Attribute Payloads, and sets the requested
+attribute value into the payload. Each requested attribute is a separate
+Attribute Payload and they MUST be appended one after the other. The
+requester need to understand that the recipient may not understand all
+the requested attributes, and may not reply to all of the requested
+attributes. The requester also need to understand that the recipient
+may reply with additional attributes that were not requested.
+
+
+.ti 0
+2.2 Replying Attributes
+
+When en entity receives the Attribute Payloads it parses them one after
+the other. The entity can parse each of the Attribute Payload separately
+since it knows the length of the current attribute; next attribute
+begins after the current attribute ends. The entity then checks the
+requested attribute and SHOULD reply either with valid value or with
+an indication that the attribute is unsupported or unknown. It is
+also possible to reply with additional attributes that were not
+requested.
+
+When replying to the requested attributes the entity assembles a list
+of Attribute Payloads, each including the attribute type and the
+actual attribute data.
+
+
+.ti 0
+2.3 Attribute Data Types
+
+This section defines basic data types that can appear in the attributes
+in this document.
+
+All integer values are stored in the MSB first order. The size of the
+integer is provided separately with the attribute. Integer is
+represented as "integer" in this documentation.
+
+Strings MUST be UTF-8 [RFC2279] encoded, and include 2 bytes length
+field indicating the length of the string. Hence, when "string" value
+appears in this documentation it is encoded as:
+
+.in 6
+Length Type Value
+2 bytes integer Length of String field
+variable UTF-8 String
+.in 3
+
+If string is not present then the length field includes zero (0)
+value.
+
+Boolean value is represented as "boolean" and its size is 1 byte.
+Value 0x00 indicates false value and value 0x01 indicates true value.
+
+
+.ti 0
+2.4 Attribute Payload
+
+The Attribute Payload is used to request an attribute, and to reply
+to the requested attribute. One payload includes one attribute.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Attribute | Attr Flags | Attribute Length |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Attribute Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 1: Attribute Payload
+
+
+.in 6
+o Attribute (1 byte) - Indicates the attribute included in this
+ Attribute Payload.
+
+o Attribute Flags (1 byte) - Indicates the flags associated
+ with this attribute. The following flags are defined:
+
+ 0x01 ATTRIBUTE_FLAG_INVALID
+
+ The attribute value in Attribute Data is invalid, or
+ unknown. This may be set to indicate that a requested
+ attribute is not available, its value is unknown, or
+ sender does not understand it.
+
+ 0x02 ATTRIBUTE_FLAG_VALID
+
+ The attribute value is included in the Attribute Data.
+
+ When sending this payload to request attributes this value
+ MUST be set to zero (0) value. When sending a reply to the
+ request this field MUST NOT include a zero (0) value.
+
+o Attribute Length (2 bytes) - Indicates the length of the
+ Attribute Data field, not including any other field.
+
+o Attribute Data (variable length) - The Attribute Data.
+ The contents of this field is attribute specific, defined
+ subsequently.
+.in 3
+
+
+.ti 0
+2.5 Attributes
+
+The following values can appear in the Attribute field in the
+Attribute Payload to indicate the content of the attribute. The
+format of the attribute data is represented as length, type and
+value. Example:
+
+.in 6
+Length Type Value
+2 bytes integer Some integer value
+variable string Some string
+1 byte boolean Boolean value
+.in 3
+
+When sending multiple Attribute Payloads it is possible to include
+multiple same attributes in the packet.
+
+
+.in 6
+0 ATTRIBUTE_NONE
+
+ This attribute is reserved and it is never sent.
+
+
+1 ATTRIBUTE_USER_INFO
+
+ This attribute includes general information about the user, their
+ name and contact information. The content of this attribute is
+ a VCard version 3.0 as defined in RFC 2426 [RFC2426] and RFC 2425
+ [RFC2425]. Note that some of the information that VCard provides
+ can be also provided in the means of providing other attributes.
+ The rationale for this is that the VCard does not provide all the
+ information, or with the required precision that may be desired in
+ some applications. It is therefore RECOMMENDED that this attribute
+ would be used to provide only basic and constant user information,
+ such as name and contact information, but not online status
+ information.
+
+ Length Type Value
+ variable VCard Basic user information
+
+
+2 ATTRIBUTE_SERVICE
+
+ This attribute indicates a service in the Internet that the user
+ is currently using or has logged in. It also shows when the user
+ started using the service, and how long user has been idle in the
+ service. The value of this attribute is as follows:
+
+ Length Type Value
+ 4 bytes integer Service Port (IANA specified)
+ variable string Service Address
+ 1 byte boolean Online status. If this is set to
+ 0x01 (true) it means the user is online
+ in the service. Set to 0x00 (false) when
+ out of reach.
+ variable string Signon date and time, UTC date, format as
+ in ISO 8601
+ 4 bytes integer Idle time
+
+
+3 ATTRIBUTE_STATUS_MOOD
+
+ This attribute indicates the mood of the user. It can indicate
+ whether the user is eager to participate in the network. The
+ value of this attribute is as follows:
+
+ Length Type Value
+ 4 bytes integer Mood mask (values ORed together)
+
+ The following mood values are defined:
+
+ 0x00000000 MOOD_NORMAL No specific mood, normal mood
+ 0x00000001 MOOD_HAPPY The user feels happy
+ 0x00000002 MOOD_SAD The user feels sad
+ 0x00000004 MOOD_ANGRY The user feels angry
+ 0x00000008 MOOD_JEALOUS The user feels jealous
+ 0x00000010 MOOD_ASHAMED The user feels ashamed
+ 0x00000020 MOOD_INVINCIBLE The user feels invincible
+ 0x00000040 MOOD_INLOVE The user feels being in love
+ 0x00000080 MOOD_SLEEPY The user feels sleepy
+ 0x00000100 MOOD_BORED The user feels bored
+ 0x00000200 MOOD_EXCITED The user feels excited
+ 0x00000400 MOOD_ANXIOUS The user feels anxious
+
+
+4 ATTRIBUTE_STATUS_FREETEXT
+
+ This attribute includes the user's online status free text. It
+ can provide personal status as a text message. The contents of
+ this attribute is a UTF-8 encoded free text string.
+
+ Length Type Value
+ variable string Free text status string
+
+
+5 ATTRIBUTE_STATUS_MESSAGE
+
+ This attribute includes the user's online status message. It
+ could provide for example a multi media message showing the status
+ of the user. The contents of this attribute is a MIME object,
+ which can be used to provide for example video, audio, image or
+ other similar status message. It could also provide a reference
+ to the message, for example an URL address.
+
+ Length Type Value
+ variable MIME Status message as MIME object
+
+
+6 ATTRIBUTE_PREFERRED_LANGUAGE
+
+ This attribute indicates the preferred language to be used when
+ communicating. The encoding of this attribute is as follows:
+
+ Length Type Value
+ variable string ISO 639-2/T three letter code
+
+
+7 ATTRIBUTE_PREFERRED_CONTACT
+
+ This attribute indicates the preferred contact methods. It can
+ indicate the method the user prefers when contacting. The value
+ of this attribute is as follows:
+
+ Length Type Value
+ 4 bytes integer Contact mask (values ORed together)
+
+ The following contact methods are defined:
+
+ 0x00000000 CONTACT_NONE No specific preferred contact method
+ 0x00000001 CONTACT_EMAIL Email is preferred
+ 0x00000002 CONTACT_CALL Phone call is preferred
+ 0x00000004 CONTACT_PAGE Paging is preferred
+ 0x00000008 CONTACT_SMS SMS is preferred
+ 0x00000010 CONTACT_MMS MMS is preferred
+ 0x00000020 CONTACT_CHAT Chatting is preferred
+ 0x00000040 CONTACT_VIDEO Video conferencing is preferred
+
+
+8 ATTRIBUTE_TIMEZONE
+
+ This attribute can be used to provide the current local time for
+ the user. The contents of this attribute is a UTF-8 encoded
+ string and the format of the string is UTC time zone defined
+ in the ISO 8601.
+
+ Length Type Value
+ variable string UTC date, format as in ISO 8601
+
+ Note that ATTRIBUTE_USER_INFO may also provide this information.
+ However it is RECOMMENDED that this attribute is used when
+ current time zone information is provided.
+
+
+9 ATTRIBUTE_GEOLOCATION
+
+ This attribute can be used to provide measured global location of
+ the user. How this information is gathered is out of scope of
+ this document. The attribute can provide latitude and longitude
+ lateral positions, but also a vertical position. A parameter
+ describing the accuracy of the information can also be provided.
+
+ Length Type Value
+ variable string Longitude (ex. 31 17 14.321W)
+ variable string Latitude (ex. 12 11 21.2N)
+ variable string Altitude
+ variable string Accuracy in meters
+
+ Note that ATTRIBUTE_USER_INFO may also provide this information,
+ however it does not have the vertical position, or the accuracy
+ parameter. It is RECOMMENDED that this attribute is used when
+ providing current global position information.
+
+
+10 ATTRIBUTE_DEVICE_INFO
+
+ This attribute includes information about the user's device.
+ The encoding of this attribute is as follows:
+
+ Length Type Value
+ 4 bytes integer Device type
+ variable string Name of the device manufacturer
+ variable string Device version
+ variable string Device model
+ variable string Device language (ISO 639-2/T)
+
+ The following Device types are defined:
+
+ 0 DEVICE_COMPUTER Device is a computer
+ 1 DEVICE_MOBILE_PHONE Device is a mobile phone
+ 2 DEVICE_PDA Device is a PDA
+ 3 DEVICE_TERMINAL Device is a terminal
+
+
+11 ATTRIBUTE_EXTENSION
+
+ This attribute indicates that the attribute value is vendor,
+ application or service specific attribute extension. This field
+ MUST include a MIME object, which is the extension value. This
+ document does not specify any explicit MIME objects for this
+ attribute.
+
+ Length Type Value
+ variable MIME Attribute extension as MIME object
+
+
+12 ATTRIBUTE_USER_PUBLIC_KEY
+
+ This attribute includes the user's public key or certificate.
+ As the public key and certificate format depends on which sort
+ of algorithm or certificate encoding user is using we need to
+ define a mechanism to differentiate the public key types from
+ each other. This document specifies the most common public keys
+ and certificates. This attribute can be used to deliver the
+ user's public key, and it MUST be present if also the
+ ATTRIBUTE_USER_DIGITAL_SIGNATURE is present. Note that the
+ recipient of this attribute SHOULD verify the public key from
+ a third party, for example from Certification Authority. If
+ there are more than one ATTRIBUTE_USER_PUBLIC_KEY attributes set
+ and ATTRIBUTE_USER_DIGITAL_SIGNATURE is also set, the digital
+ signature SHOULD be verifiable with the first set public key.
+
+ Length Type Value
+ variable string Public key/certificate type
+ variable data Public key/certificate data
+
+ The following public key/certificate types are defined:
+
+ ssh-rsa SSH RSA public key [SSH-TRANS]
+ ssh-dss SSH DSS public key [SSH-TRANS]
+ silc-rsa SILC RSA public key [SILC1]
+ silc-dss SILC DSS public key [SILC1]
+ pgp-sign-rsa OpenPGP RSA certificate [RFC2440]
+ pgp-sign-dss OpenPGP DSS certificate [RFC2440]
+ x509v3-sign-rsa X.509 Version 3 RSA certificate [RFC2459]
+ x509v3-sign-dss X.509 Version 3 DSS certificate [RFC2459]
+
+ Most of these public key/certificate types are equivalent to
+ the types specified for SSH protocol [SSH-TRANS] and are expected
+ to be officially assigned by IANA.
+
+ The encoding of the public key/certificate data in the attribute
+ is done in the manner defined in their respective definitions.
+
+ Note that these public keys are intended for signing. Some
+ certificates may have a key usage restrictions and same key cannot
+ be used for both encryption and signing. Therefore, the name
+ of the certificate type indicates if they are intended for
+ signing only.
+
+
+13 ATTRIBUTE_SERVER_PUBLIC_KEY
+
+ This attribute includes a third party server or authority public
+ key or CA certificate and MUST be present if the attribute
+ ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also present. The format
+ for this attribute is identical to the ATTRIBUTE_USER_PUBLIC_KEY
+ attribute. If there are more than one ATTRIBUTE_SERVER_PUBLIC_KEY
+ attributes set and ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also set,
+ the digital signature SHOULD be verifiable with the first set public
+ key.
+
+
+14 ATTRIBUTE_USER_DIGITAL_SIGNATURE
+
+ This attribute value includes digital signature of all Attribute
+ Payloads except this attribute. This signature can be provided by
+ the user. This attribute SHOULD be last attribute provided in the
+ reply so that it is easier for the receiver to compute the signature
+ data to be verified. The format and encoding of this attribute
+ depends on the public key or certificate used to produce the
+ signature. See the ATTRIBUTE_USER_PUBLIC_KEY for all public keys
+ and certificates that can be used to produce a signature.
+
+ Length Type Value
+ variable data Digital signature data
+
+ The encodings are as follows per public key/certificate type:
+
+ ssh-rsa and ssh-dss Defined in [SSH-TRANS]
+ silc-rsa and silc-dss Defined in [SILC1]
+ pgp-sign-rsa and pgp-sign-dss Defined in [RFC2440]
+ x509v3-sign-rsa and x509v3-sign-dss Defined in [PKCS7]
+
+ The procedure producing the signature and encoding it are done
+ in the manner defined in their respective definitions, see the
+ provided references. Also the hash function used with the
+ signature procedure is defined by the public key/certificate type.
+
+
+15 ATTRIBUTE_SERVER_DIGITAL_SIGNATURE
+
+ This attribute value includes digital signature of all Attribute
+ Payloads except this attribute, but including the attribute
+ ATTRIBUTE_USER_DIGITAL_SIGNATURE. This signature can be provided
+ by a third party server or an authority which has verified the
+ information provided by the user. How it verifies this information
+ is out of scope of this document, however it may base its
+ information to a previous registration information and current
+ online status of the user in a service. This attribute SHOULD be
+ last when provided, so that it is easier for the receiver to
+ compute the signature data to be verified. The format for this
+ attribute is identical to the ATTRIBUTE_USER_DIGITAL_SIGNATURE
+ attribute.
+.in 3
+
+
+.ti 0
+3 Security Considerations
+
+The use of these attributes dictates whether the attributes need to
+be secured or not. However, as the attributes are considered to provide
+accurate status information about specific user, it is suggested that
+the attributes would be secured. The attributes should be digitally
+signed whenever it is possible. Attributes can also be encrypted
+if it is provided by the protocol using the attributes. A third party,
+like a server in the network, could also verify the information and provide
+digital signature in case the information is accurate.
+
+Even though the attributes would be digitally signed by the sender of
+the attributes, the information contained in the attribute may still
+be incorrect. The third party server should not apply digital signature
+unless it can verify every attribute. The receiver of the attributes
+should also not trust that the information in fact is correct.
+
+However, it is possible that the context where these attributes are used
+the attributes are provided by a party that can provide the accurate
+information. For example a server in the network could reply to the
+attributes on behalf of the actual user for some of the attributes.
+
+
+.ti 0
+4 References
+
+[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+[RFC2425] Howes, T., et al, "A MIME Content-Type for Directory
+ Information", RFC 2425, September 1998.
+
+[RFC2426] Dawson, F., et al, "vCard MIME Directory Profile",
+ RFC 2426, September 1998.
+
+[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
+ Protocol Specification", Internet Draft, May 2002.
+
+[RFC2440] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
+ November 1998.
+
+[RFC2459] Housley, R., et al, "Internet X.509 Public Key
+ Infrastructure, Certificate and CRL Profile", RFC 2459,
+ January 1999.
+
+[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
+ Internet Draft.
+
+[PKCS7] Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
+ Version 1.5", RFC 2315, March 1998.
+
+
+
+
+.ti 0
+5 Author's Address
+
+Pekka Riikonen
+Snellmaninkatu 34 A 15
+70100 Kuopio
+Finland
+
+EMail: priikone@iki.fi
+
+
+.ti 0
+6 Full Copyright Statement
+
+Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it
+or assist in its implementation may be prepared, copied, published
+and distributed, in whole or in part, without restriction of any
+kind, provided that the above copyright notice and this paragraph are
+included on all such copies and derivative works. However, this
+document itself may not be modified in any way, such as by removing
+the copyright notice or references to the Internet Society or other
+Internet organizations, except as needed for the purpose of
+developing Internet standards in which case the procedures for
+copyrights defined in the Internet Standards process must be
+followed, or as required to translate it into languages other than
+English.
+
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an
+"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
--- /dev/null
+.pl 10.0i
+.po 0
+.ll 7.2i
+.lt 7.2i
+.nr LL 7.2i
+.nr LT 7.2i
+.ds LF Riikonen
+.ds RF FORMFEED[Page %]
+.ds CF
+.ds LH Internet-Draft
+.ds RH 2 February 2003
+.ds CH
+.na
+.hy 0
+.in 0
+.nf
+Network Working Group P. Riikonen
+Internet-Draft
+draft-riikonen-silc-ke-auth-08.txt 2 February 2004
+Expires: 2 August 2004
+
+.in 3
+
+.ce 2
+SILC Key Exchange and Authentication Protocols
+<draft-riikonen-silc-ke-auth-08.txt>
+
+.ti 0
+Status of this Memo
+
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC 2026. Internet-Drafts are
+working documents of the Internet Engineering Task Force (IETF), its
+areas, and its working groups. Note that other groups may also
+distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time. It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html
+
+The distribution of this memo is unlimited.
+
+
+.ti 0
+Abstract
+
+This memo describes two protocols used in the Secure Internet Live
+Conferencing (SILC) protocol, specified in the Secure Internet Live
+Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
+(SKE) protocol provides secure key exchange between two parties
+resulting into shared secret key material. The protocol is based
+on Diffie-Hellman key exchange algorithm and its functionality is
+derived from several key exchange protocols.
+
+The second protocol, SILC Connection Authentication protocol provides
+user level authentication used when creating connections in SILC
+network. The protocol is transparent to the authentication data
+which means that it can be used to authenticate the connection with, for
+example, passphrase (pre-shared secret) or public key (and certificate)
+based on digital signatures.
+
+
+
+.ti 0
+Table of Contents
+
+.nf
+1 Introduction .................................................. 2
+ 1.1 Requirements Terminology .................................. 3
+2 SILC Key Exchange Protocol .................................... 3
+ 2.1 Key Exchange Payloads ..................................... 4
+ 2.1.1 Key Exchange Start Payload .......................... 4
+ 2.1.2 Key Exchange Payload ................................ 8
+ 2.2 Key Exchange Procedure .................................... 11
+ 2.3 Processing the Key Material ............................... 12
+ 2.4 SILC Key Exchange Groups .................................. 14
+ 2.4.1 diffie-hellman-group1 ............................... 14
+ 2.4.2 diffie-hellman-group2 ............................... 15
+ 2.4.3 diffie-hellman-group3 ............................... 15
+ 2.5 Key Exchange Status Types ................................. 16
+3 SILC Connection Authentication Protocol ....................... 17
+ 3.1 Connection Auth Payload ................................... 18
+ 3.2 Connection Authentication Types ........................... 19
+ 3.2.1 Passphrase Authentication ........................... 19
+ 3.2.2 Public Key Authentication ........................... 20
+ 3.3 Connection Authentication Status Types .................... 21
+4 Security Considerations ....................................... 21
+5 References .................................................... 21
+6 Author's Address .............................................. 23
+7 Full Copyright Statement ...................................... 23
+
+
+.ti 0
+List of Figures
+
+.nf
+Figure 1: Key Exchange Start Payload
+Figure 2: Key Exchange Payload
+Figure 3: Connection Auth Payload
+
+
+.ti 0
+1 Introduction
+
+This memo describes two protocols used in the Secure Internet Live
+Conferencing (SILC) protocol specified in the Secure Internet Live
+Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange
+(SKE) protocol provides secure key exchange between two parties
+resulting into shared secret key material. The protocol is based on
+Diffie-Hellman key exchange algorithm and its functionality is derived
+from several key exchange protocols, such as SSH2 Key Exchange protocol,
+Station-To-Station (STS) protocol and the OAKLEY Key Determination
+protocol [OAKLEY].
+
+The second protocol, SILC Connection Authentication protocol provides
+user level authentication used when creating connections in SILC
+network. The protocol is transparent to the authentication data which
+means that it can be used to authenticate the connection with, for example,
+passphrase (pre-shared secret) or public key (and certificate) based
+on digital signatures.
+
+The basis of secure SILC session requires strong and secure key exchange
+protocol and authentication. The authentication protocol is secured and
+no authentication data is ever sent in the network without encrypting
+and authenticating it first. Thus, authentication protocol may be used
+only after the key exchange protocol has been successfully completed.
+
+This document constantly refers to other SILC protocol specifications
+that should be read to be able to fully understand the functionality
+and purpose of these protocols. The most important references are
+the Secure Internet Live Conferencing, Protocol Specification [SILC1]
+and the SILC Packet Protocol [SILC2].
+
+The protocol is intended to be used with the SILC protocol thus it
+does not define own framework that could be used. The framework is
+provided by the SILC protocol.
+
+
+.ti 0
+1.1 Requirements Terminology
+
+The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
+MAY, and OPTIONAL, when they appear in this document, are to be
+interpreted as described in [RFC2119].
+
+
+.ti 0
+2 SILC Key Exchange Protocol
+
+SILC Key Exchange Protocol (SKE) is used to exchange shared secret
+material used to secure the communication channel. The protocol use
+Diffie-Hellman key exchange algorithm and its functionality is derived
+from several key exchange protocols, such as SSH2 Key Exchange protocol,
+Station-To-Station (STS) protocol and the OAKLEY Key Determination
+protocol [OAKLEY]. The protocol does not claim any conformance
+to any of these protocols, they were only used as a reference when
+designing this protocol. The protocol can mutually authenticate the
+negotiating parties during the key exchange.
+
+The purpose of SILC Key Exchange protocol is to create session keys to
+be used in current SILC session. The keys are valid only for some period
+of time (usually an hour) or at most until the session ends. These keys
+are used to protect packets traveling between the two entities.
+Usually all traffic is secured with the key material derived from this
+protocol.
+
+The Diffie-Hellman implementation used in the SILC SHOULD be compliant
+to the PKCS #3.
+
+
+.ti 0
+2.1 Key Exchange Payloads
+
+During the key exchange procedure public data is sent between initiator
+and responder. This data is later used in the key exchange procedure.
+There are several payloads used in the key exchange. As for all SILC
+packets, SILC Packet Header, described in [SILC2], is at the beginning
+of all packets sent in during this protocol. All the fields in the
+following payloads are in MSB (most significant byte first) order.
+Following descriptions of these payloads.
+
+
+.ti 0
+2.1.1 Key Exchange Start Payload
+
+The key exchange between two entities MUST be started by sending the
+SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload.
+Initiator sends the Key Exchange Start Payload to the responder filled
+with all security properties it supports. The responder then checks
+whether it supports the security properties.
+
+It then sends a Key Exchange Start Payload to the initiator filled with
+security properties it selected from the original payload. The payload
+sent by responder MUST include only one chosen property per list. The
+character encoding for the security property values as defined in [SILC1]
+SHOULD be UTF-8 [RFC2279] in Key Exchange Start Payload.
+
+The Key Exchange Start Payload is used to tell connecting entities what
+security properties and algorithms should be used in the communication.
+The Key Exchange Start Payload is sent only once per session. Even if
+the PFS (Perfect Forward Secrecy) flag is set the Key Exchange Start
+Payload is not re-sent. When PFS is desired the Key Exchange Payloads
+are sent to negotiate new key material. The procedure is equivalent to
+the very first negotiation except that the Key Exchange Start Payload
+is not sent.
+
+As this payload is used only with the very first key exchange the payload
+is never encrypted, as there are no keys to encrypt it with.
+
+A cookie is also sent in this payload. A cookie is used to randomize the
+payload so that none of the key exchange parties can determine this
+payload before the key exchange procedure starts. The cookie MUST be
+returned to the original sender unmodified by the responder.
+
+Following diagram represents the Key Exchange Start Payload. The lists
+mentioned below are always comma (`,') separated and the list MUST NOT
+include white spaces (` ').
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| RESERVED | Flags | Payload Length |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
++ +
+| |
++ Cookie +
+| |
++ +
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Version String Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Version String ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Key Exchange Grp Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Key Exchange Groups ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| PKCS Alg Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ PKCS Algorithms ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Encryption Alg Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Encryption Algorithms ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Hash Alg Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Hash Algorithms ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| HMAC Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ HMACs ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Compression Alg Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Compression Algorithms ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 1: Key Exchange Start Payload
+
+
+.in 6
+o RESERVED (1 byte) - Reserved field. Sender fills this with
+ zero (0) value.
+
+o Flags (1 byte) - Indicates flags to be used in the key
+ exchange. Several flags can be set at once by ORing the
+ flags together. The following flags are reserved for this
+ field:
+
+ No flags 0x00
+
+ In this case the field is ignored.
+
+ IV Included 0x01
+
+ This flag is used to indicate that Initial Vector (IV)
+ in encryption will be included in the ciphertext
+ which the recipient must use in decryption. The IV
+ MUST be set after the last ciphertext block. With
+ this flag it is possible to use SILC protocol on
+ unreliable transport such as UDP/IP which may cause
+ packet reordering and packet losses. By default,
+ this flag is not set and thus IV is not included
+ in the ciphertext. Setting this flag increases the
+ ciphertext size by one ciphertext block. Responder
+ MAY override this flag for the initiator.
+
+ PFS 0x02
+
+ Perfect Forward Secrecy (PFS) to be used in the
+ key exchange protocol. If not set, re-keying
+ is performed using the old key. See the [SILC1]
+ for more information on this issue. When PFS is
+ used, re-keying and creating new keys for any
+ particular purpose MUST cause new key exchange with
+ new Diffie-Hellman exponent values. In this key
+ exchange only the Key Exchange Payload is sent and
+ the Key Exchange Start Payload MUST NOT be sent.
+ When doing PFS the Key Exchange Payloads are
+ encrypted with the old keys.
+
+ Mutual Authentication 0x04
+
+ Both of the parties will perform authentication
+ by providing signed data for the other party to
+ verify. By default, only responder will provide
+ the signature data. If this is set then the
+ initiator must also provide it. Initiator MAY
+ set this but also responder MAY set this even if
+ initiator did not set it.
+
+ Rest of the flags are reserved for the future and
+ MUST NOT be set.
+
+o Payload Length (2 bytes) - Length of the entire Key Exchange
+ Start payload, not including any other field.
+
+o Cookie (16 bytes) - Cookie that randomize this payload so
+ that each of the party cannot determine the payload before
+ hand. This field MUST be present.
+
+o Version String Length (2 bytes) - The length of the Version
+ String field, not including any other field.
+
+o Version String (variable length) - Indicates the version of
+ the sender of this payload. Initiator sets this when sending
+ the payload and responder sets this when it replies by sending
+ this payload. See [SILC1] for definition for the version
+ string format. This field MUST be present and include valid
+ version string.
+
+o Key Exchange Grp Length (2 bytes) - The length of the
+ key exchange group list, not including any other field.
+
+o Key Exchange Group (variable length) - The list of
+ key exchange groups. See the section 2.4 SILC Key Exchange
+ Groups for definitions of these groups. This field MUST
+ be present.
+
+o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms
+ list, not including any other field.
+
+o PKCS Algorithms (variable length) - The list of PKCS
+ algorithms. This field MUST be present.
+
+o Encryption Alg Length (2 bytes) - The length of the encryption
+ algorithms list, not including any other field.
+
+o Encryption Algorithms (variable length) - The list of
+ encryption algorithms. This field MUST be present.
+
+o Hash Alg Length (2 bytes) - The length of the Hash algorithm
+ list, not including any other field.
+
+o Hash Algorithms (variable length) - The list of Hash
+ algorithms. The hash algorithms are mainly used in the
+ SKE protocol. This field MUST be present.
+
+o HMAC Length (2 bytes) - The length of the HMAC list, not
+ including any other field.
+
+o HMACs (variable length) - The list of HMACs. The HMAC's
+ are used to compute the Message Authentication Code (MAC)
+ of the SILC packets. This field MUST be present.
+
+o Compression Alg Length (2 bytes) - The length of the
+ compression algorithms list, not including any other field.
+
+o Compression Algorithms (variable length) - The list of
+ compression algorithms. This field MAY be omitted.
+.in 3
+
+
+.ti 0
+2.1.2 Key Exchange Payload
+
+Key Exchange payload is used to deliver the public key (or certificate),
+the computed Diffie-Hellman public value and possibly signature data
+from one party to the other. When initiator is using this payload
+and the Mutual Authentication flag is not set then the initiator MUST
+NOT provide the signature data. If the flag is set then the initiator
+MUST provide the signature data so that the responder can verify it.
+
+The Mutual Authentication flag is usually used when a separate
+authentication protocol will not be executed for the initiator of the
+protocol. This is case for example when the SKE is performed between
+two SILC clients. In normal case, where client is connecting to a
+server, or server is connecting to a router the Mutual Authentication
+flag MAY be omitted. However, if the connection authentication protocol
+for the connecting entity is not based on digital signatures (it is
+based on pre-shared key) then the Mutual Authentication flag SHOULD be
+enabled. This way the connecting entity has to provide proof of
+possession of the private key for the public key it will provide in
+this protocol.
+
+When performing re-key with PFS selected this is the only payload that
+is sent in the SKE protocol. The Key Exchange Start Payload MUST NOT
+be sent at all. However, this payload does not have all the fields
+present. In the re-key with PFS the public key and a possible signature
+data SHOULD NOT be present. If they are present they MUST be ignored.
+The only field that is present is the Public Data that is used to create
+the new key material. In the re-key the Mutual Authentication flag, that
+may be set in the initial negotiation, MUST also be ignored.
+
+This payload is sent inside SILC_PACKET_KEY_EXCHANGE_1 and inside
+SILC_PACKET_KEY_EXCHANGE_2 packet types. The initiator uses the
+SILC_PACKET_KEY_EXCHANGE_1 and the responder the latter.
+
+The following diagram represent the Key Exchange Payload.
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Public Key Length | Public Key Type |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Public Key of the party (or certificate) ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Public Data Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Public Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Signature Length | |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+| |
+~ Signature Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 2: Key Exchange Payload
+
+
+.in 6
+o Public Key Length (2 bytes) - The length of the Public Key
+ (or certificate) field, not including any other field.
+
+o Public Key Type (2 bytes) - The public key (or certificate)
+ type. This field indicates the type of the public key in
+ the packet. Following types are defined:
+
+ 1 SILC style public key (mandatory)
+ 2 SSH2 style public key (optional)
+ 3 X.509 Version 3 certificate (optional)
+ 4 OpenPGP certificate (optional)
+ 5 SPKI certificate (optional)
+
+ The only required type to support is type number 1. See
+ [SILC1] for the SILC public key specification. See
+ SSH2 public key specification in [SSH-TRANS]. See X.509v3
+ certificate specification in [PKIX-Part1]. See OpenPGP
+ certificate specification in [PGP]. See SPKI certificate
+ specification in [SPKI]. If this field includes zero (0)
+ or unsupported type number the protocol MUST be aborted
+ sending SILC_PACKET_FAILURE message and the connection SHOULD
+ be closed immediately.
+
+o Public Key (or certificate) (variable length) - The
+ public key or certificate of the party. This public key
+ is used to verify the digital signature. The public key
+ or certificate in this field is encoded in the manner as
+ defined in their respective definitions; see previous field.
+
+o Public Data Length (2 bytes) - The length of the Public Data
+ field, not including any other field.
+
+o Public Data (variable length) - The public data to be
+ sent to the receiver (computed Diffie-Hellman public values).
+ See section 2.2 Key Exchange Procedure for detailed description
+ how this field is computed. This field is MP integer and is
+ encoded as defined in [SILC1].
+
+o Signature Length (2 bytes) - The length of the signature,
+ not including any other field.
+
+o Signature Data (variable length) - The signature signed
+ by the sender. The receiver of this signature MUST
+ verify it. The verification is done using the sender's
+ public key. See section 2.2 Key Exchange Procedure for
+ detailed description how to produce the signature. If
+ the Mutual Authentication flag is not set then initiator
+ MUST NOT provide this field and the Signature Length field
+ MUST be set to zero (0) value. If the flag is set then
+ also the initiator MUST provide this field. The responder
+ always MUST provide this field. The encoding for signature
+ is defined in [SILC1].
+.in 3
+
+
+
+.ti 0
+2.2 Key Exchange Procedure
+
+The key exchange begins by sending SILC_PACKET_KEY_EXCHANGE packet with
+Key Exchange Start Payload to select the security properties to be used
+in the key exchange and later in the communication.
+
+After Key Exchange Start Payload has been processed by both of the
+parties the protocol proceeds as follows:
+
+
+Setup: p is a large and public safe prime. This is one of the
+ Diffie Hellman groups. q is order of subgroup (largest
+ prime factor of p). g is a generator and is defined
+ along with the Diffie Hellman group.
+
+ 1. Initiator generates a random number x, where 1 < x < q,
+ and computes e = g ^ x mod p. The result e is then
+ encoded into Key Exchange Payload, with the public key
+ (or certificate) and sent to the responder.
+
+ If the Mutual Authentication flag is set then initiator
+ MUST also produce signature data SIGN_i which the responder
+ will verify. The initiator MUST compute a hash value
+ HASH_i = hash(Initiator's Key Exchange Start Payload |
+ public key (or certificate) | e). The '|' stands for
+ concatenation. It then signs the HASH_i value with its
+ private key resulting a signature SIGN_i.
+
+ 2. Responder generates a random number y, where 1 < y < q,
+ and computes f = g ^ y mod p. It then computes the
+ shared secret KEY = e ^ y mod p, and, a hash value
+ HASH = hash(Initiator's Key Exchange Start Payload |
+ public key (or certificate) | Initiator's public key
+ (or certificate) | e | f | KEY). It then signs
+ the HASH value with its private key resulting a signature
+ SIGN.
+
+ It then encodes its public key (or certificate), f and
+ SIGN into Key Exchange Payload and sends it to the
+ initiator.
+
+ If the Mutual Authentication flag is set then the responder
+ SHOULD verify that the public key provided in the payload
+ is authentic, or if certificates are used it verifies the
+ certificate. The responder MAY accept the public key without
+ verifying it, however, doing so may result to insecure key
+ exchange (accepting the public key without verifying may be
+ desirable for practical reasons on many environments. For
+ long term use this is never desirable, in which case
+ certificates would be the preferred method to use). It then
+ computes the HASH_i value the same way initiator did in the
+ phase 1. It then verifies the signature SIGN_i from the
+ payload with the hash value HASH_i using the received public
+ key.
+
+ 3. Initiator verifies that the public key provided in
+ the payload is authentic, or if certificates are used
+ it verifies the certificate. The initiator MAY accept
+ the public key without verifying it, however, doing
+ so may result to insecure key exchange (accepting the
+ public key without verifying may be desirable for
+ practical reasons on many environments. For long term
+ use this is never desirable, in which case certificates
+ would be the preferred method to use).
+
+ Initiator then computes the shared secret KEY =
+ f ^ x mod p, and, a hash value HASH in the same way as
+ responder did in phase 2. It then verifies the
+ signature SIGN from the payload with the hash value
+ HASH using the received public key.
+
+
+If any of these phases is to fail the SILC_PACKET_FAILURE MUST be sent
+to indicate that the key exchange protocol has failed, and the connection
+SHOULD be closed immediately. Any other packets MUST NOT be sent or
+accepted during the key exchange except the SILC_PACKET_KEY_EXCHANGE_*,
+SILC_PACKET_FAILURE and SILC_PACKET_SUCCESS packets.
+
+The result of this protocol is a shared secret key material KEY and
+a hash value HASH. The key material itself is not fit to be used as
+a key, it needs to be processed further to derive the actual keys to be
+used. The key material is also used to produce other security parameters
+later used in the communication. See section 2.3 Processing the Key
+Material for detailed description how to process the key material.
+
+If the Mutual Authentication flag was set the protocol produces also
+a hash value HASH_i. This value, however, must be discarded.
+
+After the keys are processed the protocol is ended by sending the
+SILC_PACKET_SUCCESS packet. Both entities send this packet to
+each other. After this both parties MUST start using the new keys.
+
+
+.ti 0
+2.3 Processing the Key Material
+
+Key Exchange protocol produces secret shared key material KEY. This
+key material is used to derive the actual keys used in the encryption
+of the communication channel. The key material is also used to derive
+other security parameters used in the communication. Key Exchange
+protocol produces a hash value HASH as well.
+
+The keys MUST be derived from the key material as follows:
+
+.in 6
+Sending Initial Vector (IV) = hash(0x0 | KEY | HASH)
+Receiving Initial Vector (IV) = hash(0x1 | KEY | HASH)
+Sending Encryption Key = hash(0x2 | KEY | HASH)
+Receiving Encryption Key = hash(0x3 | KEY | HASH)
+Sending HMAC Key = hash(0x4 | KEY | HASH)
+Receiving HMAC Key = hash(0x5 | KEY | HASH)
+.in 3
+
+
+The Initial Vector (IV) is used in the encryption when doing for
+example CBC mode. As many bytes as needed are taken from the start of
+the hash output for IV. Sending IV is for sending key and receiving IV
+is for receiving key. For receiving party, the receiving IV is actually
+sender's sending IV, and, the sending IV is actually sender's receiving
+IV. Initiator uses IV's as they are (sending IV for sending and
+receiving IV for receiving).
+
+The Encryption Keys are derived as well from the hash(). If the hash()
+output is too short for the encryption algorithm more key material MUST
+be produced in the following manner:
+
+.in 6
+K1 = hash(0x2 | KEY | HASH)
+K2 = hash(KEY | HASH | K1)
+K3 = hash(KEY | HASH | K1 | K2) ...
+
+Sending Encryption Key = K1 | K2 | K3 ...
+
+
+K1 = hash(0x3 | KEY | HASH)
+K2 = hash(KEY | HASH | K1)
+K3 = hash(KEY | HASH | K1 | K2) ...
+
+Receiving Encryption Key = K1 | K2 | K3 ...
+.in 3
+
+
+The key is distributed by hashing the previous hash with the original
+key material. The final key is a concatenation of the hash values.
+For Receiving Encryption Key the procedure is equivalent. Sending key
+is used only for encrypting data to be sent. The receiving key is used
+only to decrypt received data. For receiving party, the receive key is
+actually sender's sending key, and, the sending key is actually sender's
+receiving key. Initiator uses generated keys as they are (sending key
+for sending and receiving key for receiving).
+
+The HMAC keys are used to create MAC values to packets in the
+communication channel. As many bytes as needed are taken from the start
+of the hash output to generate the MAC keys.
+
+These procedures are performed by all parties of the key exchange
+protocol. This MUST be done before the protocol has been ended by
+sending the SILC_PACKET_SUCCESS packet, to assure that parties can
+successfully process the key material.
+
+This same key processing procedure MAY be used in the SILC in some
+other circumstances as well. Any changes to this procedure is defined
+separately when this procedure is needed. See the [SILC1] and the
+[SILC2] for these circumstances.
+
+
+.ti 0
+2.4 SILC Key Exchange Groups
+
+The Following groups may be used in the SILC Key Exchange protocol.
+The first group diffie-hellman-group1 is REQUIRED, other groups MAY be
+negotiated to be used in the connection with Key Exchange Start Payload
+and SILC_PACKET_KEY_EXCHANGE packet. However, the first group MUST be
+proposed in the Key Exchange Start Payload regardless of any other
+requested group (however, it does not have to be the first in the list).
+
+
+.ti 0
+2.4.1 diffie-hellman-group1
+
+The length of this group is 1024 bits. This is REQUIRED group.
+The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
+
+Its hexadecimal value is
+
+.in 6
+FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
+FFFFFFFF FFFFFFFF
+.in 3
+
+
+The generator used with this prime is g = 2. The group order q is
+(p - 1) / 2.
+
+This group was taken from RFC 2412.
+
+
+.ti 0
+2.4.2 diffie-hellman-group2
+
+The length of this group is 1536 bits. This is OPTIONAL group.
+The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
+
+Its hexadecimal value is
+
+.in 6
+FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
+.in 3
+
+The generator used with this prime is g = 2. The group order q is
+(p - 1) / 2.
+
+This group was taken from RFC 3526.
+
+
+.ti 0
+2.4.3 diffie-hellman-group3
+
+The length of this group is 2048 bits. This is OPTIONAL group.
+This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }.
+
+Its hexadecimal value is
+
+.in 6
+FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
+E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
+DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
+15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
+.in 3
+
+The generator used with this prime is g = 2. The group order q is
+(p - 1) / 2.
+
+This group was taken from RFC 3526.
+
+Additional larger groups are defined in RFC 3526 and may be used in SKE
+by defining name for them using the above name format.
+
+
+.ti 0
+2.5 Key Exchange Status Types
+
+This section defines all key exchange protocol status types that may
+be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
+to indicate the status of the protocol. Implementations may map the
+status types to human readable error message. All types except the
+SILC_SKE_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
+The length of status is 32 bits (4 bytes). The following status types
+are defined:
+
+.in 6
+0 SILC_SKE_STATUS_OK
+
+ Protocol were executed successfully.
+
+
+1 SILC_SKE_STATUS_ERROR
+
+ Unknown error occurred. No specific error type is defined.
+
+
+2 SILC_SKE_STATUS_BAD_PAYLOAD
+
+ Provided KE payload were malformed or included bad fields.
+
+
+3 SILC_SKE_STATUS_UNSUPPORTED_GROUP
+
+ None of the provided groups were supported.
+
+
+4 SILC_SKE_STATUS_UNSUPPORTED_CIPHER
+
+ None of the provided ciphers were supported.
+
+
+5 SILC_SKE_STATUS_UNSUPPORTED_PKCS
+
+ None of the provided public key algorithms were supported.
+
+
+6 SILC_SKE_STATUS_UNSUPPORTED_HASH_FUNCTION
+
+ None of the provided hash functions were supported.
+
+
+7 SILC_SKE_STATUS_UNSUPPORTED_HMAC
+
+ None of the provided HMACs were supported.
+
+
+8 SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY
+
+ Provided public key type is not supported.
+
+
+9 SILC_SKE_STATUS_INCORRECT_SIGNATURE
+
+ Provided signature was incorrect.
+
+
+10 SILC_SKE_STATUS_BAD_VERSION
+
+ Provided version string was not acceptable.
+
+
+11 SILC_SKE_STATUS_INVALID_COOKIE
+
+ The cookie in the Key Exchange Start Payload was malformed,
+ because responder modified the cookie.
+.in 3
+
+
+.ti 0
+3 SILC Connection Authentication Protocol
+
+Purpose of Connection Authentication protocol is to authenticate the
+connecting party with server. Usually connecting party is client but
+server may connect to router server as well. Its other purpose is to
+provide information for the server about which type of entity the
+connection is. The type defines whether the connection is client,
+server or router connection. Server use this information to create the
+ID for the connection.
+
+Server MUST verify the authentication data received and if it is to fail
+the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
+If authentication is successful the protocol is ended by server by sending
+SILC_PACKET_SUCCESS packet.
+
+The protocol is executed after the SILC Key Exchange protocol. It MUST
+NOT be executed in any other time. As it is performed after key exchange
+protocol all traffic in the connection authentication protocol is
+encrypted with the exchanged keys.
+
+The protocol MUST be started by the connecting party by sending the
+SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload,
+described in the next section. This payload MUST include the
+authentication data. The authentication data is set according
+authentication method that MUST be known by both parties. If connecting
+party does not know what is the mandatory authentication method it MAY
+request it from the server by sending SILC_PACKET_CONNECTION_AUTH_REQUEST
+packet. This packet is not part of this protocol and is described in
+section Connection Auth Request Payload in [SILC2]. However, if
+connecting party already knows the mandatory authentication method
+sending the request is not necessary.
+
+See [SILC1] and section Connection Auth Request Payload in [SILC2] also
+for the list of different authentication methods. Authentication method
+MAY also be NONE, in which case the server does not require
+authentication. However, in this case the protocol still MUST be
+executed; the authentication data is empty indicating no authentication
+is required.
+
+If authentication method is passphrase the authentication data is
+plaintext passphrase. As the payload is encrypted it is safe to have
+plaintext passphrase. It is also provided as plaintext passphrase
+because the receiver may need to pass the entire passphrase into a
+passphrase verifier, and a message digest of the passphrase would
+prevent this. See the section 3.2.1 Passphrase Authentication for
+more information.
+
+If authentication method is public key authentication the authentication
+data is a digital signature of the hash value of hash HASH and Key
+Exchange Start Payload, established by the SILC Key Exchange protocol.
+This signature MUST then be verified by the server. See the section
+3.2.2 Public Key Authentication for more information.
+
+See the section 4 SILC Procedures in [SILC1] for more information about
+client creating connection to server, and server creating connection
+to router, and how to register the session in the SILC Network after
+successful Connection Authentication protocol.
+
+
+.ti 0
+3.1 Connection Auth Payload
+
+Client sends this payload to authenticate itself to the server. Server
+connecting to another server also sends this payload. Server receiving
+this payload MUST verify all the data in it and if something is to fail
+the authentication MUST be failed by sending SILC_PACKET_FAILURE packet.
+
+The payload may only be sent with SILC_PACKET_CONNECTION_AUTH packet.
+It MUST NOT be sent in any other packet type. The following diagram
+represent the Connection Auth Payload.
+
+
+
+
+
+
+
+.in 5
+.nf
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Payload Length | Connection Type |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| |
+~ Authentication Data ~
+| |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+.in 3
+
+.ce
+Figure 3: Connection Auth Payload
+
+
+.in 6
+o Payload Length (2 bytes) - Length of the entire Connection
+ Auth Payload.
+
+o Connection Type (2 bytes) - Indicates the type of the
+ connection. See section Connection Auth Request Payload
+ in [SILC2] for the list of connection types. This field MUST
+ include valid connection type or the packet MUST be discarded
+ and authentication MUST be failed.
+
+o Authentication Data (variable length) - The actual
+ authentication data. Contents of this depends on the
+ authentication method known by both parties. If no
+ authentication is required this field does not exist.
+.in 3
+
+
+.ti 0
+3.2 Connection Authentication Types
+
+SILC supports two authentication types to be used in the connection
+authentication protocol; passphrase authentication or public key
+authentication based on digital signatures. The following sections
+defines the authentication methods. See [SILC2] for defined numerical
+authentication method types.
+
+
+.ti 0
+3.2.1 Passphrase Authentication
+
+Passphrase authentication or pre-shared key based authentication is
+simply an authentication where the party that wants to authenticate
+itself to the other end sends the passphrase that is required by
+the other end, for example server. The plaintext passphrase is put
+to the payload, that is then encrypted. The plaintext passphrase
+MUST be in UTF-8 [RFC2279] encoding. If the passphrase is in the
+sender's system in some other encoding it MUST be UTF-8 encoded
+before transmitted. The receiver MAY change the encoding of the
+passphrase to its system's default character encoding before verifying
+the passphrase.
+
+If the passphrase matches with the one in the server's end the
+authentication is successful. Otherwise SILC_PACKET_FAILURE MUST be
+sent to the sender and the protocol execution fails.
+
+This is REQUIRED authentication method to be supported by all SILC
+implementations.
+
+When password authentication is used it is RECOMMENDED that maximum
+amount of padding is applied to the SILC packet. This way it is not
+possible to approximate the length of the password from the encrypted
+packet.
+
+
+
+.ti 0
+3.2.2 Public Key Authentication
+
+Public key authentication may be used if passphrase based authentication
+is not desired. The public key authentication works by sending a
+digital signature as authentication data to the other end, say, server.
+The server MUST then verify the signature by the public key of the sender,
+which the server has received earlier in SKE protocol.
+
+The signature is computed using the private key of the sender by signing
+the HASH value provided by the SKE protocol previously, and the Key
+Exchange Start Payload from SKE protocol that was sent to the server.
+These are concatenated and hash function is used to compute a hash value
+which is then signed.
+
+ auth_hash = hash(HASH | Key Exchange Start Payload);
+ signature = sign(auth_hash);
+
+The hash() function used to compute the value is the hash function
+negotiated in the SKE protocol. The server MUST verify the data, thus
+it must keep the HASH and the Key Exchange Start Payload saved during
+SKE and authentication protocols. These values can be discarded after
+Connection Authentication protocol is completed.
+
+If the verified signature matches the sent signature, the authentication
+were successful and SILC_PACKET_SUCCESS is sent. If it failed the
+protocol execution is stopped and SILC_PACKET_FAILURE is sent.
+
+This is REQUIRED authentication method to be supported by all SILC
+implementations.
+
+
+
+.ti 0
+3.3 Connection Authentication Status Types
+
+This section defines all connection authentication status types that
+may be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets
+to indicate the status of the protocol. Implementations may map the
+status types to human readable error message. All types except the
+SILC_AUTH_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet.
+The length of status is 32 bits (4 bytes). The following status types
+are defined:
+
+0 SILC_AUTH_OK
+
+ Protocol was executed successfully.
+
+
+1 SILC_AUTH_FAILED
+
+ Authentication failed.
+
+
+.ti 0
+4 Security Considerations
+
+Security is central to the design of this protocol, and these security
+considerations permeate the specification. Common security considerations
+such as keeping private keys truly private and using adequate lengths for
+symmetric and asymmetric keys must be followed in order to maintain the
+security of this protocol.
+
+
+.ti 0
+5 References
+
+[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
+ Protocol Specification", Internet Draft, June 2003.
+
+[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
+ June 2003.
+
+[SILC4] Riikonen, P., "SILC Commands", Internet Draft, June 2003.
+
+[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol",
+ RFC 1459, May 1993.
+
+[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
+ April 2000.
+
+[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
+ 2811, April 2000.
+
+[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+ 2812, April 2000.
+
+[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+ 2813, April 2000.
+
+[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
+ Internet Draft.
+
+[PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
+ November 1998.
+
+[SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693,
+ September 1999.
+
+[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key
+ Infrastructure, Certificate and CRL Profile", RFC 2459,
+ January 1999.
+
+[Schneier] Schneier, B., "Applied Cryptography Second Edition",
+ John Wiley & Sons, New York, NY, 1996.
+
+[Menezes] Menezes, A., et al, "Handbook of Applied Cryptography",
+ CRC Press 1997.
+
+[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
+ RFC 2412, November 1998.
+
+[ISAKMP] Maughan D., et al, "Internet Security Association and
+ Key Management Protocol (ISAKMP)", RFC 2408, November
+ 1998.
+
+[IKE] Harkins D., and Carrel D., "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message
+ Authentication", RFC 2104, February 1997.
+
+[PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography
+ Specifications, Version 2.0", RFC 2437, October 1998.
+
+[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+.ti 0
+6 Author's Address
+
+.nf
+Pekka Riikonen
+Snellmaninkatu 34 A 15
+70100 Kuopio
+Finland
+
+EMail: priikone@iki.fi
+
+
+.ti 0
+7 Full Copyright Statement
+
+Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it
+or assist in its implementation may be prepared, copied, published
+and distributed, in whole or in part, without restriction of any
+kind, provided that the above copyright notice and this paragraph are
+included on all such copies and derivative works. However, this
+document itself may not be modified in any way, such as by removing
+the copyright notice or references to the Internet Society or other
+Internet organizations, except as needed for the purpose of
+developing Internet standards in which case the procedures for
+copyrights defined in the Internet Standards process must be
+followed, or as required to translate it into languages other than
+English.
+
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an
+"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
projects / silc.git / commitdiff