text:
|Publication number
|Publication type
|Application number
|Publication date
|Dec 27, 2011
|Filing date
|Aug 18, 2010
|Priority date
|May 7, 2004
|Fee status
|Also published as
|Publication number
|Ibrahim S. Abdullah, Daniel A. Menasce
|Original Assignee
|George Mason Intellectual Properties, Inc.
|Export Citation
|BiBTeX, EndNote, RefMan
|Patent Citations (11), Non-Patent Citations (1), Referenced by (2), Classifications (10), Legal Events (4)
|External Links: USPTO, USPTO Assignment, Espacenet
The present application is a continuation of application Ser. No. 11/122,099, filed on May 5, 2005, now abandoned, entitled "Meta-Protocol," which claims the benefit of provisional patent application No. 60/568,664 to Abdullah et al., filed on May 7, 2004, entitled "Meta-Protocol," each of which are hereby incorporated by reference in their entireties.
A portion of the present disclosure is contained in a computer program listing appendix filed on two Compact Discs in ASCII text format, which are hereby incorporated by reference in their entireties. The Compact Discs are entitled COPY 1 REPLACEMENT created on Aug. 1, 2005, of approximately 614.4 kilobytes, and COPY 2 REPLACEMENT created on Aug. 1, 2005, of approximately 614.4 kilobytes.
Communication protocols play a central role in today's information systems. The wide spread use of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol and the rapid development of communication technologies laid the ground for an explosion in the use of information technologies at homes, businesses and government agencies. Several protocols, including TCP/IP, HTTP, SMTP, S/MIME, SSL and IPsec, have contributed to this growth. Moreover, new technologies are emerging frequently to support the growing need for efficient, easy and secure communication.
Developed in the mid-1970's by the Defense Advanced Research Project Agency (DARPA) of the U.S. Department of Defense, the TCP/IP protocol has several features that led to its widespread adoption: open standard, freely available for developers and independent of any specific physical network hardware. The first two features led to TCP/IP's wide acceptance, and the latter feature made it easy for different kinds of networks to interoperate. With the adoption of TCP/IP, the Internet has seen an exponential growth.
The TCP/IP stack consists of four layers: the network access layer, the Internet Protocol layer (IP), the transport layer and the application layer. The network access layer is located at the bottom of the architecture. It consists of many protocols that provide access to physical networks. Compared to the Open System Interconnection (OSI) seven-layer reference model, the network access layer comprises just two layers: a data link layer and a physical layer.
The IP layer is responsible for defining the Internet addressing scheme, composing datagrams and routing them to their destination. IP is a connectionless protocol. Yet, it does not provide handshake or reliability mechanisms. Thus, IP depends on other layers to provide such services.
The transport layer consists of two protocols: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). TCP provides connection management reliability, flow control and sequencing, whereas UDP serves as a simple interface between applications and IP. One other distinction is that UDP does not provide reliability, flow-control or error-recovery.
The application layer is at the top of the stack. It includes protocols that use the transport layer to deliver data to the network. Many protocols run at the application layer to provide services such as TELNET, HTTP, SMT and FTP.
Problematically, TCP/IP does not have security measures to support the kind of applications that have appeared over time. Therefore, several security solutions have been proposed to address the different kinds of vulnerabilities of TCP/IP, as well as the additional security needs of applications. Such security solutions are typically associated with a single layer of the TCP/IP stack or with specific applications.
Security protocols also play a central role in today's information systems. Most tend to have more commonalities than differences. For example, security protocols share significant functionality and utilize a common set of encryption, hash and compression algorithms. They usually differ in the handshaking mechanism (which includes authentication), target data, header processing, key sizes, replay mechanisms and the order in which the various algorithms are applied.
One common security protocol is the secure socket layer (SSL). The motivation for the SSL protocol development was to provide protection to electronic commerce and Web transactions. In 1994, Netscape communications introduced SSL version 1.0 in its Mosaic Web browser. Netscape made SSL an open standard and encouraged the Web community to participate in its development. Later, in May 1996, the development of SSL became the responsibility of the Internet Engineering Task Force (IETF), which was later renamed as Transport Layer Security (TLS).
SSL has two important features. First, it provides strong protection based on public key cryptography. That is, SSL uses public key cryptography to encrypt the pre-master key that is used to generate the set of shared keys. Second, SSL is efficient because it uses symmetric key cryptography to protect the traffic between the communicating parties. Therefore, SSL consumes relatively little CPU time to protect the exchange of data between parties. These two features made SSL suitable for most e-commerce applications on the Internet.
Today, SSL is the most widely used Web security protocol. Almost every browser and Web server supports SSL. SSL adds security by inserting itself between the Hypertext Transfer Protocol (HTTP) application and the TCP layer. Therefore, SSL requires minor changes in the applications. In addition, SSL is not limited to HTTP traffic (through its original specification) but it can support other Internet applications, such as Net News, FTP and Telnet.
However, a disadvantage of SSL is that it only supports TCP. In the typical handshake process, an SSL initiator sends to the second party a list of the security capabilities that it can support. For instance, TLS v.1 currently supports 32 different capabilities. In this format, the responder selects his preferred capability and sends it back to the initiator along with a certificate that contains a public key. The certificate is then used by the initiator to authenticate the responder. Next, the initiator creates a pre-master secret key, encrypts it with the responder's public key and sends the encrypted message to the responder. Afterwards, both parties use the pre-master secret key to create six shared keys for the protection of the subsequent communication. Each party indicates its readiness to switch to protected mode by sending a single byte message called ChangeCipherSpec. The first protected message sent by each party is the Finish message. This message contains a hash value of all the previously exchanged messages between the parties to protect the session against replay attacks.
Another security protocol is IP Security Protocol (IPsec). IPsec is a security standard developed by the Internet Engineering Task Force (IETF). This protocol is designed to establish a solid security ground for the Internet. IPsec is part of the Next Generation Internet or Internet II (IPv6). Most of the VPN products nowadays adopt the IPsec protocol (e.g., Cisco VPN, eTrust, VPN-1 and Symantec). A complex technology, IPsec's main goal is to secure the flow of information between two endpoints. Its security services are designed for the IP layer. Furthermore, it provides several types of protections such as source IP authentication, integrity and confidentiality. The protection scope varies. For example, it may include the IP header, or it may be limited to the payload only. These choices are determined by a set of security policies that are managed by a system administrator. However, an IPsec-secured connection is very cumbersome to setup and configure because it comes in many varieties. Therefore, an IPsec user has to have a clear set of requirements and security policies before implementation. Otherwise, it would be hard to validate whether there is a secure connection or not.
IPsec consists of two major protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP). Each protocol can be configured to run in Transport Mode or in Tunnel Mode. The Transport Mode provides security for transport layer (TCP, UDP or ICMP). Typically, this mode is used for end-to-end communication. Therefore, ESP in transport mode encrypts, and optionally authenticates, the IP payload but not the IP header. Similarly, AH in transport mode authenticates the IP payload and selected portions of the IP header without encryption.
Tunnel mode provides security for the entire packet. A new header with the gateway destination address is added to the packet. ESP in tunnel mode adds a new header to the packet, encrypts it and optionally authenticates the new packet including the new header. In contrast, AH in tunnel mode authenticates the entire packet and parts of the new header without encryption.
IPsec manages keys and establishes sessions through a protocol called the Internet Key Exchange (IKE). IKE is a collection of protocols: Internet Security Association and Key Management Protocol (ISAKMP), Oakley Key Determination Protocol (Oakley) and Secure Key Exchange Mechanism (SKEME). Therefore, IPsec supports a wide variety of key types and sizes.
IPsec provides general IP security services regardless of the specific needs of the applications. However, IPsec is transparent to applications. Therefore, similar to SSL, IPsec cannot address specific needs of an application, such as authenticating a user or protecting parts of a document (e.g., part of a contract or a payment document).
The current approach to implementing security protocols is centered on designing a protocol as a single package comprised of two layers: control and a library of algorithms. This approach is based on the assumption that every protocol is complete and does not need to be integrated with other security protocols. Yet, this assumption may not be valid in situations where several security protocols need to coexist. In such cases, redundancy and conflicts may occur. For example, running Secure/Multipurpose Internet Mail Extensions (S/MIME) over IPsec introduces redundancy. Both provide similar encryption: S/MIME does it at the document level and IPsec at the packet level. This situation is common in business-to-business (B2B) applications when an application uses S/MIME as a document-level protection while using IPsec to protect the communication with a remote branch office.
Moreover, the current approach of designing autonomous and complete protocols has several disadvantages. First, it may result in conflicts when various protocols need to coexist. For example, if compression is done at an upper layer (e.g., S/MIME), repeating it at a lower layer may increase the size of the message. Second, there is not enough flexibility in most security protocols (e.g., S/MIME, SSL, IPsec) and, consequently, their users have to adopt them without being able to make changes. For instance, a user may want to change the header by adding or removing some fields for quality of service (QoS) purposes. Third, these protocols offer coarse grained security services and the developer of an application does not have the ability to fine tune operations within the use of these protocols. For example, S/MIME services are applied to an entire document, preventing a user from applying it on selective parts of the document. Fourth, the use of coarse grain services may lead to unnecessary performance degradation. For instance, SSL has to calculate a block of four shared keys and a couple of IVs even if the user does not want to use some of the modes such as the read mode, the write mode, the encryption service or the integrity service.
Furthermore, the traditional approach to implementing protocols is monolithic. Adhering to monolithic protocols limits users to situations for which the protocols were implemented. Internet applications and their security requirements are evolving very rapidly. Video, audio, wireless applications, collaborative applications and many other emerging technologies raise new challenges and require flexible approaches to deal with them. This monolithic implementation approach is not well-suited to cope with rapid changes in communication and security requirements.
Overall, the current process of implementing a protocol is tedious and error-prone. Protocol specifications in natural language are often ambiguous and may lead to defective implementations. Moreover, implementations have to be thoroughly tested. This testing is a time-consuming effort due to the timing dependencies of events processed by protocols.
Consequently, it would be desirable to have a model for sharing protocol specifications to produce protocol implementations automatically. It would also be desirable to free protocols from being dependent on the monolithic implementation of a limited number of capabilities. Additionally, it would be desirable to have a flexible infrastructure for businesses to exchange protocol specifications and automatically generate code that supports the evolving B2B environment. Furthermore, it would be desirable to have a framework that could be applied to overlay networks and Web Services.
The accompanying drawings, which are incorporated in and form a part of the specification, illustrate an embodiment of the present invention and, together with the description, serve to explain the principles of the invention.
The present invention is a multi-layer protocol management system and method, embeddable in a tangible computer-readable medium, that allow for on-the-fly machine-readable protocol discovery and negotiation, distribution of protocol specifications and components, automatic machine-readable protocol implementation and execution of machine-readable protocol specifications. Automatic protocol implementation may be accomplished using eXtensible Markup Language (XML)-related technologies and Component-based Software Engineering (CBSE).
The present invention is also a tangible computer-readable medium encoded with instructions capable of generating, as well as capable of being designed to generate, protocol specifications. A program of instructions, called XML-based protocol specification language (XPSL), may be used for generating a specification of a communication protocol (such as high-level specifications of a protocol) in a machine readable form. A language that protocol designers can use to describe the design of a protocol, XPSL may be expressible in Finite State Machines (FSM) by using CBSE principles. Taking an XPSL document as input, an eXtensible Stylesheet Language for Transformations (XSLT) may be used as a code generator to transform specification description into actual code (e.g., an implementation for the communication protocol). XSLT stylesheets can be designed to produce code in different programming languages (e.g., C++ or Java). CBSE may be used to build a set of operations needed by a protocol.
XML is a set of rules for creating new markup languages. Originally, XML may be construed as a subset of the Standard Generalized Markup Language (SGML), which specifies syntactic and semantic rules for creating new markup languages, such as the Hypertext Markup Language (HTML). SGML may also be deemed as an International Standards Organization (ISO) standard.
XML 1.0 was announced as a World Wide Web Consortium (W3C) recommendation on Feb. 10, 1998. A goal of XML is to provide a language for expressing metadata. Metadata refers to information about data. Metadata is often important in searches, filtering, and document management. XML is intended to be human-readable as well as machine-readable. A document that conforms to the XML specification can be called "well-formed." XML editors and parsers typically provide the capability to check if an XML document is well-formed or not.
An XML specification may include two parts. One may specify rules for constructing XML documents, while the other may specify rules for Document Type Definitions (DTD). A DTD may specify how tags are used in a class of XML documents; the order they should appear; the nesting structure of a document; and the attributes of XML elements for that class of documents. A DTD may also describe constraints on XML elements that are used to validate the correctness of an XML document. But, a DTD may also have disadvantages. First, it is not written in XML; it has a special syntax. Second, a DTD has a limited expressive syntax to address needs such as different kinds of data types and cardinality constraints. To overcome the limitations of DTDs, XML schemas may be introduced.
The W3C released the Schema standard in May 2001. An XML schema may specify valid elements and attributes in an XML document. It may also specify XML elements order, attributes constraints, accepted data types and accepted value ranges. Schema can help applications determine whether an XML document complies with a system's requirements.
XPSL may be based on XML, which is an open standard used to express Metadata in machine readable form. Because XML is known to be widely used for easy sharing and exchanging of information about transmitted data, XPSL can benefit from the wide spread tools and technologies of XML. In essence, the development of XPSL addresses the need of sharing and exchanging protocol specifications among users in a machine readable form.
The eXtensible Stylesheet Language (XSL) is a language that allows XML document users to specify how an XML document may be transformed into a resulting output document (e.g., HTML, SVG, PS, PDF, plain text, or any other format). The XSLT 1.0 recommendation was released on Nov. 16, 1999. XSLT tends to be attractive to developers because it is not a programming language. An XSLT stylesheet may be written down as a set of rules, which may be applied to the XML document during the transformation to produce the required output.
I. The Meta-Protocol Framework
A protocol may be defined as a set of rules shared by two or more communicating parties to facilitate data communication. These rules can have two parts: syntax and semantic. Syntax refers to the format of the messages that are to be exchanged; semantic refers to the sequence of operations to be performed by each party when events (e.g., timeouts and reception of messages) occur.
Referring to
The layered architecture is often necessary to maintain flexibility. Natural boundaries between layers may be found according to technologies chosen at each layer. Indeed, each layer may encompass multiple technologies that fit the requirements of that layer. For example, off-line or online approaches may be used at the negotiation layer, which is usually the first layer of the Meta-Protocol framework. Moreover, any security measures needed may vary per layer.
To implement the Meta-Protocol framework, a development environment and/or an execution environment may be needed. The development environment is generally responsible for writing down protocol specifications from protocol designs, developing components, and verifying specifications and components. Once a specification is complete along with all the required components, the protocol may be deployed into the execution environment. The development environment architecture and tools can be widely open and can vary from a simple standalone editor and compiler to complex visual (e.g., GUI) systems that integrate editing, coding, and verification.
The distinction between the two environments is important from an operational and performance point of view. An objective of the development environment is to prepare a system and produce necessary code. This objective may be achieved in the background (e.g., under no time constraints). On one hand, operations in the development environment may involve human interaction and may take several cycles to produce the correct specification and, if any, components code. On the other hand, operations in the execution environment may take place at run time. Therefore, by separating these two environments, protocol code may be executed with minimum possible overhead.
Referring to
Various mechanisms may be employed to assist in performing these functions. These include a negotiation mechanism, delivery mechanism, machine-readable protocol specification converter and executable code system manager. Each may be embedded within its respective layer as exemplified in
The system may be able to interact among the layers using a method as exemplified in
A. Negotiation Layer
A goal of the negotiation layer is to establish an agreement between two communicating parties on the name and location of a protocol specification and its components. The protocol specification may be written in XML and/or include a description of a protocol specification language (such as, but not limited to XPSL) specified in an XML schema. In essence, for example, the protocol specification may be a machine-readable XPSL specification. A component may be any software component, such as the ones listed in the Computer Program Listing Appendix. A negotiation mechanism can be used to help accomplish this goal. The initiator of the communication can provide a set of proposed protocol specifications. The responder can then select a protocol specification according to its preferences and notify the initiator.
This goal may be achieved either manually or automatically. The manual approach may be feasible for local areas but may not be appropriate for long distances. Under the automatic approach, the goal may be achieved either via a secure channel (e.g., SSL or IPsec) or through the use of a customized version of the Internet Security Association and Key Management Protocol (ISAKMP). Customization can be performed according to a user's requirements or needs. If secure channels are used, negotiation mechanisms may need to be added. Yet, it is preferable to choose a customized version of ISAKMP because it may already provide a negotiation mechanism in addition to several important security features.
ISAKMP tends to provide packet formats and negotiation procedures for establishing security associations (SA) and key management. For the purpose of maintaining interoperability between systems, it is preferable to separate security association management from key exchange. In addition, the ISAKMP standard may be independent of any specific security protocol or key exchange algorithm. Moreover, this standard may be highly flexible and interoperable with other protocols and algorithms.
Every ISAKMP packet may include one or more payloads organized as a linked list. Each payload can vary in length as specified in a payload header. The first payload may be defined in the main ISAKMP header, and every payload may carry a field that defines the next payload type, which may define the structure of such payload and its content.
It is preferable to customize a Domain of Interpretation (DOI) to define new payload formats, exchange types and name conventions, as well as to save time and effort. To achieve this feature, the IPsec format may be used with various types of information tailored to the needs of the Meta-Protocol framework. For example, IPsec may use ISAKMP proposals to deliver information related to the IPsec type of operation and transforms (e.g., AH or ESP). In the Meta-Protocol framework, ISAKMP may be used to deliver information related to protocol name, location and versions.
The operation of ISAKMP may include two phases. The first phase preferable negotiates security proposals. An agreement upon a specific proposal can establish phase-1-SA. In the second phase, a protocol specific SA may be created under the protection of phase-1-SA. The first phase may offer five types of exchanges: Base, Identity Protection, Authentication Only, Aggressive and Informational. Each type of exchange tends to describe a sequence of messages, and each may differ in the level of authentication and number of messages exchanged. An initiator can select one of these exchanges to deliver proposals according to its needs. The Base Exchange may provide session integrity protection. One embodied implementation of the present invention uses this exchange to deliver the file name and file location of an XPSL protocol specification instead of delivering IPsec related information. If confidentiality is required, then the Identity Protection exchange can be used.
As an embodiment,
According to these exemplified illustrations, in ISAKMP's Base Exchange, an initiator starts by sending a set of protocol proposals, similarly to an exchange of security associations, and a nonce. The nonce may be used to protect against anti-replay. The responder chooses one of the proposals and notifies the initiator. This notification message also includes another nonce. In the next two messages, the parties exchange key information and authentication information. The authentication payload contains a hash value over the previous messages to protect against session highjacking.
The ISAKMP protocol may contain all the security measures needed to protect the negotiation process against DoS, anti-replay and connection highjacking. The five exchange types in ISAKMP usually have different levels of authentication. The most protected exchange may be the Identity Protection exchange with six messages, and the least protected may be the Aggressive exchange with only three messages.
In an instance, as shown in
The initiator may also have the option to append to the packet a key exchange payload carrying information about the proposed key exchange technique (e.g., Oakley or Diffie-Hellman). The key exchange may also carry the required data to generate session keys.
Preferably, a protocol specification of the customized version of ISAKMP may serve as the bootstrap of the Meta-Protocol framework. Simply, this embodiment is typically required from any network node to use the Meta-Protocol framework since the code for ISAKMP may be generated from its specification.
B. Distribution Layer
Generally, specifications and components referenced therein do not need to be stored locally. Communicating parties may exchange them directly (e.g., via a communicating party distribution) or retrieve them from a trusted third party. Such exchange may be facilitated using a delivery mechanism. Specifications and components that are only needed for a short period of time may be deleted after their use to save space. Alternatively, specifications may be retrieved and/or distributed from a local cache. To protect specifications and components referenced therein from unsolicited or malicious alteration, each ought to be digitally signed by their authors and verified by the receiving party. Trusted providers may place their specifications and components at public repositories on the Internet so users may retrieve them when needed. Newer versions may also be pushed from these providers to subscribed users to keep theirs up-to-date.
As a preferred embodiment, the distribution layer uses a directory service, such as the Universal Description, Discovery, and Integration (UDDI) directory, which is a known comprehensive industry initiative that helps businesses define themselves, discover other businesses and share information about their interactions globally. UDDI is also an architecture for web services integration that contains standards-based specifications for advertising, description and discovery services. Each service advertised in a UDDI directory has the freedom to specify a transport mechanism to access that service (e.g., SMTP, FTP, HTTP, and SOAP). Every UDDI user may have the option to check the transport mechanism of the service he or she is seeking before connecting to that service. Communicating parties in the present invention may use UDDI to advertise protocol names, the location of their specifications, the location of the components needed by the specification and the preferred transport mechanism to download the specification and components.
In addition, using UDDI at the distribution layer may also serve users who are planning to start a negotiation but do not have specifications to propose to another party. Such users may consult UDDI directories to discover protocol specifications, their providers, the location of the specifications and their components for download.
UDDI is an open standard specification for directory services. The standard was released on Sep. 6, 2000 as a project aimed to provide service-centric business-to-business (B2B) integration. A goal of UDDI is to enable businesses to establish many business relationships. UDDIs are repositories of information that facilitate discovery and interaction between customers and vendors. Vendors may present their offerings through UDDI as regular text descriptions or as electronic representations (e.g., Web services).
Another goal of UDDI is to provide two main services: publishing and discovery. Typically, publishing is done by the service providers, and discovery is done by the customers. Today, there are several public UDDI sites that are running the most current specifications and are usually available free-of-charge to UDDI developers (e.g., uddi.ibm.com, uddi.rte.microsoft.com and udditest.sap.com). These UDDI sites help enable anyone to search existing data or register new services.
The data available within UDDI may be divided into three categories: white pages, yellow pages and green pages. White pages may include general information about the provider of the service (e.g., contact information). Yellow pages may provide classification information about the service providers (e.g., industry, products and codes). Green pages may contain technical information about the service. This technical information may contain a pointer to an external specification, address of the service provider and a specification of the method for accessing the service. UDDI may not be limited to advertising Web services. Rather, UDDI can be used to advertise any service including web pages, e-mail addresses and Common Object Request Broker Architecture (CORBA) services.
C. Implementation Layer
The traditional manual process, as shown in
The manual design and verification process may be similar to the traditional approach. However, the design process in the present invention may use FSMs to produce protocol specifications in XML. These specification documents generally have to be well-formed XML documents and ought to comply with the rules specified in the protocol XML schema. If these conditions are satisfied, an XSLT stylesheet may automatically implement the protocol without human intervention.
The implementation layer of the present invention may include an approach to produce code (e.g., executable code) that implements a protocol automatically. The proposed approach is preferably based on XML-related technologies and a multitude of components referenced in at least one of the protocol specifications. XML-related technologies may include, but are not limited to, XML schema, XSLT transformations, XSLT processors, XML parsers, and XML editors. Where XPSL protocol specifications are involved, it is suggested that an XML-based language, such as XPSL as later discussed herein, be used to produce code. In general, XPSL may specify protocols described through FSMs. XSLT may be used to transform or convert the specification and any missing component into actual code, such as an executable code. To aid this conversion process, a machine-readable protocol specification converter may be used. XSLT stylesheets may be designed to produce code in different programming languages (e.g., C++, Java or Cobol). It is possible that a single XSLT stylesheet may be associated with a single programming language. Such stylesheet may be used to generate an executable code, which may either be an implementation of or a code used for implementing at least one protocol specification, for a multitude of protocol specifications. The executable code itself may be retrieved from a local cache.
CBSE, a software component, may be used to build a set of operations (e.g., encryption) needed by the protocol. Such set may be a multitude of components referenced in at least one of the protocol specifications.
Every component used in an XPSL specification may be an executable program designed based on CBSE principles. Furthermore, a component may be a software component. Moreover, a component may be shared by more than one XPSL specification. For example, an RSA encryption algorithm may be used in a single protocol several times and may be shared by many protocols. However, a component may also comprise several subcomponents. For instance, a security envelope component consists of a header processing subcomponent, a MAC subcomponent and an encryption algorithm subcomponent.
The idea of modular or component-based design approach is common in many engineering fields and industries. For instance, most electronic devices, such as computers, are assembled from parts that can interoperate within a single system. These parts comprise many different kinds and are supported by many "industry standards" such as motherboards, chips, memory, keyboard and cables. This process also requires that standards for interfaces be defined to allow disparate sets of parts to be assembled into one system. Some of these standards may be dictated by major vendors, while others may be de facto industry standards.
In software engineering, CBSE may help improve the efficiency of the software development process, reduce maintenance costs and enhance the quality of the resulting product. Recently, CBSE has been adopted by many vendors in technologies such as CORBA, COM+, JavaBeans and Software Agents.
A software component may be defined as "a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard." The component model mentioned in this definition refers to the interaction and composition standard. The interaction aspect of the model defines the interface of the component. The composition aspect defines the deployment of the component in terms of installation, configuration and instantiating. While other definitions exist for software component, the recurring characteristics identified by these definitions are independency, interface, context, relationships and the architecture of the component.
CBSE is an approach that helps simplifying complex systems by dividing them into smaller subsystems. Each subsystem may be regarded as a component that can be designed, implemented and tested independently. This approach may exhibit several advantages: the ease of designing and developing large systems, language-independent, reusable, scalable, facilitation of testing and validation, and flexibility.
D. Execution Layer
Generally, the execution layer deals with an executable code of a protocol and depends on services provided by an underlying operating system and a network. All kinds of message exchanges between parties may be performed by a code running at this layer. Protocol code should be loaded as a privileged process by the operating system. This process and its address space may need to be protected against any malicious alteration or termination. To manage the loading and/or running of an executable code, an executable code system manager may be used.
Playing a central and integrative role in the present invention, this layer may include a set of interfaces and control operations. The interfaces are usually responsible for delivering requests and feedback between the external world and the execution layer to, for example, deliver user requests to start or terminate a protocol. The external world may be defined as anything outside of the execution layer, such as a tangible or intangible object, system, action, method, process, etc. Control operations, which may take place at run time, may manage the internal affairs of the execution layer. Internal affairs may be defined as the internal matters, activities, thought processes, operations, etc. within a particular environment, such as the execution layer. Examples include authenticating a user to access a protocol, checking the availability of a protocol, loading or terminating a protocol.
In this environment, the Protocol Control System (PCS) may control the internal activities and provide several interfaces to connect the layers of the present invention to the external world.
The controller often serves as the core of the PCS. It is generally responsible for the coordination of the internal activities of the system. To maintain the integrity of the system, all types of accesses to the internal subsystems should be limited to the controller. The controller is typically responsible for receiving protocol invocation requests, verification of user's access privileges, configuration management, storage of specification and components, protocol code creation or removal, loading or terminating the execution of a protocol, and auditing operations. Requests for system services may come to the PCS from, for example, a user, the operating system, an application or a network.
The controller may also be responsible for authenticating users to access protocols or modify databases (e.g., for registering, adding or deleting a specification or component). To achieve this task, the controller may need to consult internal or external user directory services and access lists determined by the PCS configuration.
Management of the configuration information may also be part of the responsibility of the controller. Only a supervisor administrator is generally allowed to change the configuration information. Configuration information may include time synchronization source, host identity and address, administrator contacts, maximum disk quota allowed for various system databases, audit policies, and access information to external databases (e.g., locations, user accounts, and access methods).
Important roles of the controller include audit and I/O management. Audit logs may be important for problem analysis and security investigations. I/O services may include handling and protecting inter-process communication, as well as communicating with network interfaces. The interfaces with the execution layer may also maintain their own logs of activities.
The cache memory is basically a temporary memory that may used by the PCS to improve the efficiency of the system. Copies of frequently used protocols, components or security related information (e.g. keys and passwords) may be temporarily stored in this cache to reduce preparation time and to speed up execution of protocols.
The code generator may include two processors: an XSLT processor and a compiler. The code generator may act on behalf of the implementation layer. The XSLT processor may take as input an XSLT stylesheet for a specific programming language and an XPSL protocol specification. The XSLT processor may output source code in the language specified in the XSLT stylesheet. The compiler may convert the source code from the XSLT processor into executable code for the protocol.
The interfaces subsystem may be responsible for facilitating the communication between the external world and the PCS. Multiple types of interfaces (e.g., a user, application, operating system, network, etc.) are often needed. Breaking down the communication of the PCS with the external world into specific interfaces may improve evolution and the scalability of the system. Evolution may be improved by replacing an old version of an interface with a newer one. Scalability may be improved by adding new interfaces as needed (e.g., when a new network driver appears).
A difference between the user interface and the application interface is that the former may be used for the manual access to the system. The latter may be used for automated access. For example, a system administrator who wants to make changes in the system needs a user interface. However, an application that needs to query the system or invoke the execution of a protocol requires an application interface. The operating system interface is typically responsible for coordinating the execution of protocols with the operating system. The network interface is often responsible for remote management of the PCS and for retrieving specifications and components from remote sites.
The database subsystem may manage information needed for the operation of the PCS, such as, though not limited to, users' accounts, access list, secret keys, certificates, XPSL protocol specifications, components, administrative accounts, trusted providers, and a registry. To save system resources, some of these databases may be maintained externally (e.g., LDAP, UDDI, iPlant, and Active Directories). Thus, the PCS may consult these directories and retrieve information as needed. The choice of an external or internal database is part of the configuration process of the PCS; such information may be saved as part of the configuration information.
Preferably, the present invention uses an access list and a registry. These two databases tend to be specific to the PCS operation. The access list defines the access permission that each user has to each object (XPSL specification or component) in the system. Each user may have four types of permissions: read (R), write (W), execute (E), and delete (D). A user may also be assigned to a combination of these permissions.
The second database can be the registry. This database may be used to register available objects (specifications or components), their location, provider information, authentication information, and expiration date. This registry can be updated in two ways: automatically or manually. The automatic update may be limited to adding new specifications or components through the on-the-fly process of exchanging protocol specifications. Deleting an object from the registry may be limited to legitimate users (e.g., Administrator). Legitimate users may be allowed to access this registry manually and update it.
A registry record may include, inter alia, an object id, object location, identity of a user who registered the object, identity of a provider who created the object, a signature value (e.g., in binary format), and an expiration date and time for the use of the object.
Every component may be an executable program having a design based on CBSE principles. A component can be designed out of a simple operation (e.g., encryption), or it could comprise several components as a compound component (e.g., security envelope). A component may be shared by more than one XPSL protocol specification. On one hand, for example, an RSA encryption algorithm can be a single component. Such a component may be used in a single protocol several times, as well as being shared by many protocols. On the other hand, a component may also comprise several subcomponents. For instance, a security envelope component may include a header processing subcomponent, a MAC subcomponent and an encryption algorithm subcomponent.
The set of all needed components may not need to be stored in every PCS system. Communicating parties can download a code of a component from one system to another if a code is needed but missing from one of the systems. Moreover, components that are needed for a short time period or by a certain process can be deleted from the system after their use. Furthermore, upgrading a component may be easier than upgrading a version of a protocol in the traditional sense. This same concept may also apply to the XPSL specification of protocols, which can be downloaded from one user to another or from a trusted center to the user for temporary usage or for an upgrade.
To protect these components from malicious alteration, they may need to be signed by their authors and checked by the PCS system before being added to the system. As portrayed in
Every component may have an interface that specifies its parameters and types. This interface should be published with a description of the component operations so that protocol designers can understand it and use it. Developing interfaces and defining conventions for components, names and functions may be, however, essential for compatibility and interoperability among components in the framework. This development can be achieved in two ways—either by standards development committees or by the fact that a component becomes widely available because a major vendor with global reach supports it. A component should not have several names on different machines because this aspect may create confusion and may prevent PCS systems from locating the correct component. Moreover, duplicates can occur because the PCS may contain several instances of the same components but with different names.
Data objects may also be considered components in the system. Such data objects may be used during the process of writing of protocol specifications. Additionally, such data objects tend to be used to hold values that are common among several components, such as time, security keys, sequence and random numbers, and header information.
One objective of the operation of the PCS is to integrate the layers of the Meta-Protocol framework. Each layer of the framework may be implemented through at least one call for an operation as follows:
One way that a call may be performed is via a mechanism within a layer as shown in
To exemplify how a PCS may operate, one may consider a typical scenario that starts with a request to run a protocol. The PCS checks locally for the protocol code. If that code is found, the PCS sends that code for execution. If that code is not found, the PCS looks for a specification, transforms the specification into code, and sends it for execution. Otherwise, the PCS uses the location information provided in the request to retrieve the specification. Once the specification is downloaded, the PCS transforms the specification into code and sends the code for execution. The transformation of protocol specifications to code requires the availability of the code of the components mentioned in the specification. If there are missing components, the PCS has to retrieve them from remote locations according to its internal operational policies.
The minimum requirements for any user of the present invention are usually the ISAKMP specification, its components and an XML transformation stylesheet. Again, ISAKMP may be considered the bootstrap of the present invention. Communicating parties may be required to generate code for ISAKMP to be able to agree upon the subsequent protocol they plan to use. Once that agreement is established, the parties may proceed to download the specification of the agreed-upon protocol, generate a code and start communication by running the generated code.
Performance can also be a concern. While actual performance may depend on the implementation of the present invention, some architectural issues may be relevant to performance. In general, the development process of components and protocols should generate optimized code that has reasonable performance compared to traditional protocols. For example, if a specification specifies the services of an SSL protocol, the present invention should be able to generate an implementation of SSL with similar performance characteristics as an implementation generated by traditional means. The code generated by the PCS can be cached in memory for reuse by similar calls to avoid the overhead of regenerating it.
A. Use of FSMs in Protocol Design
FSMs are commonly used for describing protocols. The graphical representation of an FSM may serve as a visual aid to a designer of a protocol. This representation can help in testing and verifying the correctness of the design. An FSM may have a set of states (represented by circles) and a set of transitions between these states (represented by directed arrows connecting the states). At each state, a set of events may occur. Each event may trigger a transition out of a state. Before a transition occurs, a (possibly empty) set of actions may be executed. One of the states in an FSM is often designated the initial state. To portray an FSM, as shown in
A pair of FSMs, one for each communicating party, may specify a protocol. State activities and state transitions may be coordinated between these two FSMs based on message exchanges. Each state machine may keep track of its internal shared state. The machine shared state may hold common information needed by individual states, such as public or shared keys, user identities and access permissions. The termination of the FSM or the final state may be implicitly defined according to the execution sequence.
B. XPSL XML Elements
An essential concept of the present invention is the use of a domain-specific specification language in lieu of technical natural language for the specification of protocols, as in IETF RFCs. This approach may facilitate automatic protocol implementation from specification.
As illustrated in
For a number of reasons, XML may be used as the basis for a language, which may be called XPSL, to express the specification of protocols. First, XML tends to be an open standard. Second, the tools for handling and processing XML documents and its related technologies are typically mature and widely available. Third, XML is often programming language neutral. Fourth, the XSLT technology usually makes it easy to transform an XML document into any user-preferred programming language.
To specify a protocol executable by a machine under the control of a program of instructions, preferably XPSL, several types of XML elements may be utilized or added. For example, these types include, but are not limited to and are without any particular order, <protocol>, <first-state>, <object>, <instance>, <state>, <action> and <moveto>.
Referring to
A second element that may be added is a <first-state> element. Typically a mandatory element, the <first-state> element may be used to identify the starting state of an FSM. The starting state generally serves as the state that produces the "Hello" message to start a communication. This element should occur only once in an XPSL specification given that an FSM can only have one initial state. However, all other elements may have multiple occurrences.
A third element that may be added is a <state> element. The <state> element may describe different states of a protocol.
Staying with this embodiment, a protocol may include at least one protocol specification written in XML. Moreover, a protocol may include a description of a protocol specification language (such as XPSL) specified in an XML schema.
Additionally, several elements may be added, and used, to extend a machine-readable XPSL for specifying protocols and a method of its integration, into a machine-readable tangible computer-readable medium. A purpose of extension is to address possible requirements of a general XML specification and the process of generating executable code. Such extension may be exemplified in
Hence, a fourth element that may be added is an <object> element. The <object> element may be used to define data, such as messages, keys, constants and random numbers, needed during protocol operations. Every object may have a name and a set of fields. Every field may have a type attribute associated with a <name> element as later described herein. Data types may include, but are not limited to, predefined types, such as Keys, Strings, Integers and Booleans. Objects may be passed as parameters from one action to another. Exemplified in
A fifth element that may be added is an <instance> element. The <instance> element is similar to the concept of instance in object-oriented programming; objects may represent definitions of classes and instances may either be the actual realization of the definition or hold actual data. An object may have several instances, as needed. However, every instance may represent one object and there may not be any shared information among instances. For example, an object, called error-message, may be used to create several instances of error messages as needed in the protocol states. Every error message instance may hold different error codes and an identification of the component that generated the message.
A sixth element that may be added is an <action> element. The <action> element may define actions (e.g., calls to components in a library) that take place inside a state. In some cases, elements may be nested inside an <action> element. These situations may occur when a component needs an instantiation of a data object that was not passed to the state for temporary local usage. For example, a seventh element, such as a <moveto> element, may be added and nested inside an action in various situations (e.g., branching out of a state before completing all the actions in a state due to errors).
The <moveto> element may act as a switch-case statement in a procedural programming language. This element may provide the mechanism that controls the transitions from one state to another. The <moveto> element may add an eighth element, namely an <expression> element, serving as a logical expression, and a ninth element, namely a <case> element, serving as a list of cases. This logical expression may be evaluated to produce a set of predefined values. A <case> element may point to the next state for each possible value of the expression.
A <moveto> element may either be a child of the <state> element or, again, a child of an <action> element. Being a child of an <action> element can provide flexibility for early branching out of the state before finishing all the actions listed in the state. This feature can be useful if an error or timeout is raised by some actions. However, when a <moveto> is used as a child of a state, it may have to be the last element in the state after all the actions.
As another example of an element nested in an <action> element,
Referring again to the third element, as depicted in
Furthermore, each <state> element may add an optional tenth element called <arg>, as illustrated in
Moreover, XPSL and its method of integration may add an optional, eleventh element that is used for identification purposes for any of the above elements. This additional element may be called a <name> element and may be designated as a single or child element. For example, as shown in
Writing down XPSL specifications may be generally perceived as a manual process, as illustrated in
XPSL may be stored in a tangible computer-readable medium readable by a machine, as exemplified in
C. Protocol Data Types
Every programming language often follows a specific approach for defining syntax and semantics for data types. XPSL may adopt a minimum common denominator to provide a unified approach to serve the most popular programming languages. This aspect may be addressed by two formats. First, XPSL may support six primitive data types that are common in most programming languages: byte, int, long, char, string and Boolean.
D. Sufficiency of the Specification Language
The set of XML elements used in XPSL may be sufficient to describe any FSM. For illustrative purposes, all elements of an FSM are mapped into the XPSL specification, and the XPSL specification captures the behavior of an FSM in terms of state transitions. For instance, an FSM F is a tuple (S, s0, T), where S is a set of states, s0 is the initial state and T is a set of state transitions defined as T={(s, ν, c, A)|s, νεS, c⊂Ω, A⊂Θ}. In addition, a transition (s, ν, c, A) is a tuple with two states (the "from" state s and the "to" state ν), a condition c from a set of conditions Ω, and a set of actions A from the set of possible actions Θ. The condition c is a Boolean expression whose terms may include occurrence of events (e.g., arrival of a message and timeout) and comparisons including variables (e.g., window size) and constants. Examples of actions include composing and sending messages.
The behavior of an FSM may be defined by the set of rules that determine how the FSM moves from state to state starting from the initial state s0. This behavior may be described by the following algorithm:
s ← s0
if ∃ (s, v, c, A) ∈ T | (v ≠ null)
then s ← v;
execute actions in A
else stop
This algorithm may start execution from the initial state s0, the current state s at the beginning. Then, all transitions (s, ν, c, A) out of the current state may be examined. The one for which the condition c is true may trigger a state transition to state ν. Before moving to the next state, all actions in the set A ought to be executed. The next state should then become the current state s. The process may repeat itself until a terminal state (i.e., a state with no outgoing transitions) is reached.
An FSM may be described with a tree of XML elements as in
Because an FSM may have limitations for describing the behavior of programs, the XML tree referenced in
E. The XML Schema for XPSL
It is favorable to have an XML schema to enforce XML protocol rules. This schema may be used to validate the syntax of protocol specifications. Generally, the schema prevents developers of XPSL specifications from introducing illegal elements. The schema may also help developers find any missing mandatory elements, such as the <first-state> element, before they run a transformation. The XPSL schema for protocols described using FSMs can be found in the Computer Program Listing Appendix.
For each element or an attribute in an XPSL protocol specification, there tends to be a corresponding definition or constraint that controls the content of the specification.
The definitions in
III. Automatic Code Generation
To transform XPSL protocol specifications into code, XSLT may be used. In some cases, only one XSLT is needed to transform the protocol specifications in a given programming language. Every element in an XPSL specification may cause the XSLT processor to produce the required code. An XSLT spreadsheet may be developed to produce Java code from any XPSL protocol specification. This spreadsheet may also be used on several XPSL protocol specifications. For example, Sun Microsystems' XML Pack, which includes an XSLT transformer and an XML Schema checker, may be used. XSLT rules and filters may be used to identify different XML elements, convert them to their corresponding program code and lace them in the proper XSLT output tree. Every programming language tends to require its own XSLT transformation sheet. Once that sheet is available, any protocol specification written in XPSL may be transformed to that language and compiled in an appropriate system. Code for an XSLT spreadsheet may be found in the Computer Program Listing Appendix.
As a demonstration,
A. The Stylesheet Structure
Producing Java code may require writing a main program and a set of classes. The main program is typically responsible for starting the execution. Classes may correspond to either objects or states. Thus, the first few lines in the stylesheet tend to describe the XML version, the stylesheet version, the XPSL name space, and the type of output.
The <first-state> template often serves as a trivial template that produces the name of an entry point of the state machine. This template may be called once from the main template of the stylesheet. Therefore, as portrayed in
The <object> template typically produces code for data objects. As shown in
The <instance> template, referring to
The <moveto> template may be responsible for producing a Java switch statement for branching. This template generally calls two other templates: (1) the test part of the Java switch statement, and (2) the expected cases as presented in the protocol specification. The first may be referred to as "expression," whereas the second may be referred to as "case."
The <state> template is similar to the main template. Every <state> template may represent a state of an FSM. Every state may consist of a set of objects, instances, actions, and should end up with a <moveto> statement. The <state> template may produce a Java class that corresponds to an FSM state. Typically, the <moveto> statement comes toward the end of the state to determine the next state. However, in some cases (e.g., errors) control flow may branch earlier. Such cases should be expected by the developer of the protocol specification. Therefore, the <moveto> statement should be embedded inside an <action> statement. Otherwise, the sequence of operations may be faulty.
B. Protocol Components
Generally, every component has an interface that specifies its parameters and their types. This interface should be published with a description of a component's operations so that protocol designers can understand and use it. Developing interfaces and defining conventions for component names and functions may, however, be essential for compatibility and interoperability among components in a framework. These actions may be achieved either by standard development committees or by the fact that a component becomes widely available because of a major vendor with global reach it supports. A component should not have different names on the same or different machines because doing so may prevent the execution layer of the present invention from locating the correct component.
Data objects may also be considered components. Such data objects may be used during the process of writing protocol specifications. Furthermore, data objects are often used to hold values that are common among several components, such as time, security keys, sequence and random numbers and header information.
C. Performance
An automatically generated implementation may perform similarly to that of a manually generated one. Some performance degradation should be tolerated given that the present invention often provides an extra level of flexibility (e.g., on-the-fly code generation for new protocols) not available in manually generated implementations. It is likely that most performance concerns may be handled if the components used in the implementation generated by the present invention are optimized for performance. Further performance optimizations may be obtained by caching already generated code for reuse.
IV. Validation Experiments
Several experiments may be conducted to demonstrate the feasibility of the present invention. For instance, XPSL may be used to specify NSAP, TCP's three-way handshake, ISAKMP and SSL cipher suite number 16 (SSL#16). Choosing protocols may provide diversity in terms of protocol purpose (e.g., authentication, transport, negotiation, location in the network stack, and complexity). Except for NSAP, which is usually a simple theoretical security protocol that has no practical use unless combined with other security mechanisms (e.g., anti-replay), all other protocols are often used widely in the Internet. Documentation of these experiments may be found in the Computer Program Listing Appendix.
Each experiment preferably has two parts: 1) specification and automatic code generation and 2) execution and verification of the resulting code. These experiments may be designed to test four qualities of the framework: completeness, consistency, correctness, and flexibility. A complete sequence of operations typically includes negotiation, delivery, automatic code generation, and execution. To demonstrate the consistency of the framework, four experiments may be developed according to the Meta-Protocol framework, where an XPSL specification is preferably written for these protocols. This specification may be shared between two remote parties for generating code. ISAKMP's Base Exchange may be used for the negotiation to determine the required subsequent protocol (e.g., the SSL#16).
The correctness of the framework may be validated by testing the correctness of the XPSL specification, the XSLT stylesheet, and the generated code. The correctness of the generated code may be verified by compiling and running the code and checking its output (e.g., values, formats and sequence of messages). Several test cases may be designed to provide adequate coverage of the main paths of the protocol operation. The results of these tests showed that the four protocol implementations compiled correctly and performed according to their specifications.
The flexibility aspect of the framework may be demonstrated by introducing changes into the XPSL specification, such as replacing some components with others that perform different functionality, changing the order of operations, or inserting additional operations into the sequence. In the ISAKMP Base Exchange (BX) experiment, the MD5 secure may be replaced with a Secure Hash Algorithm (SHA). In the SSL experiment, a Data Encryption Standard (DES) encryption may be replaced with Triple-DES (3DES). These changes may require modification of a single line in the XPSL specification. The code generated through the Java XSLT stylesheet may be tested and found to run correctly.
A. The NSAP Experiment
Two processes are generally needed: one for the client and one for the server. The network support may be simulated in the form of files. A process writing to a file may be considered as sending out data to a communication channel. Message receiving events is typically manual. The process may be designed to pause for input when entering every state to give the user the control to coordinate between a client process and a server process.
The generation of the NSAP code typically requires four components developed specifically for NSAP, as well as several other generic components, which are not limited to NSAP and could be shared by many protocols. These specific components include: ComposeNSAClientMsg, ComposeNSAServerRes, DecomposeNSAClienMsg, and DecomposeNSAServerRes. Examples of generic components include Encrypt, Decrypt and Generate_Int_rand.
B. The TCP Handshake Experiment
As one embodiment, this experiment requires a single process because the FSM for TCP given in RFC 793 recommends the use of a single FSM that combines the client and server operations. Therefore, the XPSL protocol specification and the XSLT transformation may produce code that works on behalf of either a client or a server. However, two error states may be added to demonstrate their flexibility.
An example of a TCP Handshake FSM diagram is illustrated in
As seen in
The following Table 1 outlines the commands for the FSM diagram for the TCP handshake, as illustrated in
Identifier Commands for FSM diagram for TCP Handshake
Passive open;
create TCP
Control Block
Delete TCB
Send SYN
Active open;
create TCB;
Send SYN
Delete TCB
Receive SYN;
Send SYN, ACK
Receive SYN;
Send ACK
Send FIN
Receive ACK of
SYN; x
Receive SYN,
ACK; Send ACK
Send FIN
Receive RIN;
Send ACK
Receive ACK
of FIN; x
Receive FIN;
Send ACK
Send FIN
Receive FIN;
Send ACK of
Receive ACK
of FIN; x
Receive ACK
of FIN2; x
Two data objects and five components have been designed specifically for this experiment. The first data object may be used to maintain the state of the process. One of its functions is to hold public information: sequence numbers and port numbers. The second data object may be used to construct a TCP datagram. The components may be designed for composing and sending TCP datagrams (sendDatagram), checking the received sequence number (checkAckofSYN and checkRcvSynAck), receiving TCP datagrams and decomposing its information, and printing out datagram information (for testing purposes). TCP datagram fields that have no role in the handshake tend not to be implemented (e.g., URG, data offset, and options).
One example of state transition and exchange of messages to set up a handshake is shown in
The user may be required to run the code twice to develop client-server interaction scenarios on a single machine. This experiment may be more difficult to run and synchronize manually. Therefore, to lessen the difficulty, a testing result sheet showing the expected results for each sequence to be compared with the results obtained in the experiment may be used. For instance, the branches may be labeled with numbers. The user may be prompted during the experiment to choose a branch.
The same XSLT stylesheet used in the previous two experiments may be used again to generate Java code. Being able to generate correct code for the three experiments using the same XSLT stylesheet may help demonstrate the power of the XSLT transformation.
C. ISAKMP Experiment
ISAKMP may be used to implement the negotiation layer of the Meta-Protocol. Once again,
Referring to
A comparison between a list of components and objects used in the initiator (i.e., ISAKMP initiator), as exemplified in
In the first state of an ISAKMP session, the initiator receives some input parameters from an application: destination IP and port, a secret value to be used in generating cookies, and initiator private, and public RSA keys. These values may then be passed inside an object called ISAKMPFSM. This object may hold all the variables that are publicly required by all the states during a session.
A goal of the initiator, in the first state, is to prepare a proposal and send it to the responder. This proposal may consist of three parts: payload header, proposed protocol name and location. Again, an example of an ISAKMP initial message may be viewed in
A Java class for the send operation, SendUDP, may be represented in
The responder XPSL specification may work similarly compared to that of the initiator but in reverse order. For example, when the initiator sends a message, the responder should receive that message. Most action components are shared by both parties. However, there tends to be two main differences, namely the values they process and some context-specific operations. For instance, cookies and nonces are prepared by the same components (e.g., MD5 and random number), but their values vary because they are generated by two different processes with different input values (e.g., IP address and port numbers for cookies). Examples of context-specific operations include, but are not limited to, preparing proposal payloads and preparing selection payloads. The proposal payload operation may be performed by the initiator; the selection operation may be performed by the responder.
D. The SSL Experiment
1. SSL Handshake Experiment
In this experiment, two processes may be used to represent a client and a server. The user may also be required to synchronize between the two processes manually. The experiment can be limited only to the Handshake protocol. The Record layer protocol and the Alert protocol are generally not part of the experiment. Therefore, the process should stop after generating the shared keys, composing the Finish message and delivering it to the record layer protocol. The record layer protocol may have to use the negotiated set of keys to apply crypto operations and add an SSL header. Also, limited error checking may be implemented. Moreover, the client and the server may read the RSA keys from local files.
Generally, SSL handshake has three objectives: a client and server need to agree on a set of crypto algorithms to be used to protect traffic, agree on a set of shared keys and authenticate each other. The last objective is optional and may be used to authenticate a server to a client. The SSL specification may provide about 32 options for the first objective. Each option may represent a set of algorithms. An example of an option is: TLS_RSA_with_DES_CBC_SHA.
As per one aspect of the present invention, the SSL handshake process follows the following sequence:
The XPSL protocol specification may follow the sequence shown in the FSM. The state of the machine is maintained in an object called SessionState.
The Java code corresponding to the specification shown in
The component library may provide a component, called createKey, that generates a pair of RSA keys. Generally, this component has to be executed before running the client and server processes. It may take as input a) two file names, one for the public key and the other for the private key, and b) a password to protect the private key. These file names may have to be included in the specification of the protocol before generating the code of the experiment.
2. SSL #16 Experiment
Here, again, two processes may be used to represent a client and a server. As one embodiment, the SSL record layer protocol has to use the negotiated set of keys in the handshake phase to apply the crypto operations and add the SSL header. The SSL may have 32 options, where each option may represent a set of cryptographic algorithms. The operation may be limited to a single option: TSA_RSA_with_DES_CBC_SHA. Moreover, 44 components including 9 data objects may be developed to carry out the operations of SSL#16.
The experiment here is an extension to the SSL Handshake experiment. Five new states may be added to the XPSL specification used in the SSL handshake.
An example of the XPSL specification for SSL#16 is listed in the Computer Program Listing Appendix. Twenty-five components, including 9 data object types, may be developed according to the SSL specification RFC2246 to simplify demonstration and verification. The list of components and data object types is among the components library in the Computer Program Listing Appendix.
It is important to note that this experiment ignores the implementation of many checks (e.g., errors, resource availability, or data types and ranges validations) because such checks may complicate the experiment and verification process. However, one skilled in the art would recognize that such features are needed in real life, and would preferably include such checks to address real life scenarios. In addition, except for the network (TCP), interfaces to application and the operating system are not implemented. TCP may be used to demonstrate that the experiment can run over a network. However, to include these interfaces, a user may manually manage such operations in the experiment.
Since the first four states of the SSL#16 have been described in SSL Handshake, this section describes the remaining five states. In these states, the client and the server may use shared keys developed during the handshake to exchange application data. These keys may be held in an object called SSLSessionState. The structure of the SSLSessionState may be shown in
This experiment may implement a transfer of files from a client to a server. Implementing the other way around is generally straightforward and can be achieved in two ways: either by switching the XPSL specification or adding the components that are responsible for sending files to the XPSL specification of the server. The client FSM, shown in
Similar to the client process, a loop may be placed between states 5 and 7. One purpose of this loop is to repeat the process of receiving SSL protected files from the client. Human intervention may not be needed. The loop may be indefinite until an empty file is received from the client, which may indicate a request for the end of the connection. It may not be necessary to implement the process of assembling large files at state 7 because the fragmentation process might not be implemented in the client process.
E. The Components Library
Preferably, the present invention uses CBSE. To run these experiments, a library that comprises all the necessary operations may be developed. The library may contain about 86 components and 24 data objects. All may be written in Java and may follow the object-oriented programming paradigm. Therefore, messages and data structures are preferably designed as objects that are passed to the components for processing. Moreover, objects that are shared by more than one protocol (e.g., error message) may be implemented as part of the component library for easier accessibility. Similarly, objects that are shared by more than one component may also be included as part of the component library (e.g., StringObject, BytesObject and TCP diagram). The interfaces and brief description of these components may be found in the Computer Program Listing Appendix.
Most of the components have been developed for the purpose of these experiments. However, some may wrap standard Java crypto functions or modified pieces of borrowed code. The component's interfaces and brief description may be provided in the Computer Program Listing Appendix, which lists all the components that are used by the three protocols: NSAP, TCP's 3-way handshake and SSL Handshake. The information there may also indicate whether the component is general, or specific to NSAP, TCP or SSL.
As an example,
V. Related Work
Related work in the area of communication protocols may be found in several research projects: x-kernel, Cactus, Ensemble and the Click router. The x-kernel is an operating system communication kernel designed to provide configurable communication services in which a communication protocol represents a unit of composition. The x-kernel architecture may be extendable. For example, Horus and Coyote are extensions and applications of the x-kernel architecture to the area of group communications. The present invention differs from these research works in that none of them has proposed high level protocol specifications so users may exchange and produce implementations automatically.
In security protocols, the Conduits+ framework has been used to implement IPsec. Cactus is another framework that may be used to implement a security system called SecCom. Conduits+ and SecComm differ from the present invention in two aspects. The first aspect is that the specification of the required configuration may be transmitted through the header information of the messages. In contrast, the specification of the present invention may be coded in a separate document so that it may be transmitted independently of the messages in a secure fashion. Second, the event-driven approach in Cactus to activate components at runtime may add a layer of delay to the system. In contrast, the sequence of operations in the present invention may be predetermined before runtime based on the specification of the protocol leading to the efficient execution of the selected components.
Protocol implementations may be derived automatically from abstract specifications in languages, such as SDL, Esterel, Estelle, LOTOS, Promela++, SMURPH and Cicero. However these languages follow a low level procedural programming paradigm. Therefore, protocol developers need to work out all the details of the operations of the protocols. Conversely, the present invention tends to capitalize on CBSE to produce a high level specification. Therefore, most of the details of the operations of a protocol are usually hidden inside the components.
Automatic Protocol Generation (APG) work produces protocol designs in an automated way. The APG process takes as input a set of requirements and produces a set of proposed protocol designs. Quite the opposite, unlike APG, the present invention may take a design (i.e., the output of the APG process) and may convert it into a specification used to automatically generate executable code for a protocol.
Cryptographic libraries implement security services as independent components. Examples of such libraries include IBM's CCA, RSA's Cryptokit, Microsoft's CryptoAPI, Sun's JCA/JCE, X/Open's GCS-API and Intel's CSSM-API. However, there is no high level and easy way for producing useful valid compositions out of these libraries. Resolving this issue, the present invention may add a layer of mechanisms that facilitate the generation of useful compositions out of these components.
UML is also used for the purpose of automatic code generation. The UML approach differs from the technique taught by the present invention in two aspects: 1) the present invention is simple because it may depend on FSMs, which provide a simpler graphical representation for protocols than UML diagrams, and 2) the present invention may use XSLT to generate code automatically from an XML-based specification, while UML code generation solutions tend to be proprietary and are based on UML graphical representations. It should be noted that XML Metadata Interchange (XMI) may be used as a model interchange format for UMI, but it is not part of the code generation process.
Related work that includes the use of XML to produce program code, such as Libxml2, may also be found. In such works, an instrument designer produces an XML document that describes the instrument's services. This XML document may be used to produce a user information document in HTML format and source code for the instrument embedded services. Generally, the XML description is just a listing of the services, where each service may be associated with a piece of C code that is loaded from a library by an XSLT transformer.
The present invention distinctly contrasts such works by extending such works to the area of protocol implementations in conjunction with the use of CBSE. The XML specification in the present invention may be based on FSMs to provide a detailed description of the flow of control, handling of data objects and the set of operations.
FSMs have also been used to generate code for protocols. For example, a C++ code skeleton for the flow of control of the protocol may be generated directly out of the FSM diagrams. The present invention is distinguishable from this technique in that the present invention may encode FSMs in XML, allowing for automatic code generation in any programming language.
The foregoing descriptions of the preferred embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching without departing from the scope of this invention and its broader aspects. The illustrated embodiments were chosen and described in order to best explain the principles of the invention and its practical application to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. For example, one skilled in the art will recognize that the present invention may be used in search engines, databases and docket systems. Additionally, the present invention may also be used in banks, stock trades, manufacturing of vehicles (e.g., cars, planes, boats, etc.), production plants (e.g., paper mills, oil, etc.), human resources, payroll, etc.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
|Cited Patent
|Filing date
|Publication date
|Feb 10, 1992
|Oct 20, 1998
|Lucent Technologies
|Apparatus and method for communicating data between elements of a distributed system using a general protocol
|Feb 10, 1998
|Aug 15, 2000
|3Com Corporation
|Method and apparatus for determining a protocol type on a network connection using error detection values stored within internetworking devices
|Mar 9, 1998
|Aug 22, 2000
|3Com Corporation
|Method and apparatus for detecting the protocol used by an end station and negotiating a protocol used by the endpoint
|Jan 17, 2002
|Mar 23, 2004
|Cisco Technology, Inc.
|Generic code book compression for XML based application programming interfaces
|Mar 28, 2003
|Oct 31, 2006
|Xilinx, Inc
|Using an embedded processor to implement a finite state machine
|Mar 4, 2004
|Mar 24, 2009
|Secure64 Software Corp.
|Customized execution environment
|Apr 13, 2001
|Apr 11, 2002
|Jeffrey Capone
|System and method for building applications that adapt for multiple device and protocol standards
|Apr 25, 2001
|Oct 31, 2002
|Lewis Woodrow T.
|Method of and system for providing parallel media gateway
|Mar 29, 2001
|Nov 28, 2002
|International Business Machines Corporation
|Automated dynamic negotiation of electronic service contracts
|Jan 24, 2003
|Aug 21, 2003
|Christopher Tofts
|Method of optimising messaging or data transfer, and a system using such a method
|Sep 13, 2002
|Mar 18, 2004
|Rick Rowe
|Casino open network system architecture
|Rebekah Lepro, "Cardea: Dynamic Access Control in Distributed Systems," Nov. 2003, NAS Technical Report NAS-03-020.
|Citing Patent
|Filing date
|Publication date
|Jun 11, 2007
|Dec 11, 2008
|Ebay Inc.
|Method and system for secure network connection
|May 6, 2016
|Nov 17, 2016
|Ciambella Ltd.
|Method and apparatus for automatic software development for a group of controller-based devices
|U.S. Classification
|International Classification
|Cooperative Classification
|European Classification
|Sep 20, 2010
Owner name: GEORGE MASON INTELLECTUAL PROPERTIES, INC., VIRGIN
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GEORGE MASON UNIVERSITY;REEL/FRAME:025011/0142
Effective date: 20100908
Owner name: GEORGE MASON UNIVERSITY, VIRGINIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ABDULLAH, IBRAHIM S.;MENASCE, DANIEL;REEL/FRAME:025011/0126
Effective date: 20100826
|Aug 7, 2015
|Maintenance fee reminder mailed
|Oct 13, 2015
|Fee payment
Year of fee payment: 4
|Oct 13, 2015
|Surcharge for late payment


text:
I Am Afraid I'm a 45 Yo Lesbian
Personal Stories, Advice, and Support 2 People
Did Menopause Make Me Gay?O.K., so I'm not really "menopausal." Perimenopausal is more like it. Oh, and I'm only 44. The f'd up hormones have made me stupid in the head, on top of everything else. Anyway, I've been a feminist since my 20's. I've had many boyfriends...
secondspring 41-45 1 Response 0 Apr 9, 2009

subset: commoncrawl


text:
WEST HOLLYWOOD, California — My Chemical Romance threw a party on Monday night at the House of Blues on the Sunset Strip to celebrate the release of their brand new album, Danger Days: The True Lives of the Fabulous Killjoys, and the members of the MCRmy showed up in their Killjoy finest.
Both inside and out, the House of Blues was transformed into a DayGlo diaspora, part postapocalyptic fashion spectacle, part bizarre performance-art piece, as My Chem fans donned neon masks, brightly colored bandanas and a variety of blinking accessories (glasses, necklaces, bracelets, etc.), all in the name of Danger Days. They strolled through the "Zone 5 Carnival," scarfed down cotton candy, avoided the menacing Draculoids that patrolled the grounds and — perhaps most importantly — witnessed one heck of a concert.
"It was amazing. They're my favorite band, so I was just completely stoked the whole time," 17-year-old MCR fan Ryan Johnson said. "There was a lot of moshing going on, and it was kind of crazy. The energy was amazing."
And that energy was matched only by some MCR followers' dedication ... they came from miles around (and a half a world away) to be here on this night, to be with their fellow fanatics and say they were there on the night their favorite band released its most ambitious album to date.
"It was one of the most amazing concerts of my life ... the utter energy that MCR puts out to the fans and the love all of us have for them, we all come together and it's like one big family having an amazing get-together," 15-year-old Matt Jennette said. "I came all the way here from Chicago because this is the album-release party and I love them with an unholy dedication. I had to see 'em. I paid like $200 for the tickets and it was worth it without a shadow of a doubt."
"I came from Italy, just because I love them more than my life. Their music makes me feel happy," Stefania Fiorese, 24, added. "We were in the first row and it was amazing. I saw them a couple of weeks ago in Paris, and it was so good, but this one was better. The crowd was pushing so hard — everyone was jumping, everyone was trying to reach them. Tomorrow I will be purple all over my body but I don't care."
That sentiment was echoed by pretty much every MCR fan who MTV News spoke to on Monday, many of whom limped out of the House of Blues a little battered, but completely, totally, blissed out of their minds.
"They never cease to amaze me, they're always great shows," John Conaty, 20, beamed. "I got kicked, crowd surfed on, got hit on the head numerous times, but it never felt so good. At every My Chemical Romance show, getting crushed feels the best."
"I got kicked in the face! I didn't even see it coming!" 16-year-old Savannah Hill laughed. "There was a crowd surfer and then they just came out of nowhere and whammed me in the face, but then I continued to watch the show. It was awesome."
Have you seen My Chemical Romance live? Tell us about your concert experiences in the comments.


text:
McEwen up against record field in national champs
A record number of cyclists will line up in next week's Australian Open Road Championships in Mt Torrens, South Australia.
The men's road race will feature 93 elite riders including defending champion Robbie McEwen, while 58 riders will compete in the women's event.
In the time trial events, Queensland's Nathan O'Neill is aiming for his seventh elite men's title and world number one oenone Wood is on track for her third straight victory in the women's event.
Topics: cycling, mount-torrens-5244
First posted


text:
GraphicRiver Ultra backgraunds V2 44072
Stock Graphic \ Backgrounds
Resolution \ Simply \ Projects \ Wallpapers \ Portfolio \ Includes \ Grouped
Stock Graphic - Ultra backgraunds V2 44072 by ktyellow @ GraphicRiver
Stock Graphic \ Backgrounds
Ultra backgraunds V2
Six beautiful colors for funds with three variations each, created in Photoshop with a resolution of 1680X1050 for use in their projects or simply as wallpapers.
Grouped and organized in folders
Includes: psd and jpg files.
My Portfolio.
Layered: Yes; Minimum Adobe CS Version: CS3; Pixel Dimensions: 1680x1050.
Christmas Patterns; Realistic painting background collection ; Icon Package; Light Stripes Background; Ultra backgraunds ; Modern Business card; why colors ?.
Keywords: abstract, background, blue, clean image gallery, flowers, green, moon, red, web, yellow.


text:
At 6-foot-4 and 320 pounds, Brian Williams (Dallas/South Oak Cliff) has the ability to effectively line up as an offensive tackle or defensive tackle.
Williams is a starter at both positions for SOC, and he's getting looks from FBS schools at both spots. Williams has heard from Texas A&M, Tulsa and UTEP thus far.
"Everything has been going great. I'm just getting used to a new scheme on offense and defense quickly," Williams said. "I'm just glad I'm able to help my team out on both sides of the ball. I don't see any disadvantages."
Williams, who has an offer from FCS school Morgan State, said he's more comfortable playing on the defensive side of the ball. He's been a defensive tackle since middle school. Williams began playing on the offensive line as a freshman.
Williams said he will take an official visit to Morgan State in January. He also would like to visit Texas A&M sometime after the season.


text:
Investigate State Police Involvement in Human Trafficking.
Connecticut State Trooper, guilty of Human Trafficking crimes, receives a suspended sentence. Why? We demand answers.
Connecticut State Trooper, guilty of Human Trafficking crimes, receives a suspended sentence. Why? We demand answers.
Join this cause and commit to honor the victims of Sandy Hook Elementary School by calling on our nation's leaders to
Elepahnt ( Elephant) being held hostage for ransom by Indonesian farmers. VIDEO - Published on 30th Jun 2013 The
JUNE 2013 NEWS LINK: http://esecaucus.com/2013/06/secaucus-animal-horrors/
Maryland teenager accused of stabbing family puppy to death! PLEASE READ and share widely. News
Please express support and sympathy for the families who lost loved ones in the Sandy Hook shooting, and those injured.
Force Facebook to remove the page, Wolf Butchering, cooking, and recipes, and all its variations. These pages are
Please join us in asking Senate Majority Leader Harry Reid to stand up to the NRA. People are disgusted by the NRA's
48,000 Americans will be murdered with guns during President Obama's 2nd term. We must demand a plan to end gun
This very sadly is a perfect example of why animal abuse must be reported. Justice for Mary... A 20-year-old Wisconsin
Take action now! Send a letter urging President Correa to respect indigenous rights and the rights of nature.
An estimated 8 million dogs and cats enter animal shelters in the U.S. each year, and approximately 4 million – or


text:
A business version of the new Infiniti Q50 will also be available when the vehicle goes on sale starting next month. This version, dubbed as the 'Executive', will feature one of the most advanced satellite navigation systems and a highly competitive finance package. It is available as Executive and as Premium Executive.
The Executive model has a starting price of £29,870 and comes with a headline contract hire leasing rate of just £299.99 plus VAT per month (3+35 rentals, non-maintenance, 10,000 miles a year). The Q50 Premium Executive, meanwhile, boasts of satellite navigation, heated and powered leather seats with memory and I-Key plus many other features.
It carries a tag of £33,470 or with contract hire for just £336.99 per month. Both versions are available in either manual or automatic transmission. The Q50 (manual transmission) boasts of a 114g/km carbon dioxide rating, leading to benefit-in-kind tax bills for drivers.
A 20 percent taxpayer in 2013/14 will only be charged with a benefit-in-kind tax bill of just £83.45 a month, while a 40 percent taxpayer faces a £166.90 tax bill. The tax bill for a 20-percent taxpayer will only be £99.56 (£199.13) in 2015/16. Lease costs and BIK liability for the automatic version are similarly competitive.
The Infiniti Q50 Executive is powered by 2.2-liter four-cylinder diesel engine that provides 170PS (168bhp) of output and 400Nm of torque that allow it to accelerate from zero to 62mph in 8.5 seconds.
The engine returns 64.2mpg for the manual and 58.9mpg for the automatic. Infiniti UK Fleet Manager Hannah Bishop remarked that the Q50 Executive is "a very attractive and competitive proposition for the business user" as it offers "everything a driver expects in a car and a great deal more besides."


text:
When is a T-shirt shop not just a T-shirt shop? When it's Palmercash. Listen Boise, we're just gonna come straight out with this: Props to you for knowing what a good thing we have here with downtown Boise's new Palmercash store. But at the risk of sounding like complete know-it-alls: do you really know what a big deal it is to have an actual Palmercash store? Huge. So huge we don't even know. And what's even cooler is that the vintage T-shirt maker so popular with the coolest of the kids is homegrown. Giving Idaho street cred one shirt at a time ... Palmercash. Long live the T-shirt for sure.
Second Place: The Modern Man
Third Place: Tie: A Novel Adventure, Paradigm and The White Pine
showing 1 to 10 of 31
Jim's Appliances, Furniture, Bedding
Renewal Consignment Homewares
Euphoria Salon
Record Exchange
Floating Feather Day Spa
Boise Co-op
Idaho Youth Ranch
Boise Blue Art Supply
Shu's Idaho Running Company


text:
Dubai possesses already world's most luxury hotel, The Burj al Arab.
Very soon another highest class hotel will be added: the amazing Atlantis The Palm Hotel. It is a hotel with 1729 rooms and 17 restaurants, and will be opened to the public on 24th September. The construction lasted 4 years and cost 1,5 billion dollars.
This hotel is dedicated to water: it has a huge water aquarium under the hotel ( more stocks, 11 billions of water ) and a huge water park near the hotel ( the biggest from Dubai and Middle East ).
The big aquarium under is easy accessible from the hotel, and you can take a walk through the aquarium without getting wet!
The hotel is also inside luxury decorated, and you are going to feel spoiled, like in 1001 Nights. The
inner architecture of Hotel Atlantis The Palm has also some marine elements.
And you have also the unique opportunity to swim with the dolphins, in the Hotel Delphinpark, just to feel closer to the sea and its living creatures.
My conclusion is simple: Hotel Atlantis The Palm is a jewel you've got to visit!
To my feed via RSS . (?) or via email.
if not, come back tomorrow on journeyetc.com and see what's new :)


text:
Apparently, one of the top trends for Fall 2010 is FUR (real or faux). See the article I'm reading here.
Purlieu, when made out of the pattern yarn (spincycle's novelty yarn) reminds me of a luxurious furry collar. I try to stay current on fashion without being trendy or tasteless. Right now I am scheming up another soft, furry, knit for your fuzzle-tastic delight. Stay tuned.


text:
In a recent email I received from Tom, he shared 7 prospecting, lead generation, easy business building strategies, and other fantastic tools each of us kind find helpful as we look to build a successful business.
I thought I would share the links with you. Take some time to click on each and take careful notes!
Remember to also visit the business building resources below!
To Your Success,
Monique Hawkins
Be a Mentor with A Servant's Heart
Tom Schreiter Recommended Links:
1. Want instant rapport with your
prospects? Here are six ways:
2. You often hear me talk about the 6
levels of communication. We always want
to use the highest level available to
us. Here is the video:
3. Want more hot prospects now? I've
posted several ways to get them on my
4. Our job is to close. We don't get
paid unless we close. This is the
link to the Members-only class that
explains closing like you never could
5. Every new distributor needs to read
this. If they really understood how their
network marketing business really worked,
they would soar.
6. Many readers couldn't get on the
Jerry "D'Rhino" Clark tele-training
call. Here is the link to the recording
of the call. Enjoy!
7. New distributors are intimidated by the
task of building a huge downline. Make it
simple and comfortable for them with this
Tom 'Big Al' Schreiter
Fortune Network Publishing
Phone +1 (281) 280-9800
PO Box 890084, Houston, TX 77289 USA
Resources To Help You Grow Your Business
"Success in 10 Steps" The ebook recommended by Tom Schreiter and
Michael Dlouhy which teaches you how to build a successful mlm business in 10 easy steps.
My Personal Blog: Monique's Home Based Business Tips
"How to Double Your Traffic by Writing Irresistible Headlines" Webinar http://headlinehacks.com/watch-aweber-replay/
The Big Al Report by Tom Schreiter: http://www.BigAlReport.com
"Fortune Now" by Tom Schreiter: http://www.fortunenow.com