Subject: Re: [midcom] Last call reminder

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Aug 2002 05:21:31 -0400

[resending as I think this was lost due to ietf.org mail outage]

I thought I had responded to this a month back, but searching through
the archives found nothing. Turns out I had half responded, and left the
unsent mail in my drafts folder. Sorry about that....

Thanks for your comments. Responses inline.

Pete Cordell wrote:
  > Here's some editorial errors I found when skimming through STUN.  (I'm
  > afraid I didn't give it a thorough read.)
  >
  > 8.1 (Clarity): If the STUN Shared Secret
  >    Request was used, the key MUST be the {one placed}->{TARGET-OTP}
  >    in a Shared Secret
  >    Response to a Shared Secret Request that had a TARGET-TID equal to
  >    the transaction identifier in the Binding Request.
  >
  > It would be nice to re-word this paragraph, but I've tried and it's
  > difficult!  Best I could do is below, but its not much of an
  > improvement.
  >
  >    If the STUN Shared Secret
  >    Request was used, the key MUST be the TARGET-OTP from the Shared
  >    Secret response corresponding to a
  >    to a Shared Secret Request containing a TARGET-TID equal to
  >    the transaction identifier of the Binding Request.

A bit better. I'll use that.

  >
  > 8.2 (Typo): SHOULD {prevent} -> {present} a site certificate ?

Fixed.

  >
  > 8.2 (Functional): 'The server MUST always return the same TARGET-OTP for
  > two
  >    requests with the same TARGET-TID.'
  >
  >    This sounds like a way that an attacker can learn the TARGET-OTP
  >    corresponding to a TARGET-TID.  This could be useful in an attack.
  >    Also, stated as is, it does not allow the server to change the key
  > generation
  >    mechanism (say a master secret) from one month to the next.

As we concluded on the list, the server now supplies a username and a
target OTP. Thus, this issue is moot.

  >
  >
  > 11.2.6 (Typo): TARGET-TID: Re: 'This MUST be equal to the transaction ID
  > that will
  >    be used in Binding Requests that contain the shared secret learned
  > from
  > the
  >    exchange.'  This doesn't seem right.  Maybe it should be:
  >
  >    This MUST be
  >    equal to the transaction ID that will be used in Binding Requests
  >    that {contain}->{are authenticated by} the shared secret learned from
  > the
  > exchange.

This too is moot with the username parameter.

  >
  >
  >
  > (General (Clarity): Still think CHANGED-ADDRESS should be CHANGE-ADDRESS
  > to
  > ties in more closely with the text 'The fourth attribute is the
  > CHANGE(D)-ADDRESS attribute. It is present in Binding Responses. It
  > informs
  > the client of the source IP address and port that would be used if the
  > client requested the "change IP" and "change port" behavior.'.

I think its fine, since CHANGED-ADDRESS is a noun, where as
CHANGE-ADDRESS is a verb. Since we are talking about an address, which
is a noun, the current wording seems fine to me.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom