Re: [HOKEY] WGLC: draft-ietf-hokey-preauth-ps-02

[<Preetida.Vinayakray-Jani at nokia.com>]

Hi Ashutosh:

In line pl. Just responding comment 2.

Thanks
Preeti 

>-----Original Message-----
>From: ext Ashutosh Dutta [mailto:adutta at research.telcordia.com] 
>Sent: 29 March, 2008 13:26
>To: Vinayakray-Jani Preetida (Nokia-NRC/Helsinki)
>Cc: hokey at ietf.org
>Subject: Re: [HOKEY] WGLC: draft-ietf-hokey-preauth-ps-02
>
>Hi Preeti,
>           Thanks for your review and useful feedback. Please 
>see my comments inline marked as AD. If you have any more 
>comments please let us know.
>
>Preetida.Vinayakray-Jani at nokia.com wrote:
>> Hi:
>> 
>> Pl. find following in ref. to subjected draft.
>> 
>> Draft:
>> Section 3: Problem Statement
>> 
>> => Understanding that this is problem statement draft, this section 
>> requires to deliver the subjected goal. Although problem statement 
>> discussion covers e.g. performance issues very specific to 802.11 
>> only, inter-access handover, inter-authetnicator, 
>intra-domain/subnet...etc.
>> 1. A consistent usage of single term like inter-domain or 
>inter-subnet 
>> may provide more clear view of prob. statement
>
>AD. Inter-domain (Inter-administrative domain) handover 
>usually involves inter-subnet handover. We can probably make 
>it clear in the draft.
>
>> 2. Also text reelvant to perfomance issue like handover 
>latency can be 
>> extended more in terms of subjected scope as provided 
>details are more 
>> focused on intra-technology handover. i.e how handover latency in 
>> terms security context feasible in terms of inter-domain or 
>inter-subnet?
>
>AD. Reference MQ7 (e.g., Mobiquitous paper by Rafa et al.) 
>discusses the details of authentication related latency 
>involved during inter-domain handover.
>
>> 3. Categorizing the problem statement with different scenario can 
>> provide direct mapping with usage sceanrios - section 4.
>> 
>> Draft:
>> Section 4...4.1 ..4.2
>> 
>> => 1. It seems the 4.1 scenario simply involves the normal 
>> authentication procedure? In my view there is no pre-authetnication 
>> scenario here, isn't it? If there are some security context 
>> transferred by MN prior to its association with CA then it is of no 
>> use, as CA may not accept such security context without consulting 
>> Home AAA. Then in such case simple authentication procedure will be 
>> followed. Or am I missing something?
>
>AD. Section 4.1 does involve pre-authentication, but it does 
>not take the help of the serving authenticator (SA) and 
>directly talks to the candidate authenticator (CA), since MN 
>has the knowledge of CA. However the mobile does it before it 
>hands over to the new network.
>
>> 
>> 2. In indirect pre-autnetication, it is asusmed that there will be
>> pre-exisitng trust between SA and CA. To me this scenario is 
>analogus to
>> fast handover in MIP, with proxy-solicitation msg. However 
>keeping MIP
>> aside, even if MN receives IP level details of CA through SA, the
>> performed pre-authentication can be partial as MN still needs to
>> associate CA first before using IP level security. Any comments?   
>
>AD. The draft does not make any assumption regarding 
>pre-established  SA 
>between SA and CA, as SA (Serving Authenticator) acts like a proxy and 
>forwards the packets to CA (Candidate Authenticator). MN does not 
>directly communicate with CA, but SA does communicate with CA 
>in case of 
>indirect pre-authentication. So the role of CA and SA are little 
>different than PAR and NAR that you have mentioned for FMIPv6.
>
>I do not understand quite well about the partial pre-authentication of 
>MN. Could you please clarify it little more?
>

[Preeti] Parital authentication -> In above scenrio, Preauthentication
involves direct IP level communication between SA and CA, Although
resulted pre-authentication is for MN, it does not include MN's layer 2
authentication. Hence it is partial. If layer 2 authentication fails
then success of layer 3 may not bring any value or underutilization of
reserved resources. 

Just for clarification of PAR and NAR. I mean to say analogus here as
proxy solicitation message carried betw. PAR and NAR, nothing else. 

>> Draft:
>> Section 5... 5.1.....5.2
>> 
>> =>Authenticator discovery protocols will different from any 
>secure DNA?
>> If MN is directly involved with pre-authentication then it may be, if
>> not then SA may act as proxy node for such discovery 
>protcol? Any views?
>
>AD. In case of direct authentication, candidate authenticator (CA) 
>discovery can be done at a more granular level using discovery 
>mechanism 
>such as IEEE 802.21 IS (Information Service).
>
>> In context binding, 2nd para - First apporach (1st four lines) are
>> relevant to indirect binding isn't it? 
>
>AD. It could be applied to both types of authentication.
>
>> Thanks
>> Preeti
>
>
>Regards
>Ashutosh
>>  
>> _______________________________________________
>> HOKEY mailing list
>> HOKEY at ietf.org
>> https://www.ietf.org/mailman/listinfo/hokey
>
_______________________________________________
HOKEY mailing list
HOKEY at ietf.org
https://www.ietf.org/mailman/listinfo/hokey