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

From: "Jim Schaad" <[email-masked]>
Date: Thu, 6 Feb 2014 16:42:12 -0800

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 1) Nevertheless, if a proxy supports this specification, it
MAY re-assemble the data in order to either examine and/or modify it.  ---
This is not  protocol statement it is a statement of why one might wish to
do something.  If the proxy does not implement the spec, it does not have
this capability.
	(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
	(section 3) An authorization exchange before authentication allows a
RADIUS client to provide the RADIUS server with information that MAY modify
how the authentication process will be performed (e.g. it MAY affect the
selection of the EAP method).  --- This decision process is independent of
the fragmentation protocol and thus is not appropriate 2119 language.

2.  !!! Pet Peeve !!! - I have run into people who believe that the
capitalization of may, should, must do not matter when defining 2119
language.  Personally I think they are idiots for this view, but they
strongly believe it.  For this reason I have started including the sentence
"When these words appear in lower case, they have their natural language
meaning." As part of the 2119 boiler plate.  You might want to consider
doing so.

3.  On page 9 (after figure 2) - It is not clear to me what you mean by
Non-compliant servers.  Are these servers that do not implement this
specification or are they servers that do not correctly implement the RADIUS
specification.  (Simple way to make it clear would be to add a parenthetical
after the first occurrence of the term   "non-compliant (i.e., servers not
implementing fragmentation)"

4. Same paragraph - suggest s/a particular Service-Type/a Service-Type other
than Additional-Authorization/  (I am not sure that is a correct statement
in terms of the actual value returned, but particular does not give me
something to code to)

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.

6. Section 4.2 - Para #1 - The requirements on the Service-Type attribute,
while understandable, appear to violate a previous statement that the order
of the attributes not be changed (Section 3 para 3  The encoding process is
a simple linear walk over the attributes to be encoded.  This walk preserves
the order of the attributes, as required by [RFC2865].)  This should
probably be explicitly called out as being ok.  (This may be done by a proxy
rather than the server.)  - Maybe point to the discussion in section 7.2 as
well, although there it says that the attributes can be re-ordered.

After a second pass through the document (with jumps to other documents), I
still find this somewhat confusing language here.  Something that might make
things a bit clearer
	In section 3 para 3 - s/order of the attributes/order of attributes
of the same type/

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.)

8.  Section 7.4 - Service-Type = Additional-Authorization should be included
in the server list.

9. section 10 - !! Pet Peeve !! - A MAC is not a signature and should not be
called one.

10.  References
	(Which of the documents do I need to understand to implement - as
oppose to understand background reasoning)
	RFC 2866 should be informational
	RFC 3579 should be informational
	RFC 5080 should be informational
	(Yes I could list others here such as how to write IANA
considerations which the author needs to know but not the reader).

11.  Did I miss where you defined the T bit - or did you?

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.

13.  Should the Access-Request (ID=181) be Frag-Status = More-Data-Pending ?

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.

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.

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.

Spelling errors

s/wand/and/
s/eight (7)/seven (7)/
s/how many space/how much space/
s/MUST not/MUST NOT/
s/before start forwarding/before starting to forward/
s/could be a reasonable limits/could be a reasonable limit/  or  /could be
reasonable limits/

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 07 Feb 2014 09:45:24 +0100

Hi Jim,

thanks for the valuable comments. See my responses inline:

> do something.  If the proxy does not implement the spec, it does not have

Right.

> this is part of the fragmentation protocol

Take into account that Service-Type = Additional-Authorization is a new
value defined in this document.

> the fragmentation protocol and thus is not appropriate 2119 language.

Right.

> meaning." As part of the 2119 boiler plate.  You might want to consider

I think it is a good idea.

> implementing fragmentation)"

Right, that term is confusing.

> in terms of the actual value returned, but particular does not give me

I agree with your suggestion.

> 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.

> 	In section 3 para 3 - s/order of the attributes/order of attributes

Yes. When I read your comment I first thought exactly that, that order
must be preserved between attributes of the same type. I was going to
suggest a similar rephrasing as you did.

> section, which makes me less inclined to include in the general discussion

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.

> 8.  Section 7.4 - Service-Type = Additional-Authorization should be included

Absolutely. I forgot to add it.

> 9. section 10 - !! Pet Peeve !! - A MAC is not a signature and should not be

Right, my bad. It should say:

     It requires that all Access-Request packets associated with
    fragmentation are authenticated using the existing
    Message-Authenticator attribute.  This attribute  prevents forging
    and replay, to the limits of the existing security.

> considerations which the author needs to know but not the reader).

That makes sense.

> 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]/

> 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.

> 13.  Should the Access-Request (ID=181) be Frag-Status = More-Data-Pending ?

Yes, thanks.

> 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.

> on the re-ordering of attributes which have disparate types in order to pack

I'm not sure that would be worthy. That would require to execute an
optimization algorithm just to gain some bytes.

> Fragmentation-Supported if fragmentation is not going to happen.

I guess we could provide a one-line explanation of each value for "code"
field.

> s/could be a reasonable limits/could be a reasonable limit/  or  /could be

Thanks and best regards,
Alejandro

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 7 Feb 2014 09:29:43 -0800

From: Alejandro Perez Mendez [mailto:[email-masked]] 
Sent: Friday, February 07, 2014 12:45 AM
To: Jim Schaad; [email-masked]
Cc: [email-masked]
Subject: Re: Last call comments on draft-ietf-radext-fragmentation-02

Hi Jim,

 

[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.

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.

[JLS] Yes – I think this is probably a sufficient degree of uniqueness.

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.

We address this issue

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

   "T" for Truncation.

This says you need to have a section to define it and mark your document as
updating RFC 6929.

 

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.

[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.

 
13.  Should the Access-Request (ID=181) 

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.

 

[JLS] – No problems – I would have stated it in terms of – you can do this
but it is not worth the effort.

[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.

Thanks and best regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 10 Feb 2014 09:45:32 +0100

El 07/02/14 18:29, Jim Schaad escribió:
>
> *From:*Alejandro Perez Mendez [mailto:[email-masked]]
> *Sent:* Friday, February 07, 2014 12:45 AM
> *To:* Jim Schaad; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: Last call comments on draft-ietf-radext-fragmentation-02
>
> Hi Jim,
>
> 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.
>
>
>
>   
> 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.
>
> 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.

> "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:
>
> 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).

> 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.
>
> included in all Access-Accept messages where “post-authorization” in 
> terms of what I laid out above is going to be possible.
>

I agree.

> [JLS] – No problems – I would have stated it in terms of – you can do 
> this but it is not worth the effort.
>
>   
>   
> 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
>

Seems reasonable.

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