Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-radius-opt-05.txt

From: "Leaf Yeh" <[email-masked]>
Date: Sun, 3 Feb 2013 23:57:57 +0800

>> Appreciate your carefulness. I tend not to touch the word of 
>> 'stateful', but could make the clarification after Fig. 2 in section 
>> 3 as follows: 'If the authentication or the authorization through 
>> RADIUS passes, the NAS MUST store the RADIUS attributes received in 
>> the Access-Accept message from the RADIUS server during the whole 
>> session.' I regard this is the part of the RADIUS protocol.
Tomek - Ok. You may add that radius state and exact retention policy is 
> outside of this document and just reference whatever document governs 
> NAS behavior.
> Section 1.2 of RFC2865 has the definition of 'session', but it seems 
> difficult to find the exact words on 'radius state' or 'retention 
> policy' in this RFC.
Tomek - Ok. So I think just saying that "how NAS manages the state is
outside of scope of this document" would be ok.

I will change the above text in section 3 to be: 

  ' If the authentication or the authorization
   through RADIUS passes, the NAS MUST store the information indicated
   in the RADIUS attributes received in the Access-Accept message from
   the RADIUS server during the whole session.  How the NAS manages
   these information during the RADIUS session is out of the scope of
   this document. '

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tomek Mrugalski
Sent: Friday, December 14, 2012 8:41 PM
To: Leaf yeh
Cc: [email-masked]
Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-radius-opt-05.txt

On 14.12.2012 08:59, Leaf yeh wrote:
>> Appreciate your carefulness. I tend not to touch the word of 
>> 'stateful', but could make the clarification after Fig. 2 in section 
>> 3 as follows: 'If the authentication or the authorization through 
>> RADIUS passes, the NAS MUST store the RADIUS attributes received in 
>> the Access-Accept message from the RADIUS server during the whole 
>> session.' I regard this is the part of the RADIUS protocol.
> Ok. You may add that radius state and exact retention policy is 
> outside of this document and just reference whatever document governs 
> NAS behavior.
> 
> Section 1.2 of RFC2865 has the definition of 'session', but it seems 
> difficult to find the exact words on 'radius state' or 'retention 
> policy' in this RFC.
Ok. So I think just saying that "how NAS manages the state is outside of
scope of this document" would be ok.

>> In your example, the NAS gets the 'special prefix' in the attribute 
>> of Delegated-IPv6-Prefix (123) from the RADIUS server.
>> Then the relay only need to convey the Delegated-IPv6-Prefix (123) to 
>> the server. I meant the relay don't need to convey 'User-Name (1)' 
>> through this option to the server, if it is regarded only for the 
>> RADIUS server.
> Tomek - You are thinking about your use cases. It's not about prefixes 
> and addresses only. What if I want someone with special Radius 
> user-name to get a different set of other DHCP options, special 
> personal dns server for my boss, dedicated NTP server for engineers in 
> lab etc? I'd like it to be a generic Radius option that happens to 
> solve your cases, but is flexible enough to cover others as well.
> 
> I tend to keep the scope of the draft for the use cases defined, and 
> still can't get the border of your question on the real use case yet.
Since nobody else joined the discussion, I suppose there's not much desire
for other cases. Keep the text as it is then.

> As the appearance of the OPTION_RADIUS, how about the following text:
> ' According to the network scenarios described in section 3, the 
> OPTION_RADIUS SHOULD appear in the RELAY-FORW (12) message relaying 
> SOLICIT (1), REQUEST (3) and REBIND (6) from the DHCPv6 client, and 
> MAY appear in the RELAY-FORW (12) relaying any other message from the
> DHCPv6 client. ' ?
Sounds good. I'm not sure if you meant REBIND or RENEW, but I'm fine with
both.

> Tomek - Existing text is ok, but it is not sufficient and it talks 
> about different circumstances (what to do when someone tries to add a 
> new option to the registry). I'm talking about potential security 
> problems once the protocol is deployed. How about this one: "Networks 
> that deploy this mechanism may allow new attack vector against DHCPv6 
> servers in case DHCPv6 relay is compromised. By forging Radius options 
> in relayed messages, the attacker can influence DHCPv6 server 
> assignment policy.". In simple words, if your Radius authentication is 
> completely secure and bullet proof, someone still can hijack your 
> relay and just include options that say "yeah, this user has 
> authentication, honest!" and the server will happily provision an 
> unathenticated device.
> 
> I would adopt the above text for 'Security Consideration' if you 
> insist. How about the text to be: 'The mechanism described in this 
> document may introduce new attack vector against the DHCPv6 server in 
> case the DHCPv6 relay agent is compromised. By forging the RADIUS 
> attributes contained in the OPTION_RADIUS of the RELAY-FORW (12) 
> messages, the attacker may influence the parameter assignment on the
> DHCPv6 server for the DHCPv6 clients. But in the network scenarios 
> described in the section 3, NAS could always be regarded as a trusted 
> network component in the real deployment. ' ?
I don't have any experience with NAS, but my understanding is that if
someone manages to hijack your NAS you have bigger problems than just
influencing your DHCP server. But since this draft is about DHCP, it is
useful to mention that. Your proposed text is ok.

Ok, this addresses all my comments. Thank you.

Cheers,
Tomek
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg