draft-ietf-dnsext-gss-tsig-06.txt

bind-3.2.

Expires August 28, 2003                                       [Page 16]

INTERNET-DRAFT                   GSS-TSIG             February 28, 2003

  III. Server receives a query with QTYPE = TKEY
  When server receives a query with QTYPE = TKEY, the server verifies
  that Mode and Algorithm fields in the TKEY record in the Additional
  records section of the query are set to 3 and "gss-tsig" respectively.
  It finds that the key_name 789.client.example.com.server.example.com.
  is not listed in its (key_name, context_handle) mapping table.


  IV. Server calls GSS_Accept_sec_context
  To continue security context negotiation server calls
  GSS_Accept_sec_context with the following parameters (Note that some
  INPUT and OUTPUT parameters not critical for this algorithm are not
  described in this example)
   INPUTS
     CONTEXT HANDLE input_context_handle  = 0
     OCTET STRING   input_token           = token specified in the Key
                              field from TKEY RR (from Additional
                              records section of the client's query)
  The OUTPUTS parameters returned by GSS_Accept_sec_context include
     INTEGER        major_status = GSS_S_CONTINUE_NEEDED
     CONTEXT_HANDLE output_context_handle context_handle
     OCTET STRING   output_token output_token

  Server stores the mapping of the
  789.client.example.com.server.example.com. to OUTPUT context_handle
  in its (key_name, context_handle) mapping table.


  V. Server responds to the TKEY query
  Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's
  call to GSS_Accept_sec_context, the server responds to the TKEY query
  placing in the answer section a TKEY record containing output_token in
  the Key Data RDATA field. The error field in the TKEY record is set to
  0. The RCODE in the query response is set to NOERROR.


  VI. Client processes token returned by server
  When the client receives the TKEY query response from the server, the
  client calls GSS_Init_sec_context with the following parameters (Note
  that some INPUT and OUTPUT parameters not critical for this algorithm
  are not described in this example)
     CONTEXT HANDLE input_context_handle  = the context_handle stored
          in the client's mapping table entry ([e-mail].,
          789.client.example.com.server.example.com., context_handle)
     INTERNAL NAME  targ_name             = "[e-mail]"
     OCTET STRING   input_token           = token from Key field of TKEY
          record from the Answer section of the server's response
     BOOLEAN        replay_det_req_flag   = TRUE
     BOOLEAN        mutual_req_flag       = TRUE


  The OUTPUTS parameters returned by GSS_Init_sec_context include
     INTEGER        major_status = GSS_S_COMPLETE

Expires August 28, 2003                                       [Page 17]

INTERNET-DRAFT                   GSS-TSIG             February 28, 2003


     CONTEXT HANDLE output_context_handle = context_handle
     OCTET STRING   output_token = output_token
     BOOLEAN        replay_det_state = TRUE
     BOOLEAN        mutual_state = TRUE

  Since the major_status is set to GSS_S_COMPLETE the client side
  security context is established, but since the output_token is not
  NULL client MUST send a TKEY query to the server as described below.


  VII. Client sends a query with QTYPE = TKEY to server
  Client sends to the server a TKEY query for the
  789.client.example.com.server.example.com. name. Query contains a TKEY
  record in its Additional records section with the following fields
  (Note that some INPUT and OUTPUT parameters not critical to this
  algorithm are not described in this example)
     NAME = 789.client.example.com.server.example.com.
     RDATA
        Algorithm Name      = gss-tsig
        Mode                = 3 (GSS-API negotiation - per [RFC2930])
        Key Size            = size of output_token in octets
        Key Data            = output_token


  VIII. Server receives a TKEY query
  When the server receives a TKEY query, the server verifies that Mode
  and Algorithm fields in the TKEY record in the Additional records
  section of the query are set to 3 and gss-tsig, repectively. It
  finds that the key_name 789.client.example.com.server.example.com. is
  listed in its (key_name, context_handle) mapping table.


  IX. Server calls GSS_Accept_sec_context
  To continue security context negotiation server calls
  GSS_Accept_sec_context with the following parameters (Note that some
  INPUT and OUTPUT parameters not critical for this algorithm are not
  described in this example)
   INPUTS
     CONTEXT HANDLE input_context_handle  = context_handle from the
           (789.client.example.com.server.example.com., context_handle)
           entry in the server's mapping table
     OCTET STRING   input_token           = token specified in the Key
           field of TKEY RR (from Additional records Section of
           the client's query)

  The OUTPUTS parameters returned by GSS_Accept_sec_context include
     INTEGER        major_status = GSS_S_COMPLETE
     CONTEXT_HANDLE output_context_handle = context_handle
     OCTET STRING   output_token = NULL




Expires August 28, 2003                                       [Page 18]

INTERNET-DRAFT                   GSS-TSIG             February 28, 2003


  Since major_status = GSS_S_COMPLETE, the security context on the
  server side is established, but the server still needs to respond to
  the client's TKEY query, as described below. The security context
  state is advanced to Context Established.


  X. Server responds to the TKEY query
  Since the major_status = GSS_S_COMPLETE in the last server's call to
  GSS_Accept_sec_context and the output_token is NULL, the server
  responds to the TKEY query placing in the answer section a TKEY record
  that was sent by the client in the Additional records section of the
  client's latest TKEY query. In addition to this server places a
  TSIG record in additional records section of its response. Server
  calls GSS_GetMIC to generate a signature to include it in the TSIG
  record. The server specifies the following GSS_GetMIC INPUT
  parameters:
     CONTEXT HANDLE context_handle = context_handle from the
           (789.client.example.com.server.example.com., context_handle)
           entry in the server's mapping table
     OCTET STRING   message        = outgoing message plus TSIG
                                   variables (as described in [RFC2845])

  The OUTPUTS parameters returned by GSS_GetMIC include
     INTEGER        major_status = GSS_S_COMPLETE
     OCTET STRING   per_msg_token

  Signature field in the TSIG record is set to per_msg_token.


  XI. Client processes token returned by server
  Client receives the TKEY query response from the server. Since the
  major_status was GSS_S_COMPLETE in the last client's call to
  GSS_Init_sec_context, the client verifies that the server's response
  is signed. To validate the signature client calls GSS_VerifyMIC with
  the following parameters:

   INPUTS
     CONTEXT HANDLE context_handle = context_handle for
                  789.client.example.com.server.example.com. key_name
     OCTET STRING   message        = incoming message plus TSIG
                                  variables (as described in [RFC2845])
     OCTET STRING   per_msg_token  = Signature field from TSIG RR
                  included in the server's query response

  Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the
  signature is validated, security negotiation is complete and the
  security context state is advanced to Context Established. These
  client and server will use the established security context to sign
  and validate the signatures when they exchange packets with each
  other until the context expires.



Expires August 28, 2003                                       [Page 19]

INTERNET-DRAFT                   GSS-TSIG             February 28, 2003

7. Security Considerations

This document describes a protocol for DNS security using GSS-API.
The security provided by this protocol is only as effective as the
security provided by the underlying GSS mechanisms.

All the security considerations from RFC2845, RFC2930 and RFC 2743
apply to the protocol described in this document.


8. IANA Considerations

The authors request that the IANA reserve the TSIG Algorithm name
gss-tsig for the use in the Algorithm fields of TKEY and TSIG resource
records. This Algorithm name refers to the algorithm described in this
document. The requirement to have this name registered with IANA is
specified in RFC 2845.


9. Conformance

The GSS API using SPNEGO [RFC2478] provides maximum flexibility to
choose the underlying security mechanisms that enables security context
negotiation. GSS API using SPNEGO [RFC2478] enables client and server to
negotiate and choose such underlying security mechanisms on the fly. To
support such flexibility, DNS clients and servers SHOULD specify SPNEGO
mech_type in their GSS API calls. At the same time, in order to
guarantee interoperability between DNS clients and servers that support
GSS-TSIG it is required that
- DNS servers specify SPNEGO mech_type
- GSS APIs called by DNS client support Kerberos v5
- GSS APIs called by DNS server support SPNEGO [RFC2478] and
  Kerberos v5.

In addition to these, GSS APIs used by DNS client and server MAY also
support other underlying security mechanisms.


10. Acknowledgements

The authors of this document would like to thank the following people
for their contribution to this specification:  Chuck Chan, Mike Swift,
Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake 3rd and Erik
Nordmark.


11. References

[RFC2743] J. Linn, "Generic Security Service Application Program
          Interface, Version 2 , Update 1", RFC 2743, RSA Laboratories,
          January 2000.



Expires August 28, 2003                                       [Page 20]

INTERNET-DRAFT                   GSS-TSIG             February 28, 2003

[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
          "Secret Key Transaction Authentication for DNS (TSIG)",
          RFC 2845, ISC, NAI Labs, Motorola, Nominum, May, 2000,

[RFC2930] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY RR)",
          RFC 2930, Motorola, September 2000.

[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions,"
          RFC 2535, IBM, March 1999.

[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update,"
          RFC 2137, CyberCash, April 1997.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
          STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., "Domain Names - Implementation and
          Specification", STD 13, RFC 1034, November 1987.

[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
          RFC 1964, OpenVision Technologies, June 1996.

[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
          RFC 2025, Bell-Northern Research, October 1996.

[RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API
          Negotiation Mechanism", RFC 2478, Bull, December 1998.

[ISO11578]"Information technology", "Open Systems
          Interconnection", "Remote Procedure Call",
          ISO/IEC 11578:1996, http://www.iso.ch/cate/d2229.html.


12. Author's Addresses

Stuart Kwan                         Praerit Garg
Microsoft Corporation               Microsoft Corporation
One Microsoft Way                   One Microsoft Way
Redmond, WA  98052                  Redmond, WA  98052
USA                                 USA
[e-mail]                 [e-mail]

James Gilroy                        Levon Esibov
Microsoft Corporation               Microsoft Corporation
One Microsoft Way                   One Microsoft Way
Redmond, WA  98052                  Redmond, WA  98052
USA                                 USA
[e-mail]                [e-mail]



Expires August 28, 2003                                       [Page 21]

INTERNET-DRAFT                   GSS-TSIG             February 28, 2003


Randy Hall                          Jeff Westhead
Lucent Technologies                 Microsoft Corporation
400 Lapp Road                       One Microsoft Way
Malvern PA 19355                    Redmond, WA  98052
USA                                 USA
[e-mail]                [e-mail]



Expires August 28, 2003                                       [Page 22]