Re: [radext] Last call comments on draft-ietf-radext-fragmentation-02

[Alejandro Perez Mendez <[e-mail]>]

El 07/02/14 18:29, Jim Schaad escribió:
>
> *From:*Alejandro Perez Mendez [mailto:[e-mail]]
> *Sent:* Friday, February 07, 2014 12:45 AM
> *To:* Jim Schaad; [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: Last call comments on draft-ietf-radext-fragmentation-02
>
> Hi Jim,
>
> thanks for the valuable comments. See my responses inline:
>
> El 07/02/14 01:42, Jim Schaad escribió:
>
>     In general, yes I believe this document is in good shape and ready to go
>
>     forward.  There are a couple of small things that need to
>
>       
>
>       
>
>     1.  !!! Pet Peeve !!! - I would request that the authors please review the
>
>     use of 2119 language.  There are places where, IMHO, it is used incorrectly.
>
>     Examples are:
>
>   
>         (section 2) Instead, the CoA client MUST send a CoA-Request packet
> containing session identification attributes, along with Service-Type =
> Additional-Authorization, and a State attribute.      ---- I don't think
> this is part of the fragmentation protocol
>
>
> Take into account that Service-Type = Additional-Authorization is a 
> new value defined in this document.
>
> [JLS] Then I have a confusion about why this needs to be done. It says 
> that there is no need to fragment CoA packets, so why is there a need 
> to do this?  This may be due the fact that I don’t really understand 
> what CoA is doing – so I am willing to say this is reader 
> misunderstanding and you can ignore it.
>
>
>
>   
> 5. Next paragraph - does it really need to be globally unique?  Is it
> sufficient to be unique to either the server or the server/NAS pair?  The
> problem with the phrase "globally and temporally unique" is that says to me
> that it can never be re-used ever in the history of the world by anybody and
> I don't think that is what is implied here.
>
>
> Note that it says globally and temporally unique. That "temporally" 
> addition would allow others to use the same value after/before a 
> reasonable amount of time.
> Anyway, I think it would be sufficient to be temporally unique to the 
> server, as it is the one using it to recognise the conversation. The 
> NAS just copies the value into the next Access-Request packet, without 
> further processing.
>
> To avoid confusion, I think it could be rephrased as:
>
> We only note that it MUST be temporally unique to the server.
>
> [JLS] Yes – I think this is probably a sufficient degree of uniqueness.
>
>       
>
>       
>
>   
> 7. Section 7.1 - I may have a slight misunderstanding here (and it may not
> be worth changing the document for this in any case).  However, I believe
> that a proxy can remove all previous proxy-state information and just insert
> its own into a packet.  Thus it is possible that the server does not know
> how many bytes to allow for proxy state as not all of the attributes will be
> sent to the server.  (I just found that this is discussed in step #2 of this
> section, which makes me less inclined to include in the general discussion
> but still unsure.)
>
>
> Proxies can do anything they want, even completely change the whole 
> packet removing the existing attributes and inserting new ones. From 
> this assumption, the NAS and the AS can only wish proxies will behave 
> according to some conventions. Anyway, this discovery mechanism is a 
> best effort. That's why step #2 specifies to artificially increase the 
> amount of free space.
>
> [JLS] – I can easily live with no change for this.
>
>   
>   
>   
>   
> 11.  Did I miss where you defined the T bit - or did you?
>
>
> Page 7, first paragraph says:
>
> We address this issue
>    by defining a new field in the Reserved field of the "Long Extended
>    Type" attribute format.  This field is one bit in size, and is called
>    "T" for Truncation.
>
> That is, the T flag belongs to a different specification: RFC 6929. 
> Perhaps we should add a reference. s/attribute format/attribute format 
> [RFC6929]/
>
> [JLS]  The following text is in your document
>
> We address this issue
>
>    by defining a new field in the Reserved field of the "Long Extended
>
>    Type" attribute format. This field is one bit in size, and is called
>
>    "T" for Truncation.
>
>
> This says you need to have a section to define it and mark your 
> document as updating RFC 6929.
>
>   

Seems reasonable. I'll do it.

>   
> 12.  This may just be me, but I have a problem with the terms
> "pre-authorization" and "post-authorization".   My issue with the terms is
> that there are three cases where I see things happening:
>   
>         a) Before doing the authentication (NAS->server)
>         b) Post doing the authentication (NAS->Server)
>         c) "post" doing the authentication (Server->NAS as part of the
> access-accept process).
>   
>         However the document currently says that c is post-authorization but
> b is not covered in section 12.
>
>
> Personally, I don't see your case b) as a plausible case (I may be 
> wrong). Note that the NAS does not distinguish "after authentication" 
> until it receives the Access-Accept packet, and that would be c) already.
>
> If your concern is more related to the naming itself, maybe these 
> phases/steps should be renamed to "pre-authentication" and 
> "post-authentication". I have thought on changing them sometimes in 
> the past.
>
> [JLS] This is something that Plasma is looking at for a standard 
> model.  We are going to be using ABFAB and doing the following steps:
>
> 1. Do a pre-authentication by sending a policy to the server  as part 
> of the initial Access-Request step
>
> 2.Do a post-authentication by sending a SAML request to the server to 
> get various attributes that we need in order to do the policy 
> evaluation to grant access to a resource.
>
> By doing this as two operations rather than one, we can restrict the 
> amount of items that we ask for, i.e. by not asking for things that 
> are not applicable to the person that is authorized.  This increases 
> the privacy and reduces the chances that the server would see us as 
> trying to just get tons of attributes.
>
> We are looking at doing this by sending another Access-Request with a 
> state from the previous Access-Request in order to tie together the 
> two sessions. Since this dialog would not need to do an authentication 
> (tied from the previous dialog) it still is a post-authentication 
> dialog, but is NAS initiated again.
>
>
>

 From my view, in that case you'd be doing a pre-authorization phase 
(policies), then authentication (EAP), then a post-authorization where 
the AS is not sending any authorization information (EAP-Succes), but it 
will include a State attribute to allow the NAS to start a new 
pre-authorization exchange afterwards (SAML request), ending with 
another post-authorization (SAML response).

>   
>   
> 13.  Should the Access-Request (ID=181)
>   
> 14.  In the last paragraph on page 15, you are putting in a state attribute
> where one did not exist in the original request.  It is not clear to me why
> this is happening just because this is the fragmentation protocol.  It would
> seem to me that this is something that should be done in general for all
> access-accept messages, whether or not it is going to be fragmented.
>
>
> I guess you mean page 14. It is stated that "The AS includes an State
>    attribute to allow the client to send additional authorization data."
>
> We added this text because we wanted the AS to provide the NAS with 
> the means to continue with the authorization exchange (e.g. further 
> requests). Now that you brought up, I think that it  should probably 
> be out of the fragmentation protocol. Perhaps it should be a 
> recommendation for ASs to include a State attribute on all their 
> Access-Accept, as a way to allow NASs to continue with the conversation.
>
> [JLS] No I meant the last pargraph on page 15.  I was looking at the text
>
> The AS includes an State
>
>    attribute to allow the client to send additional authorization data.
>
> This is where the final chunk is being constructed.
>
> However – yes I would like a recommendation that a state attribute be 
> included in all Access-Accept messages where “post-authorization” in 
> terms of what I laid out above is going to be possible.
>

I agree.

>
>
>   
>   
> 15.  Section 5 - I don't know if there is a reason to discuss packing based
> on the re-ordering of attributes which have disparate types in order to pack
> the chunk tighter.
>
>
> I'm not sure that would be worthy. That would require to execute an 
> optimization algorithm just to gain some bytes.
>
> [JLS] – No problems – I would have stated it in terms of – you can do 
> this but it is not worth the effort.
>
>   
>   
> 16. Section 8.1 - It might be worthwhile to repeat that implementations
> SHOULD send this attribute in the an Access-Request with the value of
> Fragmentation-Supported if fragmentation is not going to happen.
>
>
> I guess we could provide a one-line explanation of each value for 
> "code" field.
>
> [JLS] No that is not what I was asking for.  I was looking for a 
> restatement of the following text from section 4.2
>
> Client supporting this specification MUST include a Frag-Status =
>
>    Fragmentation-Supported attribute in the first Access-Request sent to
>
>    the server, in order to indicate they would accept fragmented data
>
>    from the sever.  This is not required if pre-authorization process
>
>    was carried out, as it is implicit.
>
>   

Seems reasonable.

Regards,
Alejandro
>
>
> Thanks and best regards,
> Alejandro
>
>
>
>
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext