Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17

[Victor Fajardo <vfajardo at tari.toshiba.com>]

Hi Qin,

Thanks for the review.

> Hi,
> May I have some comments on draft-ietf-dime-rfc3588bis-17?
>
> Regards!
> -Qin
> [snip]
> "
> 1.  Introduction
> .............
> Server-initiated messages
>
> While RADIUS server-initiated messages are defined in [RFC5176],
> support is optional.  This makes it difficult to implement
> features such as unsolicited disconnect or reauthentication/
> reauthorization 
> "
>  [Qin] Reauthentication/reauthoriation is not necessary to be server-initiated?
>   


>   e.g., In RFC5296"EAP Extensions for EAP Re-authentication Protocol (ERP)
>    ", EAP Re-authentication is host/peer initiated, isn't it?
>    So it is not very accurate to say the reauthentcation is server-initiated .
>
> "
>   

mmm ... the statement above is just giving an example of 
server-initiated messages. i don't think it stating that re-authz are 
server-initiated only.


>  on demand across a heterogeneous deployment.
>  Support for server-initiated messages is mandatory in
> "    
> [Qin]: The last sentence is not complete. I guess we should say 
>   "
> To tackle this issue, support for server-initiated message is mandaroty in Diameter.
>    "
>   

Ok.

> [snip]
> "
> Peer discovery and configuration
>
> RADIUS implementations typically require that the name or address
> of servers or clients be manually configured, along with the
> corresponding shared secrets.  This results in a large
> administrative burden, and creates the temptation to reuse the
> RADIUS shared secret, which can result in major security
> vulnerabilities if the Request Authenticator is not globally and
> temporally unique as required in [RFC2865].  Through DNS, Diameter
> enables dynamic discovery of peers. 
> "
>
> [Qin]: In order to align the contents in this paragraph with other paragraphs, the similar anchor point should be appended, i.e., 
>       s/
>       "
>       Diameter enables dynamic discovery of peers. 
>       "
>       /
>       "
>       Diameter enables dynamic discovery of peers (section 5.2).
>       "
>   

Ok.

> [snip]
> "
> 1.1.1.  Description of the Document Set
> [snip]
> "
>    The Mobile IPv4 [RFC4004] application defines a Diameter application
>    that allows a Diameter server to perform AAA functions for Mobile
>    IPv4 services to a mobile node.
> "
>    [Qin]: Do we need to add some references to Diameter support for Mobile IPv6 
>     and Diameter support for Proxy Mobile IPv6? 
>   

In reference to Glen's comments, I actually would like to trim down this 
section so that it does not refer to any diameter applications. There 
are and will be very many diameter applications and I don't think it's 
useful to iterate them. I think its best just to describe a general 
relationship of diameter to the transport profile.

> [snip]
> "
> 2.9.  Diameter Path Authorization
>
>    As noted in Section 2.2, Diameter provides transmission level
>    security for each connection using TLS.  Therefore, each connection
>    can be authenticated, replay and integrity protected.
> "
>    [Qin]: In which situation the Diameter Path Authorization will be used?
>    Diameter Path Authoirzation will be performed between the Diameter Client and server?
>    or between different Proxys or Relays? What is the main difference between Path authorization and service authorization?
> "
>   

path authorization can be performed between any diameter peers (clients, 
servers, proxy/relay) to verify if they can do what they claim to do; 
i.e. through authorization cerficates. so path authorization can also 
deal with validating the application a diameter node supports and 
possibly its role for that application. AFAIK, service authorization is 
a concept used within the diameter application itself and is independent 
of path authorization.

>    In addition to authenticating each connection, each connection as
>    well as the entire session MUST also be authorized.  Before
>    initiating a connection, a Diameter Peer MUST check that its peers
>    are authorized to act in their roles.  For example, a Diameter peer
>    may be authentic, but that does not mean that it is authorized to act
>    as a Diameter Server advertising a set of Diameter applications.
>
>    Prior to bringing up a connection, authorization checks are performed
>    at each connection along the path.  Diameter capabilities negotiation
>    (CER/CEA) also MUST be carried out, in order to determine what
>    Diameter applications are supported by each peer. 
> "
>
>  [Qin]: What's the relationship between capabilities negotiation and Path Authorization?
>  Why we mention capability negotation in this section?
>   
see above.

we mention it here because the capabilities exchange tells you the 
applications a peer support and the part of the path authorization helps 
you verify whether the peer can really do what it claim to do; i.e. 
through authorization certificates.

> [snip]
> "
> 8.  Diameter User Sessions
> [snip]
> "
>    An access device that does not expect to send a re-authorization or a
>    session termination request to the server MAY include the Auth-
>    Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint
>    to the server.  
> "
>  [Qin] 
> What does the re-authorization means here? What's the difference between re-authorization and re-authentication? 
>   

In this case, re-authorization is tied to a session. if a user is not 
expected to ask for re-authorization, then the server may not need to 
keep state. re-authorization and re-authentication are two(2) different 
concepts ... one deals with policing and the other deals with proving 
your identity again.

>  [Qin] 
> Why does the server  not maintain the state for Diameter User session  in some situation mentioned above?
>   

see above.


> [snip]
> "
> 8.3.  Server-Initiated Re-Auth
>
>    A Diameter server may initiate a re-authentication and/or re-
>    authorization service for a particular session by issuing a Re-Auth-
>    Request (RAR).
> "
> [Qin] Can you provide some reference as regarding this mechanism?
>   

I'm guessing diameter credit-control has server-initiated RAR ...

> "
>    For example, for pre-paid services, the Diameter server that
>    originally authorized a session may need some confirmation that the
>    user is still using the services.
> "
> [Qin] If the security information(e.g., keys) is expired, do we need to depend on
>  Server-Initiated Re-auth to renew the security information? In this case, it seems
>  that the Client also can initiate this Re-auth?
>   

Yes the client can perform re-auth in this scenario. The base protocol 
does not limit what the diameter applications can do. it simply provides 
a framework for it.


> "
>    An access device that receives a RAR message with Session-Id equal to
>    a currently active session MUST initiate a re-auth towards the user,
>    if the service supports this particular feature.  Each Diameter
>    application MUST state whether service-initiated re-auth is
> "
>    [Qin]: s/service-initiated/server-initiated
> "
>    supported, since some applications do not allow access devices to
>    prompt the user for re-auth.
> "
>   

Ok.

regards,
victor