RFC 2478

The Simple and Protected GSS-API Negotiation Mechanism

📅 published December 1998, from ietf

📜 RFC 2478: The Simple and Protected GSS-API Negotiation Mechanism

Okay bestie, let's get into it 💖 This one came out in December 1998, written by E. Baize and D. Pinkas from Bull 🎀. It's on the Standards Track, so it's aiming to become an actual Internet standard 💅 The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any earlier RFC 🦋

Status of this Memo ✨

This is an Internet standards track protocol for the Internet community, and the authors are literally asking for discussion and suggestions 💬 If you want to know where it stands, check the current edition of "Internet Official Protocol Standards" (STD 1) for the standardization state and status. Distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (1998). All Rights Reserved. 💜

1. ABSTRACT 🦋

Okay so this document defines a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API), which is described in [1] 🔐

The GSS-API gives you a generic interface that can sit on top of different security mechanisms. The vibe is: if two peers have GSS-API credentials for the same security mechanism, they can set up a security context between them (subject to policy) ✨ The catch is that GSS-API doesn't say how peers figure out whether they even have a mechanism in common 🙈

So this is where the Simple and Protected GSS-API Negotiation Mechanism comes in 👑 It's a pseudo-security mechanism, identified by the object identifier iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2). It lets GSS-API peers work out, in-band, whether their credentials share one or more common GSS-API security mechanisms. If they do, it invokes normal security context establishment for a selected common mechanism 🔥 This is most useful for apps built on GSS-API implementations that support multiple security mechanisms, so it's giving "main character energy" for those setups 💅

It allows negotiation of different security mechanisms, different options within a given security mechanism, or different options from several security mechanisms. Iconic range, honestly 🌈

Once the common mechanism is identified, that mechanism can also negotiate its own options during its context establishment. Those options live inside the mechanism tokens, so the SPNEGO protocol can't see them 🙈 It's like a little secret inside the envelope 💌

The negotiation model goes like this: the initiator proposes either one security mechanism or an ordered list of them. The target can accept the proposed mechanism, choose one from the offered set, or reject the proposed value(s). Then the target tells the initiator what it chose ✨

In its basic form this protocol requires an extra round trip. Connection setup is a big deal for network performance, and extra round trips over WAN links, packet radio networks, and so on really do make a difference 😭 To dodge that extra trip, the initiator's initial security token for its preferred mechanism can be embedded in the initial token. If the target's preferred mechanism matches the initiator's preferred mechanism, the negotiation protocol adds no additional round trips 🚀

The simple and protected GSS-API mechanism negotiation also gives you a way to protect the negotiation itself. That protection must be used when the underlying mechanism selected by the target is capable of integrity protection 🛡️

When all the mechanisms proposed by the initiator support integrity protection, or when the selected mechanism supports it, the negotiation mechanism becomes protected. That guarantees the appropriate mechanism supported by both peers was selected 🫶

This whole thing uses the concepts from the GSS-API specification [1]. The negotiation data gets wrapped in context-level tokens, so callers of the GSS-API don't need to know the negotiation tokens exist. They only need to know about the new pseudo-security mechanism 🧚 If the negotiation phase fails, a major status code is returned: GSS_S_BAD_MECH 💀

2. NEGOTIATION MODEL 🌸

2.1. Negotiation description 💖

The security mechanism negotiation model reuses a subset of the concepts specified in [2] 🦋

Each OID represents one GSS-API mechanism or one variant of one 🍓

  • When the initiator proposes one security mechanism, that's the only mechanism it supports, or the one it selected (when the additional APIs defined in Annex A are used) ✨
  • When the initiator proposes several security mechanisms, they form a set of mechanisms the initiator supports or selected (when the additional APIs defined in Annex A are used) 💅

The first negotiation token the initiator sends contains an ordered list of mechanisms. It also includes a set of options (for example the deleg, replay, and conf flags) that should be supported by the selected mechanism. Optionally, it can include the initial security token for the initiator's desired mechanism (the first one on the list) 🎀

The first negotiation token the target sends contains the result of the negotiation: accept_completed, accept_incomplete, or reject. If it's an accept, it also contains the agreed security mechanism 👑 It may also include the response to the initiator's initial security token, but only when the first mechanism the initiator proposed was the one selected 🫶 When that first mechanism is acceptable to the target, the target should respond to the initiator's desired-mechanism initial security token if one is present. But if that isn't possible, the target can just ignore it and leave out the responseToken from the first reply 🙈

Implementations that can piggyback the initial token get rewarded with faster connection setup 🚀

When negotiation succeeds, the security mechanism is the one suitable for the target, picked from the list the initiator offered 🔥 How the target chooses a mechanism is an implementation-specific local matter. Without any other policy, the target should choose the first mechanism in the list for which valid credentials are available ✨

Once a mechanism has been selected, its specific tokens get carried inside the negotiation tokens: in the mechToken for the initiator, and in the responseToken for the target 💌

Part 1 of 4 is done, bestie 🦋 Part 2 is coming up next, so stay tuned ⭐

2.2. Negotiation procedure ✨

Here's the negotiation procedure in a nutshell, bestie 💅:

  • (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but asks (either explicitly, with the negotiation mechanism, or by accepting a default, when the default is the negotiation mechanism) that the Simple and Protected GSS-API Negotiation Mechanism be used 🦋
  • (b) the initiator GSS-API implementation emits a negotiation token with a list of supported security mechanisms for the credentials used for this context establishment, and optionally an initial security token for the first mechanism on that list (i.e. the preferred mechanism), then indicates GSS_S_CONTINUE_NEEDED status 🌸
  • (c) the GSS-API initiator sends the token to the target application 💌
  • (d) the GSS-API target takes the token in by invoking GSS_Accept_sec_context. The target GSS-API implementation emits a negotiation token containing which, if any, of the proposed mechanisms it supports (or has selected) 🧚

If the mechanism the target selects matches the preferred mechanism the initiator identified, and the initiator provides a mechToken, the negotiation token response MAY also contain an initial security token from that mechanism ✨.

If the preferred mechanism is accepted, GSS_Accept_sec_context() indicates GSS_S_COMPLETE when unilateral or mutual authentication has been performed and involves a single token in either direction 👑.

If a proposed mechanism is accepted and it wasn't the preferred mechanism, or if the first negotiation token the initiator sent did not include a mechToken, then the negotiation token response the target sends MAY also contain a response token from that mechanism, which carries mechanism-specific information (e.g. to transmit a certificate) 🎀. The initiator MAY ignore such an initial token if it isn't prepared to process it 🙈.

If a proposed mechanism other than the preferred one is accepted, or the preferred mechanism is accepted but involves multiple exchanges (e.g. challenge-response authentication), then GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED status 🔥.

If the proposed mechanism(s) are rejected, GSS_Accept_sec_context() indicates GSS_S_BAD_MECH status. The security context initialisation has failed 💀.

  • (e) the GSS-API target returns the token to the initiator application 🍓
  • (f) the GSS-API initiator takes the token in by invoking GSS_Init_sec_context 💜

GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED, GSS_S_COMPLETE or GSS_S_BAD_MECH status 🦋.

GSS_S_BAD_MECH shows up when the negotiation token carries a reject result, or when it carries an accept result and the mechanism the target selected isn't on the initial list the initiator sent 🙅‍♀️.

GSS_S_BAD_MIC shows up when the selected mechanism supports a MIC token but the MIC computed over the list of mechanisms the initiator sent is missing or wrong 🙈.

If the negotiation token carries a reject result, context establishment is impossible. For example, a rejection happens if the target doesn't support the initiator's proposed mechanism type(s). When the mechanism negotiation fails, the mech_type output parameter value is the negotiation mechanism type 💔.

GSS_S_CONTINUE_NEEDED comes back when the negotiation token carries an accept result and more tokens have to be exchanged to finish context establishment for the selected mechanism. In that case GSS_Init_sec_context() returns an initial context token as output_token, with the selected mechanism's context token wrapped inside that output_token 🌈.

The initiator then sends the output_token to the target. Context setup carries on under the standard GSS-API conventions for the selected mechanism, with that mechanism's tokens encapsulated until GSS_S_COMPLETE is returned for both the initiator and the target 🫶. While GSS_S_CONTINUE_NEEDED is being returned, the mech_type output parameter is not valid yet 🌸.

When GSS_S_COMPLETE is returned, the mech_type output parameter tells you the selected mechanism 👑. When the final negotiation token does not contain a MIC, the initiator GSS-API implementation MUST check that the returned/selected mechanism is on the originally submitted list of mechanisms, and also verify that the selected mechanism is not able to support a MIC 🔍. When the final negotiation token contains a MIC over the initial mechanisms list the initiator sent, the MIC MUST be verified 🔐.

Heads up: the *_req_flag input parameters for context establishment are relative to the selected mechanism, and so are the *_state output parameters. In other words, these parameters don't apply to the negotiation process itself 🚨.

The initiator GSS-API calling application may need to know whether the negotiation exchanges were protected. To check, when GSS_S_COMPLETE is returned it can simply test the integ_avail flag. If that flag is set, the negotiation was protected 🛡️.

When a GSS-API implementation that doesn't support negotiation receives a negotiation token on the target side, it indicates GSS_S_BAD_MECH status, as if a particular basic security mechanism had been requested but wasn't supported 🙃.

When GSS_Acquire_cred is invoked with the negotiation mechanism as desired_mechs, an implementation-specific default credential is used to carry on the negotiation. A set of mechanisms specified locally by the system administrator is then available for negotiation. If the caller wants to make its own choice, an additional API has to be used (see Appendix A) 🎀.

3. DATA ELEMENTS 💖

3.1. Mechanism Type 🦋

MechType::= OBJECT IDENTIFIER

mechType: each security mechanism is as defined in [1].

3.2. Negotiation Tokens 🌸

The syntax of the negotiation tokens follows the InitialContextToken syntax defined in [1]. The security mechanism of the initial negotiation token is identified by the Object Identifier iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) ✨.

3.2.1. Syntax 🧚

This section specifies the syntax of the corresponding "innerContextToken" field for the first token and for subsequent negotiation tokens. During mechanism negotiation, the "innerContextToken" field contains the ASN.1 structure "NegociationToken" given below, encoded using the DER encoding conventions 💅.

NegotiationToken ::= CHOICE {
                              negTokenInit  [0]  NegTokenInit,
                              negTokenTarg  [1]  NegTokenTarg }

MechTypeList ::= SEQUENCE OF MechType

NegTokenInit ::= SEQUENCE {
                            mechTypes       [0] MechTypeList  OPTIONAL,
                            reqFlags        [1] ContextFlags  OPTIONAL,
                            mechToken       [2] OCTET STRING  OPTIONAL,
                            mechListMIC     [3] OCTET STRING  OPTIONAL
                         }

ContextFlags ::= BIT STRING {
        delegFlag       (0),
        mutualFlag      (1),
        replayFlag      (2),
        sequenceFlag    (3),
        anonFlag        (4),
        confFlag        (5),
        integFlag       (6)
}

negTokenInit: this is the negotiation token the initiator sends to the target. For the first token sent, it contains one or more security mechanisms supported by the initiator (listed in the mechTypes field) and the service options (reqFlags) requested to establish the context. The context flags SHOULD be filled in from the req_flags parameter of init_sec_context() 🌈.

The mechToken field is optional for the first token sent, which all target implementations would not have to support. However, for targets that do support piggybacking the initial mechToken, an optimistic negotiation response is possible. Otherwise the mechToken carries the tokens specific to the selected mechanism 🫶.

The mechListMIC is an optional field. If the chosen mechanism supports integrity, the initiator MAY optionally include a mechListMIC, which is the result of a GetMIC of the MechTypes in the initial NegTokenInit, and return GSS_S_COMPLETE 🔐.

When the chosen mechanism uses an odd number of messages, the final mechanism token is sent from the initiator to the acceptor. In this case there's a tradeoff: either use the optimal number of messages, or use an additional message from the acceptor to the initiator to give the initiator assurance that the initiator's mechanism list wasn't modified. The implementation can choose which tradeoff to make (see section 4.2.2 for further details on processing that field) ⚖️.

NegTokenTarg ::= SEQUENCE {
    negResult      [0] ENUMERATED {
                            accept_completed    (0),
                            accept_incomplete   (1),
                            reject              (2) }          OPTIONAL,
    supportedMech  [1] MechType                                OPTIONAL,
    responseToken  [2] OCTET STRING                            OPTIONAL,
    mechListMIC    [3] OCTET STRING                            OPTIONAL
}

negTokenTarg: this is the negotiation token the target returns to the initiator. For the first token returned, it contains a global negotiation result and the selected security mechanism (if any) 🎀.

negResult: the result accept_completed means a context has been successfully established, while accept_incomplete means additional token exchanges are needed 💫.

Note: For the case where (a) a single-token context setup is used and (b) the preferred mechanism does not support the integrity facility, which would otherwise cause a mechListMIC to be generated and enclosed, this feature lets you tell apart a mechToken sent by the initiator but not processed by the target (accept_incomplete) and a mechToken sent by the initiator and processed by the target (accept_completed) 🕵️‍♀️.

For targets that support piggybacking the initial mechToken, an optimistic negotiation response is possible, and in that case it includes a responseToken that may continue the authentication exchange (e.g. when mutual authentication has been requested, or when unilateral authentication needs several round trips). Otherwise the responseToken carries the tokens specific to the selected mechanism. For any subsequent tokens the target returns, negResult and supportedMech are not present 🦋.

For the last token the target returns, the mechListMIC, when present, is a MIC computed over the MechTypes using the selected mechanism 🔑.

negResult: the result of the negotiation exchange, as specified by the target. It can be one of:

  • accept_completed: the target accepts the preferred security mechanism, and the context is established for the target, or 🎉
  • accept_incomplete: the target accepts one of the proposed security mechanisms and further exchanges are necessary, or ⏳
  • reject: the target rejects all the proposed security mechanisms 🚫

supportedMech 💖 This field has to be present when negResult is accept_completed or accept_incomplete. It's a choice from the mechanisms the initiator offered.

responseToken ✨ This field MAY be used either to send the response to the mechToken when the initiator sends it, and the first mechanism from the list has been selected by the target, or to carry the tokens specific to the selected security mechanism.

mechListMIC 🔥 If the selected mechanism can do integrity protection, this field MUST be present in the last message of the negotiation. That's when the underlying mechanism returns a non-empty token and a major status of GSS_S_COMPLETE. It holds the result of a GetMIC of the MechTypes field in the initial NegTokenInit. It lets you verify that the list the initiator sent arrived at the target unmodified 🕵️‍♀️

3.2.2. Processing of mechListMIC 🦋

Okay so if the mechanism picked by the negotiation doesn't support integrity, then there's no mechListMIC at all. But if it does, a mechListMIC MUST be used and validated the way we explain below 🫶

If the mechanism supports integrity and uses an even number of messages, then the target MUST compute a MIC as described above, and send it in the final NegTokenTarg along with the final mechToken. The initiator MUST require that the mechListMIC field is present and valid when it receives the last token. Without a valid mechListMIC, the negotiation MUST fail, as if the last context establishment token was invalid 💀

If the chosen mechanism supports integrity and uses an odd number of messages, the final mechanism token gets sent from the initiator to the target. This is where it gets a little tricky 🙈 There's a tradeoff here. You can go with the optimal number of messages, or you can add one more message from the target to the initiator so the initiator gets assurance that its mechanism list wasn't modified. The implementation gets to pick which tradeoff it wants 💅

When generating the final NegTokenInit message, the NegTokenInit MAY optionally include a mechListMIC, which is the result of a GetMIC of the MechTypes in the initial NegTokenInit and returns GSS_S_COMPLETE. The target MUST check the presence of the MIC computed over the mechList sent in the initial NegTokenInit. Then there are three cases to consider 👀

  1. If the mechListMIC is present and correct, then GSS_S_COMPLETE is returned to the target with no token. The context is established by the target ✨
  2. If the mechListMIC is present but invalid, then the context establishment MUST fail. An error major status code is returned to the target 😭
  3. If the mechListMIC is not included in the final NegTokenInit, then GSS_S_COMPLETE MUST be returned to the target with a token. That token MUST be a NegTokenTarg, with a MIC included as described above, and no responseToken. The application then sends this token back to the initiator, which MUST verify that the mechListMIC field is present and valid 🔍
Note: If the MIC was originally sent by the initiator, but thenafter deleted by an attacker, the target will send back a token according to the description above. The initiator won't be able to process that returned token, so the context establishment MUST then fail. 🚨

4. EXAMPLES : SECURITY MECHANISM NEGOTIATION 🎀

Okay, here are some examples of security mechanism negotiation between an initiator (I) and a target (T) 🧚

4.1. Initial steps 🌸

So the initiator (I) supports two security mechanism types, GSS-MECH1 and GSS-MECH2. It invokes GSS_Init_sec_context() with:

   Input
     mech_type = OID for negotiation mechanism or NULL, if the
     negotiation mechanism is the default mechanism.

   Output
     major_status = GSS_S_CONTINUE_NEEDED
     output_token = negTokenInit

The negotiation token (negTokenInit) contains two security mechanisms with:

     mechType = GSS-MECH1 or
     mechType = GSS-MECH2

(I) sends the negotiation token to (T) 💌

4.2 Successful negotiation steps 💅

   (T) supports GSS-MECH2
   (T) receives the negotiation token (negTokenInit) from (I)
   (T) invokes GSS_Accept_sec_context() with :

   Input
        input_token = negTokenInit

   Output
        major_status = GSS_S_CONTINUE_NEEDED
        output_token = negTokenTarg

The negotiation token (negTokenTarg) contains:

        negResult = accept (the negotiation result)
        supportedMech : mechType = GSS-MECH2

(T) returns the negotiation token (negTokenTarg) to (I), and then (I) invokes GSS_Init_sec_context() with:

   Input
        input_token = negTokenTarg

   Output
        major_status = GSS_S_COMPLETE
        output_token = initialContextToken (initial context token
                                            for GSS-MECH2)
        mech_type = GSS-MECH2

The subsequent steps are security mechanism specific, and they work as specified in [1]. The output tokens from the security mechanism get encapsulated in a NegTokenTarg message (with the supportedMech field omitted, and the mechListMIC included with the last token) 🦋

4.3. Failed negotiation steps 🙈

   (T) supports GSS-MECH3.
   (T) receives the negotiation token (negTokenInit) from (I)
   (T) invokes GSS_Accept_sec_context() with :

   Input
        input_token = negTokenInit

   Output
        major_status = GSS_S_BAD_MECH
        output_token = negTokenTarg

The negotiation token (negTokenTarg) contains:

        negResult = reject (the negotiation result)

(T) returns the negotiation token (negTokenTarg) to (I), and then (I) invokes GSS_Init_sec_context() with:

   Input
        input_token = negTokenTarg

   Output
        major_status = GSS_S_BAD_MECH

Oof, the security context establishment has failed 💔

4.4 Successful Negotiation with preferred mechanism info 🌈

The initiator (I) supports two security mechanism types, GSS-MECH1 and GSS-MECH2, and it invokes GSS_Init_sec_context() with:

   Input
        mech_type = OID for negotiation mechanism or NULL, if the
        negotiation mechanism is the default mechanism.

   Output
        major_status = GSS_S_CONTINUE_NEEDED
        output_token = negTokenInit

The negotiation token (negTokenInit) contains two security mechanisms with:

        mechType = GSS-MECH1 or
        mechType = GSS-MECH2

        mechToken = output_token from GSS_Init_sec_context
       ( first mechType) as described in [1]

(I) sends the negotiation token to (T) ✨

Now the target (T) supports GSS-MECH1, so it receives the negotiation token (negTokenInit) from (I) and invokes GSS_Accept_sec_context() with:

   Input
        input_token = negTokenInit

   Output
        major_status = GSS_S_CONTINUE_NEEDED
        output_token = negTokenTarg

The negotiation token (negTokenTarg) contains:

        negResult = accept (the negotiation result)
        supportedMech : mechType = GSS-MECH1

        mechToken = output_token from
                         GSS_Accept_sec_context(mechToken )

(T) returns the negotiation token (negTokenTarg) to (I), and then (I) invokes GSS_Init_sec_context() with:

   Input
        input_token = negTokenTarg

   Output
        major_status = GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED as needed
        output_token = ContextToken (initial or subsequent context token
                       for GSS-MECH1)
        mech_type = GSS-MECH1

Specific implementations of the protocol can support the optimistic negotiation by completing the security context establishment using the agreed upon mechanism, as described in [1]. As described above in section 5.2, the output tokens from the security mechanisms get encapsulated in a NegTokenTarg message (with the negResult and supportedMech fields omitted, and the mechListMIC included with the last token) 🧁

5. SECURITY CONSIDERATIONS ⚠️

When the mechanism the target selects from the list the initiator supplied supports integrity protection, then the negotiation is protected 🔐

When one of the mechanisms the initiator proposed does not support integrity protection, then the negotiation is exposed to all the threats a non-secured service is exposed to. Especially, an active attacker can force the use of a security mechanism that isn't the common preferred one (when multiple security mechanisms are shared between peers) but is still acceptable to the target 😱

In any case, the communicating peers MAY be exposed to the denial of service threat 🥺

6. ACKNOWLEDGMENTS 🫶

Big thank yous to Stephen Farrell of SSE, Marc Horowitz of Stonecast, John Linn of RSA Laboratories, Piers McMahon of Platinum Technology, Tom Parker of ICL and Doug Rosenthal of EINet, for reviewing earlier versions of this document and for giving useful inputs 💜 Thanks are also due to Peter Brundrett of Microsoft for his proposal for an optimistic negotiation, and to Bill Sommerfeld of Epilogue Technology for his proposal for protecting the negotiation 👑

APPENDIX A 👑

GSS-API NEGOTIATION SUPPORT API ✨

To give a GSS-API caller (either the initiator or the target, or both) the ability to choose a reduced set of mechanisms for negotiation from the set of supported mechanisms, two additional APIs are defined:

  • GSS_Get_neg_mechs() indicates the set of security mechanisms available on the local system to the caller for negotiation.
  • GSS_Set_neg_mechs() specifies the set of security mechanisms to be used on the local system by the caller for negotiation.

A.1. GSS_Set_neg_mechs call 🌷

Input:

     cred_handle          CREDENTIAL HANDLE
                          - NULL specifies default credentials
     mech_set             SET OF OBJECT IDENTIFIER

Outputs:

     major_status INTEGER,
     minor_status INTEGER,

Return major_status codes:

  • GSS_S_COMPLETE indicates that the set of security mechanisms available for negotiation has been set to mech_set.
  • GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.

This call lets callers specify the set of security mechanisms that may be negotiated with the credential identified by cred_handle. It's meant for specialised callers who need to restrict the negotiable mechanisms from the full set available to the caller (based on available credentials). Note that if more than one mechanism is specified in mech_set, the order in which they're specified implies a relative mechanism preference for the target 🍓

A.2. GSS_Get_neg_mechs call 🦋

okay so this one is the call for figuring out which security mechanisms are up for negotiation with a given credential 🧚 it's giving "who can I actually talk to right now" energy

Input:
     cred_handle    CREDENTIAL HANDLE
                    - NULL specifies default credentials

Outputs:
     major_status INTEGER,
     minor_status INTEGER,
     mech_set     SET OF OBJECT IDENTIFIER

the return major_status codes you can get back are:

  • GSS_S_COMPLETE: the set of security mechanisms available for negotiation came back in mech_option_set 💅
  • GSS_S_FAILURE: the call couldn't be done, and the GSS-API level doesn't say why 💀

this call lets callers see which mechanisms they can negotiate with the credential named by cred_handle ✨ it's meant for specialised callers who want to shrink the negotiable list down from every mechanism they support, based on which credentials they actually have 🎀

⚠️ Note: GSS_Indicate_mechs() lists every mechanism type on the local system 😭 this call takes no input parameter, so the set it returns isn't guaranteed to work for every credential. bestie, don't mix them up!

REFERENCES 📚

  • [1] Linn, J., "Generic Security Service Application Program Interface", RFC 2078, January 1997.
  • [2] Standard ECMA-206, "Association Context Management including Security Context Management", December 1993. Available on http://www.ecma.ch

AUTHORS' ADDRESSES 🌸

Eric Baize
Bull - 300 Concord Road
Billerica, MA 01821 - USA

Phone: +1 978 294 61 37
Fax: +1 978 294 61 09
EMail: Eric.Baize@bull.com


Denis Pinkas
Bull
Rue Jean-Jaures
BP 68
78340 Les Clayes-sous-Bois - FRANCE

Phone: +33 1 30 80 34 87
Fax: +33 1 30 80 33 21
EMail: Denis.Pinkas@bull.net

Okay, this part is legal stuff, so I'm keeping it word for word. Copyright is held by the Internet Society.

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🫶

📦 where this page comes from