Subject: RE: [Ecrit] Comments/Questions on draft-ietf-ecrit-03

From: "Reese, Theresa E" <[email-masked]>
Date: Thu, 8 Feb 2007 08:37:08 -0500

Hannes -

Responses to your questions.

Terry

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, February 07, 2007 4:16 PM
To: Reese, Theresa E
Cc: [email-masked]; Henning Schulzrinne
Subject: Re: [Ecrit] Comments/Questions on draft-ietf-ecrit-03

>   
>I understood your scenario. There are two more questions:

>* What type of security protocol for authentication do you envision?
>Currently, we talk about TLS usage in the LoST document.
>Hence, I assume that you would use some TLS ciphersuite, such as  TLS 
>with pre-shared  secrets,  to authenticate the client to the server.

Yes, I assume that TLS would be used, and that the TLS mechanisms would
be used to authenticate the client to the server.

>* If authentication in TLS fails then you are not really able to send 
>any LoST message. Hence, you cannot return an error in the LoST 
>protocols to say that authentication did not work. Are there cases
where 
>you authenticate a client successfully but then you decide to reject
him?
You raise a good point.  If the client (i.e., ESRP) fails to
authenticate itself, then the connection will not be established in the
first place, so it cannot send messages to the ECRF. Thus, no LoST error
message specifying that the client was not authorized to receive the
requested information is necessary.  

Thank you for the clarification.

Terry

> Ciao
> Hannes

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

---

From: "Reese, Theresa E" <[email-masked]>
Date: Thu, 8 Feb 2007 08:38:35 -0500

Hi Hannes -

Yes, I agree.

Terry

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, February 07, 2007 4:17 PM
To: Reese, Theresa E
Cc: Henning Schulzrinne; [email-masked]
Subject: Re: [Ecrit] Comments/Questions on draft-ietf-ecrit-03

Hi Terry,

Reese, Theresa E wrote:
> Henning -
>
> One additional comment regarding the optional return of displayName
and
> serviceNumber in a LoST <findServiceResponse> - -
>
> It may be that the return of such information may be useful to some
> types of clients and not to others who are accessing the SAME service.
> For example, a serviceNumber will not be useful to an ESRP, but may be
> useful information for end user equipment (where both types of clients
> are accessing the same service).  Doesn't this imply that a choice
must
> be made by the server about whether or not to return the information?
>
>   
The LoST server could make such a differentiation given the information 
it has. You mentioned that the ESRP has to authenticate to the LoST 
server and the end host hopefully doesn't need todo that. To me that 
sounds like an easy way to differentiate.
Even if the LoST server sends the two elements always it does not hurt 
-- I doubt that the bandwidth between the ESRP and the LoST server will 
be  limited.

Ciao
Hannes

> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Wednesday, February 07, 2007 1:32 PM
> To: Reese, Theresa E
> Cc: [email-masked]
>> [TER]  As I indicated in my original e-mail, Section 7.4.2 of lost-03
>> states that the server MUST include validation information in the
>> response if the 'validateLocation' attribute in the request is set to
>> "true."  If the absence of such information in the response is
>> considered an abnormal condition, then a warning seems  
>> appropriate.  If
>> the absence of such information in the response is NOT considered
>> abnormal, then perhaps the text in Section 7.4.2 should be changed  
>> from
>> "MUST" to "MAY".
>>     
>
> I agree that this needs to be clarified. I think it should be  
> something like
>
> "SHOULD return, unless the server does not support validation for  
> that particular address"
>
> or something along those lines.
>
>
>
>
>   
>> [TER] So are you suggesting that it will be up to the LoST server to
>> determine whether serviceNumber and displayName will be returned,  
>> based
>> on local policy?
>>
>>     
>
> I wouldn't call it "local policy" since this implies a choice, so  
> it's rather more like "available data". Some mappings for some  
> services just may not have a meaningful displayName or service number.
>
>
>   
>> [TER] As Hannes suggested, these are really two different cases.   
>> In the
>> case of the unauthenticated user, no information would be returned,
so
>> an error indication would be appropriate, based on the text in the  
>> first
>> paragraph of Section 12.  If partial information is returned, the
text
>> in the first paragraph of Section 12 says that a <warnings> element
>> should be returned as part another response element, if the LoST  
>> server
>> was able to respond in part, but the response was not what the client
>> desired.
>>     
>
> As I mentioned before, I don't see the need for a warning, as it just

> adds another variation that client code needs to handle. The only  
> reason to distinguish between "not available" and "not available to  
> you" is if adding credentials makes a difference. However, with HTTP  
> Digest, that doesn't work, since you can't easily say "challenge  
> me!" (and with Basic, it probably doesn't work, either, due to realm  
> issues).
>
> Henning
>