[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of
> Sent: Friday, January 04, 2008 12:11 AM
> To: email@example.com
> Cc: firstname.lastname@example.org
> Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
> >When the peer, the local domain and the AAA-Home also
> support ERP, a
> >DSRK (DSRK1) may be requested by the local ER server A at
> the time of
> >the EAP exchange.
> Some questions:
> 1. Is the "Local ER server" always a RADIUS client?
Yes, it is both a client and a server. It is a client from the
perspective that it requests for the key material from a RADIUS server
and a server from the perspective that it will later serve NASs during
> ERX document
> seems to
> indicate that this might not always be the case.
Could you please point out where? I just scanned the ERX document and
except for describing a specific security consideration with the use of
RADIUS, the document only seems to have pointers to the RADIUS and
Diameter documents. Perhaps I missed it.
> 2. How is the request for the DSRK made by the "local ER
> server"? Is the
> request authenticated with user credentials? How does the
> RADIUS server determine if the Request is valid?
The request for DSRK is made with a RADIUS attribute or Diameter AVP in
an ERP bootstrapping exchange initiated by the peer or the first EAP
Response message coming from the peer in a regular EAP exchange. The
EAP or ERP exchange authenticates the peer and upon successful
authentication, a DSRK is included along with ER Finish or EAP Success
for the local ER server. This is not much unlike providing the MSK to
the NAS, except that there is no explicit request for an MSK.
> 3. How does the RADIUS server know how to reach the "Local ER server"?
> The ERX document talks about a "Domain Identity". How does
> the RADIUS server use the "Domain Identity" to determine what
> RADIUS client to send a packet to?
> Is there an assumption that the "Local ER server" is one hop
> away from the home RADIUS server? What attributes need to be
> placed within an Access-Accept to ensure that the packet is
> routed to the "local server"?
The local ER server must be in the path of the full EAP exchange or the
ERP bootstrapping exchange of the peer in order to request and receive a
DSRK. This text was present in draft-gaonkar-radext-erp-attrs-01 and I
notice that it is missing in 02. We will fix that. The packet is
routed just using regular AAA routing - the requesting entity's identity
is part of the attribute defined, which will provide an FQDN or IP
address of the local ER server requesting the key - this is present in
the Access-Accept as well. The local ER server that requested the DSRK
will look for this attribute in the Access-Accept.
> 4. In Figure 1, the ERX document shows the following flow:
> [<-- EAP-Request/ ------
> [<-- EAP Initiate/ ------
> Is this a typo? The figure shows that the
> EAP-Request/Identity isn't being responded to by the peer.
> If the peer implements RFC 3748, won't it send an
> EAP-Response, which will be passed to the RADIUS server,
> which will then initiate EAP?
The idea behind sending both EAP-Request/Identity and
EAP-Initiate/Reauth-Start is that the network can initiate regular EAP
or re-authentication when it wants. A peer that supports ERX and
possesses a valid EMSK should respond only to the
EAP-Initiate/Reauth-Start. The EAP process may timeout or the
authenticator, upon receiving the EAP-Initiate/Reauth-Start may
> Figure 1
> seems to show the EAP peer ignoring the EAP-Request, which
> implies that it needs to wait for some period of time for
> another message, which
> might or might not arrive. How long should it wait?
Not sure why the peer would wait.. It sees that the authenticator
supports ERX and knows that it possesses a valid EMSK - so, it just
proceeds with the ERP exchange.
> If the peer doesn't respond to the EAP-Request/Identity,
> according to RFC
> and RFC 4137, the NAS will retransmit. So we'll have two EAP
> conversations going on at once?
As I note above, the authenticator may retransmit the
EAP-Request/Identity, in which case it will timeout or it may terminate
EAP when it receives the EAP-Initiate/Reauth-Start. A smart
implementation should do the latter. Even upon retransmission of the
EAP-Request/Identity, there isn't really an issue, since, the identifier
for EAP-Initiate is picked by the peer. Hence, the EAP code (Initiate),
along with the identifier value, will distinguish this exchange from an
EAP-Request transmitted by the authenticator.
> 5. In Figure 2, the peer is initiating what would appear to
> be a standard
> RADIUS/EAP conversation via the EAP-Response/Identity. However, it
> would appear that the EAP Response/Identity is being
> "augmented" by the local server. It's hard for me to tell
> from the figure whether the [DSRK Req, Domain Identity] is
> being inserted within the EAP-Response/Identity, or whether
> it represents separate RADIUS attributes. Can you clarify?
It represents separate RADIUS attributes.
> 6. If the "local 'server" isn't on the path between the NAS
> and the home server
> (as it might not be, because of failover), what happens?
> Does each proxy
> also need to host a "local server" to make sure that doesn't occur?
> If the "local server" is not on the path, then it seems like
> two distinct messages
> would be required. Is there an expectation that the RADIUS
> will be multicast, or that two distinct RADIUS Access-Accept
> packets will be sent?
As written, the protocol only supports the case where the local ER
server is in the path between the NAS and home server. There was some
interest in later supporting the case where it is not in the path, but
there is no proposal to support that option now.
> to unsubscribe send a message to
> email@example.com with the word 'unsubscribe' in
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.