Subject: Comments on draft-ietf-dnsext-gss-tsig-04.txt

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jan 2002 11:23:51 +0100 (CET)

Here are some comments on the draft. Once we can resolve them, which I think
means an updated I-D, then I can get the IETF wide last call started.

   Erik

---

Change from
	The Secret Key Transaction Signature for DNS (TSIG) [RFC2845] protocol
to  
	Secret Key Transaction Authentication for DNS (TSIG) [RFC2845] protocol
since that is the correct title for TSIG.

In section 3 it says:
>	and servers that support GSS-TSIG it is required that security
Since this is about ensuring interoperability I think the intent
is captured by replaceing /required/REQUIRED/

Section 3.1.1
What is the meaning of abandon the algorithm? Try the next one?
Is there a list of algorithms that the application can choose from?
It makes sense to make this more clear.

Section 3.1.1:
	Note: if the original client call to GSS_Init_sec_context returned any
	major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, then
	the client MUST NOT send TKEY query.
What should the client do instead?

section 3.1.3.1
	of the query.  The response MUST be signed with a TSIG record. The
	signature in the TSIG record MUST be verified using the procedure
	detailed in section 5, Sending and Verifying Signed Messages. If the
	response is not signed, OR if the response is signed but signature is
	invalid, then an attacker has tampered with the message in transit or
	has attempted to send the client a false response. The client MAY
	continue waiting for a response to its last TKEY query until the time
Is the "continue waiting" restricted to the unsigned on invalid signature case?
Or does it apply in the valid signature case as well? If the former it would
make sense to e.g. s/The client MAY/In this case the  client MAY/

section 3.1.3.2
what does "abandon this negotiation sequence" mean?
Where does it continue?

section 4.1.1 doesn't seem to specify what do do when the context
is expired.

------

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: "Levon Esibov" <[email-masked]>
Date: Thu, 31 Jan 2002 12:24:47 -0800

Erik,
Thanks for your feedback!

We updated the draft to clarify the text in all instances you enumerated
in your message. The latest version of the draft is attached. Please let
us know if further clarifications are needed.
 
Clarify for namedroppers: no modifications were made to the GSS-TSIG
algorithm itself. The updates only clarify the text per Erik's comments.

Regards,
Levon.

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2002 2:24 AM
To: [email-masked]
Cc: Stuart Kwan; Praerit Garg; James Gilroy; Levon Esibov;
[email-masked]; Jeff Westhead
Subject: Comments on draft-ietf-dnsext-gss-tsig-04.txt

Here are some comments on the draft. Once we can resolve them, which I
think
means an updated I-D, then I can get the IETF wide last call started.

   Erik

---

Change from
	The Secret Key Transaction Signature for DNS (TSIG) [RFC2845]
protocol
to  
	Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
protocol
since that is the correct title for TSIG.

Section 3.1.1

Section 3.1.1:
	Note: if the original client call to GSS_Init_sec_context
returned any
	major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE,
then
	the client MUST NOT send TKEY query.
What should the client do instead?

section 3.1.3.1
	of the query.  The response MUST be signed with a TSIG record.
The
	signature in the TSIG record MUST be verified using the
procedure
	detailed in section 5, Sending and Verifying Signed Messages. If
the
	response is not signed, OR if the response is signed but
signature is
	invalid, then an attacker has tampered with the message in
transit or
	has attempted to send the client a false response. The client
MAY
	continue waiting for a response to its last TKEY query until the
time
Is the "continue waiting" restricted to the unsigned on invalid
signature case?
Or does it apply in the valid signature case as well? If the former it
would
make sense to e.g. s/The client MAY/In this case the  client MAY/

section 3.1.3.2

------