Subject: Re: [midcom] STUN 05 - clarification

From: "Panayiotis A. Thermos" <[email-masked]>
Date: Mon, 13 Jan 2003 14:13:48 -0500

Jonathan thanks for the reply,
see more comments below:

                    Jonathan                                                                                 
                    Rosenberg              To:     "Panayiotis A. Thermos" <[email-masked]>          
                    <jdrosen@dynami        cc:     [email-masked], (bcc: Panayiotis A. Thermos/Telcordia)   
                    csoft.com>             Subject:     Re: [midcom] STUN 05 - clarification                 
                                                                                                             
                    01/11/2003                                                                               
                    10:53 PM                                                                                 

inline.

Panayiotis A. Thermos wrote:
>> greetings,
>>
>> can someone clarify the following sentence in draft-ietf-midcom-stun-05?
>>
>> Section 8.1, page 14  the paragraph before the last paragraph:
>>
>> "If the username present in the request was not allocated using a Shared
>> Secret Request, the REFLECTED-FROM attribute MUST contain the
>> source address and port of the entity which obtained the username,
>> as best can be verified with the mechanism used to allocate the
username."
>>
>> How we can assert which entity obtained the username?

>It depends on the mechanism used to allocate them. For example, if its
>kerberos, then the IP address of the entity to which the ticket was
>granted will suffice.

Does this mean that the STUN server has to contact another entity that has
issued the user credentials to verify their validity?

If so, which of the following assumptions stand?
     a) The STUN server will establish an out of band channel of
communication
                      with the component managing the user credentials
(e.g. LDAP request).
     b) The STUN server and the  component for managing the user
credentials
                      are co-located.
     c) How will the STUN server obtain the external entity's IP
address/port?
                     Do we assume that this is a local
configuration/implementation preference?
     d) all of the above or a combination ( :-)  for completeness)

>> Can someone give an example?

>See above.

>>
>> What does it mean "as best can be verified with the mechanism used to
>> allocate the username"?

>Presumably, the mechanism has a way to verify that the username request
>is not coming from a spoofed IP address. An "anonymous" challenge, which
>requires the client to reflect a nonce handed it by the server, can be
>used to verify the return routability. That is, the client whose source
>IP was X in the request is capable of receiving IP packets sent to that
>IP address.

>>
>> If the username was not assigned by the respective STUN server that
handles
>> the request how it can verify the username (besides performing another
>> message
>> exchange with another STUN  server which presumably assigned the
username,
>> which may require additional authentication )?

>This was just leaving a hook for other mechanisms to be used.
understood

perhaps a brief example can help the reader/developer clarify what the
author's
intentions are here.

>-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 15 Jan 2003 05:49:29 -0500

inline.

>      d) all of the above or a combination ( :-)  for completeness)

None of this is specified. The text you are worrying about is merely a 
hook for other things. The above questions would all need to be answered 
in the context of a specific mechanism. There are no currently proposed 
alternatives, so I cannot provide any details.

-Jonathan R.