To: [email-masked]
Date: Sat, 13 Feb 2010 16:58:55 -0000

Sam wrote:
> > Ah! My terminology failure. Can we include a hash of the SAML=20
> > message in the artifact or along side the artifact to get=20
> authenticity=20
> > of the SAML message?

Josh wrote:
> Probably. I've discovered an issue in the specification which=20
> might prevent this (there is a requirement to "authenticate"=20
> the issuer, which to me implies a demonstration of authority=20
> to wield a name; whereas in this instance we only need to=20
> demonstrate authority to wield a SAML message). I've emailed=20
> the SSTC list for clarification.

Bad news. As I suspected, it is a requirement that the call-back used to
the resolve the artifact is authenticated at the transport layer.
Scott's advice was to avoid artifact resolution "at all costs". I see
two possible options:

1. Ignore the RADIUS spec's MTU requirement, and use RadSec to transport
the SAML message by value over TCP. The argument for doing this is that
the RADIUS MTU makes sense for UDP, but not for TCP, and being dogmatic
about the RADIUS spec is going to significantly increase complexity.
There are sufficiently few RadSec implementations at the moment that
we're realistically unlikely to cause any actual harm. Most importantly,
it is also simple and robust. The argument for not doing this is that
we're abusing the RADIUS spec.

2. TAS and TAC derive a new key for the artifact call-back from the
established AAA context. TAS replicates a copy to S with the
Access-Accept, together with the artifact. S uses the key and the
artifact to resolve the SAML message.

Any other ideas?

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Wed Jan  2 04:44:17 2013
From: Klaas Wierenga <[email-masked]>
Date: Wed, 2 Jan 2013 13:44:12 +0100
To: "<[email-masked]>" <[email-masked]>
Subject: [abfab] abfab meeting in Orlando

Hi all,

First of all, Happy Newyear!=20

We have requested a 2 hour slot for the coming IETF, with as main agenda =
items the remaining documents and a rechartering discussion.
Please let us know if you want to be on the agenda!

Cheers,

Klaas & Leif=

From [email-masked]  Tue Jan  8 03:54:18 2013
From: Rhys Smith <[email-masked]>
Date: Tue, 8 Jan 2013 11:54:10 +0000
To: [email-masked]
Sender: [email-masked]
Subject: [abfab] Fwd: New Version Notification for draft-smith-abfab-usability-ui-considerations-03.txt

--Apple-Mail=_890C0FC2-D86C-4C5B-B101-AED930322BD1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

FYI. I've bumped the version of the usability/UI draft just to keep it =
alive, as it was due to expire in a couple of days. No real changes from =
-02.

But, I'm going to be updating it over the next week or so and submitting =
an updated version, so if anyone has any input into that process above =
that which I've already received it would be most welcome=85=20

Best,
Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's research and education network

email: [email-masked] / [email-masked]
GPG: 0xDE2F024C

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for =
draft-smith-abfab-usability-ui-considerations-03.txt
> Date: 8 January 2013 11:50:54 GMT
> To: [email-masked]
>=20
>=20
> A new version of I-D, =
draft-smith-abfab-usability-ui-considerations-03.txt
> has been successfully submitted by Rhys Smith and posted to the
> IETF repository.
>=20
> Filename:	 draft-smith-abfab-usability-ui-considerations
> Revision:	 03
> Title:		 Application Bridging for Federated Access =
Beyond web (ABFAB) Usability and User Interface Considerations
> Creation date:	 2013-01-08
> WG ID:		 Individual Submission
> Number of pages: 15
> URL:             =
http://www.ietf.org/internet-drafts/draft-smith-abfab-usability-ui-conside=
rations-03.txt
> Status:          =
http://datatracker.ietf.org/doc/draft-smith-abfab-usability-ui-considerati=
ons
> Htmlized:        =
http://tools.ietf.org/html/draft-smith-abfab-usability-ui-considerations-0=
3
> Diff:            =
http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-abfab-usability-ui-consider=
ations-03
>=20
> Abstract:
>   The use of ABFAB-based technologies requires that each user's device
>   is configured with the user's identities that they wish to use in
>   ABFAB transactions.  This will require something on that device,
>   either built into the operating system or a standalone utility, that
>   will manage the user's identities and identity to service mappings.
>   Anyone designing that "something" will face the same set of
>   challenges.  This document aims to document these challenges with =
the
>   aim of producing well-thought out UIs with some degree of
>   consistency.
>=20
>=20
>=20
>=20
> The IETF Secretariat
>=20

--Apple-Mail=_890C0FC2-D86C-4C5B-B101-AED930322BD1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">FYI. =
I've bumped the version of the usability/UI draft just to keep it alive, =
as it was due to expire in a couple of days. No real changes from =
-02.<div><br></div><div>But, I'm going to be updating it over the next =
week or so and submitting an updated version, so if anyone has any input =
into that process above that which I've already received it would be =
most =
welcome=85&nbsp;<div><br></div><div>Best,</div><div>Rhys.</div><div><div>
--<br>Dr Rhys Smith<br>Identity, Access, and Middleware =
Specialist<br>Cardiff University &amp; Janet - the UK's research and =
education network<br><br>email:&nbsp;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&nbsp;/&nbsp;<a=
 href=3D"mailto:[email-masked]">[email-masked]</a><br>GPG: =
0xDE2F024C

</div>
<div><br><div>Begin forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; =
font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span =
style=3D"font-family:'Helvetica'; font-size:medium;"><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br><=
/span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, =
1.0);"><b>Subject: </b></span><span style=3D"font-family:'Helvetica'; =
font-size:medium;"><b>New Version Notification for =
draft-smith-abfab-usability-ui-considerations-03.txt</b><br></span></div><=
div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; =
font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span =
style=3D"font-family:'Helvetica'; font-size:medium;">8 January 2013 =
11:50:54 GMT<br></span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, =
1.0);"><b>To: </b></span><span style=3D"font-family:'Helvetica'; =
font-size:medium;"><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br></span></di=
v><br><div><br>A new version of I-D, =
draft-smith-abfab-usability-ui-considerations-03.txt<br>has been =
successfully submitted by Rhys Smith and posted to the<br>IETF =
repository.<br><br>Filename:<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span> =
draft-smith-abfab-usability-ui-considerations<br>Revision:<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span> =
03<br>Title:<span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span> Application Bridging for Federated Access Beyond web (ABFAB) =
Usability and User Interface Considerations<br>Creation date:<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span> =
2013-01-08<br>WG ID:<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span> Individual Submission<br>Number =
of pages: 15<br>URL: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a=
 =
href=3D"http://www.ietf.org/internet-drafts/draft-smith-abfab-usability-ui=
-considerations-03.txt">http://www.ietf.org/internet-drafts/draft-smith-ab=
fab-usability-ui-considerations-03.txt</a><br>Status: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"http://datatracker.ietf.org/doc/draft-smith-abfab-usability-ui-con=
siderations">http://datatracker.ietf.org/doc/draft-smith-abfab-usability-u=
i-considerations</a><br>Htmlized: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"http://tools.ietf.org/html/draft-smith-abfab-usability-ui-consider=
ations-03">http://tools.ietf.org/html/draft-smith-abfab-usability-ui-consi=
derations-03</a><br>Diff: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-abfab-usability-ui-=
considerations-03">http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-abfab-us=
ability-ui-considerations-03</a><br><br>Abstract:<br> &nbsp;&nbsp;The =
use of ABFAB-based technologies requires that each user's device<br> =
&nbsp;&nbsp;is configured with the user's identities that they wish to =
use in<br> &nbsp;&nbsp;ABFAB transactions. &nbsp;This will require =
something on that device,<br> &nbsp;&nbsp;either built into the =
operating system or a standalone utility, that<br> &nbsp;&nbsp;will =
manage the user's identities and identity to service mappings.<br> =
&nbsp;&nbsp;Anyone designing that "something" will face the same set =
of<br> &nbsp;&nbsp;challenges. &nbsp;This document aims to document =
these challenges with the<br> &nbsp;&nbsp;aim of producing well-thought =
out UIs with some degree of<br> =
&nbsp;&nbsp;consistency.<br><br><br><br><br>The IETF =
Secretariat<br><br></div></blockquote></div><br></div></div></body></html>=

--Apple-Mail=_890C0FC2-D86C-4C5B-B101-AED930322BD1--

From [email-masked]  Fri Jan 18 11:45:05 2013
From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Fri, 18 Jan 2013 14:45:01 -0500
Subject: [abfab] Eap Applicability:  Re-authentication

So, I was wondering what's up with the EAP applicability draft and why
we've not made more progress. I'm kind of glad I didn't ask the question
but instead went back to my notes, because I discovered that I dropped
the ball.
I already put forward some text on retransmission; Jim and Yoshi
provided edits and they were happy with that.
I don't think Alper was happy with the result; the chairs and editors of
EAP applicability will need to resolve who is in the rough there.

However, I also promised text on re-authentication.

Proposed text:

EAP lower layers MAY provide a mechanism for re-authentication to happen
within an existing session [RFC 3748]. Diameter standardizes a mechanism
fro an AAA server to request re-authentication [RFC
4005]. Re-authentication permits security associations to be updated
without establishing a new session. For network access, this can be
important because interrupting network access can disrupt connections
and media.

Some applications might not need re-authentication support. For example
if sessions are relatively short-lived or if sessions can be replaced
without significant disruption, re-authentication might not provide
value. Protocols like HypertextTransport Protocol (HTTP) and Simple
Mail Transport Protocol (SMTP) are examples of protocols where
establishing a new connection to update security associations is likely
to be sufficient.

Re-authentication is likely to be valuable if sessions or connections
are long-lived or if there is a significant cost to disrupting them.

Another factor may make re-authentication important. Some protocols only
permit one side of a connection (for example the client) to establish a
new connection. If another party in the protocol MAY need the security
association refreshed then re-authentication can provide a mechanism to
do so.

Lower layers SHOULD describe whether re-authentication is provided and
which parties can initiate it.

From [email-masked]  Fri Jan 18 15:06:07 2013
From: "Jim Schaad" <[email-masked]>
To: "'Sam Hartman'" <[email-masked]>, <[email-masked]>
Date: Fri, 18 Jan 2013 15:05:42 -0800
Subject: Re: [abfab] Eap Applicability:  Re-authentication

Sam,

Here are some initial inline comments 

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Friday, January 18, 2013 11:45 AM
> To: [email-masked]
> Subject: [abfab] Eap Applicability: Re-authentication
> 
> 
> 
> So, I was wondering what's up with the EAP applicability draft and why
we've
> not made more progress. I'm kind of glad I didn't ask the question but
> instead went back to my notes, because I discovered that I dropped the
ball.
> I already put forward some text on retransmission; Jim and Yoshi provided
> edits and they were happy with that.
> I don't think Alper was happy with the result; the chairs and editors of
EAP
> applicability will need to resolve who is in the rough there.
> 
> However, I also promised text on re-authentication.
> 
> Proposed text:
> 
> EAP lower layers MAY provide a mechanism for re-authentication to happen
> within an existing session [RFC 3748]. Diameter standardizes a mechanism
fro

[JLS] I have problems with talking about the re-authentication happening
within an existing session.  EAP does not have sessions so you don't
re-authenticate inside of an EAP session.  You need to clarify what session
you are talking about.  You should also potentially talk about what a
session means, are we talking about cryptographic sessions, application
sessions, infrastructure session?  

s/fro/for/

> an AAA server to request re-authentication [RFC 4005]. Re-authentication
> permits security associations to be updated without establishing a new
> session. For network access, this can be important because interrupting
> network access can disrupt connections and media.
> 
> Some applications might not need re-authentication support. For example if
> sessions are relatively short-lived or if sessions can be replaced without
> significant disruption, re-authentication might not provide value.
Protocols
> like HypertextTransport Protocol (HTTP) and Simple Mail Transport Protocol
> (SMTP) are examples of protocols where establishing a new connection to

s/establishing/re-establishing/

> update security associations is likely to be sufficient.
> 
> Re-authentication is likely to be valuable if sessions or connections are
long-
> lived or if there is a significant cost to disrupting them.
> 
> Another factor may make re-authentication important. Some protocols only
> permit one side of a connection (for example the client) to establish a
new

s/one side of a connection/one party in the protocol/

> connection. If another party in the protocol MAY need the security

[JLS] Suggest killing the MAY.  There is not real protocol requirement on
this statement - it could never be testable.
s/ in the protocol MAY need the/in the protocol needs the/

> association refreshed then re-authentication can provide a mechanism to do
> so.

> 
> Lower layers SHOULD describe whether re-authentication is provided and
> which parties can initiate it.

The EAP applicability statement document should make some type of definition
for what a lower layer is.  Copying the definition from section 2.2 in 3748
is fine with me.

[JLS] The lower lay needs to 1) identify which party(s) can initiate the
re-authentication and 2) how to send an appropriate protocol message to that
party(s) to request that it initiate re-authentication.

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

From [email-masked]  Sun Jan 20 16:53:39 2013
Date: Mon, 21 Jan 2013 09:53:31 +0900
From: Yoshihiro Ohba <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] Eap Applicability:  Re-authentication

Sam,

I suggested to replace "application" with "lower-layer" in your text and 
Jim was against my suggestion.  To continue the discussion, I asked a 
question whether GSS EAP token carries a sequence number but it was not 
answered yet.   My point is that GSS-EAP solely cannot be considered as 
an EAP lower layer unless GSS-EAP itself provides in-order delivery of 
EAP message.  For the same reason, IEEE 802.1X can be considered as an 
EAP lower-layer only if 802.1X frame is carried over Ethernet or alike 
media that provides in-order delivery of EAP message.

Yoshihiro Ohba

(2013/01/19 4:45), Sam Hartman wrote:
>
> So, I was wondering what's up with the EAP applicability draft and why
> we've not made more progress. I'm kind of glad I didn't ask the question
> but instead went back to my notes, because I discovered that I dropped
> the ball.
> I already put forward some text on retransmission; Jim and Yoshi
> provided edits and they were happy with that.
> I don't think Alper was happy with the result; the chairs and editors of
> EAP applicability will need to resolve who is in the rough there.
>
> However, I also promised text on re-authentication.
>
> Proposed text:
>
> EAP lower layers MAY provide a mechanism for re-authentication to happen
> within an existing session [RFC 3748]. Diameter standardizes a mechanism
> fro an AAA server to request re-authentication [RFC
> 4005]. Re-authentication permits security associations to be updated
> without establishing a new session. For network access, this can be
> important because interrupting network access can disrupt connections
> and media.
>
> Some applications might not need re-authentication support. For example
> if sessions are relatively short-lived or if sessions can be replaced
> without significant disruption, re-authentication might not provide
> value. Protocols like HypertextTransport Protocol (HTTP) and Simple
> Mail Transport Protocol (SMTP) are examples of protocols where
> establishing a new connection to update security associations is likely
> to be sufficient.
>
> Re-authentication is likely to be valuable if sessions or connections
> are long-lived or if there is a significant cost to disrupting them.
>
> Another factor may make re-authentication important. Some protocols only
> permit one side of a connection (for example the client) to establish a
> new connection. If another party in the protocol MAY need the security
> association refreshed then re-authentication can provide a mechanism to
> do so.
>
> Lower layers SHOULD describe whether re-authentication is provided and
> which parties can initiate it.
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab
>

From [email-masked]  Mon Jan 21 12:09:22 2013
From: "Jim Schaad" <[email-masked]>
To: "'Yoshihiro Ohba'" <[email-masked]>, <[email-masked]>
Date: Mon, 21 Jan 2013 12:08:57 -0800
Subject: Re: [abfab] Eap Applicability:  Re-authentication

I don't think we have suggested that GSS-EAP is the "lower -layer", nor is
it the "application".    GSS-EAP states that the "application" is
responsible for doing in order delivery for during the initialization.

Let us consider the case of SSH using GSS-EAP for authentication.  One could
run SSH over UDP, TCP, DTLS/UDP, TLS/TCP.  In these cases SSH, the
"application", would need to have code to deal with in order delivery with
UDP, however TCP, DTLS/UDP and TLS/TCP themselves all satisfy the in order
requirements.  

Many of the things that we are talking about however are based on SSH, how
does it deal with re-authentication being one of those things.  One does not
expect TCP to know anything about the process of asking for and dealing with
re-authentication, but SSH is the proper layer to talk about this.  

In this working group we are focused on applications not lower-layers.  We
need to tell applications what they need to do (one of which is to figure
out how to get in order delivery somehow) and not confuse the issue between
what is an application as oppose to making them think about lower-layers
instead (which are maybe different).

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yoshihiro Ohba
> Sent: Sunday, January 20, 2013 4:54 PM
> To: [email-masked]
> Subject: Re: [abfab] Eap Applicability: Re-authentication
> 
> Sam,
> 
> I suggested to replace "application" with "lower-layer" in your text and
Jim
> was against my suggestion.  To continue the discussion, I asked a question
> whether GSS EAP token carries a sequence number but it was not
> answered yet.   My point is that GSS-EAP solely cannot be considered as
> an EAP lower layer unless GSS-EAP itself provides in-order delivery of EAP
> message.  For the same reason, IEEE 802.1X can be considered as an EAP
> lower-layer only if 802.1X frame is carried over Ethernet or alike media
that
> provides in-order delivery of EAP message.
> 
> Yoshihiro Ohba
> 
> 
> (2013/01/19 4:45), Sam Hartman wrote:
> >
> > So, I was wondering what's up with the EAP applicability draft and why
> > we've not made more progress. I'm kind of glad I didn't ask the
> > question but instead went back to my notes, because I discovered that
> > I dropped the ball.
> > I already put forward some text on retransmission; Jim and Yoshi
> > provided edits and they were happy with that.
> > I don't think Alper was happy with the result; the chairs and editors
> > of EAP applicability will need to resolve who is in the rough there.
> >
> > However, I also promised text on re-authentication.
> >
> > Proposed text:
> >
> > EAP lower layers MAY provide a mechanism for re-authentication to
> > happen within an existing session [RFC 3748]. Diameter standardizes a
> > mechanism fro an AAA server to request re-authentication [RFC 4005].
> > Re-authentication permits security associations to be updated without
> > establishing a new session. For network access, this can be important
> > because interrupting network access can disrupt connections and media.
> >
> > Some applications might not need re-authentication support. For
> > example if sessions are relatively short-lived or if sessions can be
> > replaced without significant disruption, re-authentication might not
> > provide value. Protocols like HypertextTransport Protocol (HTTP) and
> > Simple Mail Transport Protocol (SMTP) are examples of protocols where
> > establishing a new connection to update security associations is
> > likely to be sufficient.
> >
> > Re-authentication is likely to be valuable if sessions or connections
> > are long-lived or if there is a significant cost to disrupting them.
> >
> > Another factor may make re-authentication important. Some protocols
> > only permit one side of a connection (for example the client) to
> > establish a new connection. If another party in the protocol MAY need
> > the security association refreshed then re-authentication can provide
> > a mechanism to do so.
> >
> > Lower layers SHOULD describe whether re-authentication is provided and
> > which parties can initiate it.
> > _______________________________________________
> > abfab mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/abfab
> >
> 
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

From [email-masked]  Mon Jan 21 16:20:00 2013
Date: Tue, 22 Jan 2013 09:19:54 +0900
From: Yoshihiro Ohba <[email-masked]>
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] Eap Applicability:  Re-authentication

Just to clarify that my comment was about "Retransmission Text for EAP 
applicability" that is discussed in another thread.

Please see my comment below.

(2013/01/22 5:08), Jim Schaad wrote:
> I don't think we have suggested that GSS-EAP is the "lower -layer", nor is
> it the "application".    GSS-EAP states that the "application" is
> responsible for doing in order delivery for during the initialization.

This simply means that application is part of EAP lower-layer, as oppose 
to your previous statement you made in Nov 19, 2012: "However this does 
not change my opinion that application protocol that is using GSS-API is 
not part of the EAP lower-level."

We need to first mention in EAP applicability is that a GSS-EAP 
application is part of EAP lower-layer and needs to follow the EAP 
lower-layer requirements.

Then, we can further have detailed text on retransmission and message 
discarding behavior as suggested by Sam, but I still suggest replacing 
"application" with "lower-layer" in there, because technically there is 
nothing specific to applications.

Regards,
Yoshihiro Ohba

> Let us consider the case of SSH using GSS-EAP for authentication.  One could
> run SSH over UDP, TCP, DTLS/UDP, TLS/TCP.  In these cases SSH, the
> "application", would need to have code to deal with in order delivery with
> UDP, however TCP, DTLS/UDP and TLS/TCP themselves all satisfy the in order
> requirements.
>
> Many of the things that we are talking about however are based on SSH, how
> does it deal with re-authentication being one of those things.  One does not
> expect TCP to know anything about the process of asking for and dealing with
> re-authentication, but SSH is the proper layer to talk about this.
>
> In this working group we are focused on applications not lower-layers.  We
> need to tell applications what they need to do (one of which is to figure
> out how to get in order delivery somehow) and not confuse the issue between
> what is an application as oppose to making them think about lower-layers
> instead (which are maybe different).
>
> Jim
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Yoshihiro Ohba
>> Sent: Sunday, January 20, 2013 4:54 PM
>> To: [email-masked]
>> Subject: Re: [abfab] Eap Applicability: Re-authentication
>>
>> Sam,
>>
>> I suggested to replace "application" with "lower-layer" in your text and
> Jim
>> was against my suggestion.  To continue the discussion, I asked a question
>> whether GSS EAP token carries a sequence number but it was not
>> answered yet.   My point is that GSS-EAP solely cannot be considered as
>> an EAP lower layer unless GSS-EAP itself provides in-order delivery of EAP
>> message.  For the same reason, IEEE 802.1X can be considered as an EAP
>> lower-layer only if 802.1X frame is carried over Ethernet or alike media
> that
>> provides in-order delivery of EAP message.
>>
>> Yoshihiro Ohba
>>
>>
>> (2013/01/19 4:45), Sam Hartman wrote:
>>> So, I was wondering what's up with the EAP applicability draft and why
>>> we've not made more progress. I'm kind of glad I didn't ask the
>>> question but instead went back to my notes, because I discovered that
>>> I dropped the ball.
>>> I already put forward some text on retransmission; Jim and Yoshi
>>> provided edits and they were happy with that.
>>> I don't think Alper was happy with the result; the chairs and editors
>>> of EAP applicability will need to resolve who is in the rough there.
>>>
>>> However, I also promised text on re-authentication.
>>>
>>> Proposed text:
>>>
>>> EAP lower layers MAY provide a mechanism for re-authentication to
>>> happen within an existing session [RFC 3748]. Diameter standardizes a
>>> mechanism fro an AAA server to request re-authentication [RFC 4005].
>>> Re-authentication permits security associations to be updated without
>>> establishing a new session. For network access, this can be important
>>> because interrupting network access can disrupt connections and media.
>>>
>>> Some applications might not need re-authentication support. For
>>> example if sessions are relatively short-lived or if sessions can be
>>> replaced without significant disruption, re-authentication might not
>>> provide value. Protocols like HypertextTransport Protocol (HTTP) and
>>> Simple Mail Transport Protocol (SMTP) are examples of protocols where
>>> establishing a new connection to update security associations is
>>> likely to be sufficient.
>>>
>>> Re-authentication is likely to be valuable if sessions or connections
>>> are long-lived or if there is a significant cost to disrupting them.
>>>
>>> Another factor may make re-authentication important. Some protocols
>>> only permit one side of a connection (for example the client) to
>>> establish a new connection. If another party in the protocol MAY need
>>> the security association refreshed then re-authentication can provide
>>> a mechanism to do so.
>>>
>>> Lower layers SHOULD describe whether re-authentication is provided and
>>> which parties can initiate it.
>>> _______________________________________________
>>> abfab mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/abfab
>>>
>>
>> _______________________________________________
>> abfab mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/abfab
>

From [email-masked]  Mon Jan 21 16:47:01 2013
From: "Jim Schaad" <[email-masked]>
To: "'Yoshihiro Ohba'" <[email-masked]>
Date: Mon, 21 Jan 2013 16:46:36 -0800
Cc: [email-masked]
Subject: Re: [abfab] Eap Applicability:  Re-authentication

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Monday, January 21, 2013 4:20 PM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [abfab] Eap Applicability: Re-authentication
> 
> Just to clarify that my comment was about "Retransmission Text for EAP
> applicability" that is discussed in another thread.
> 
> Please see my comment below.
> 
> (2013/01/22 5:08), Jim Schaad wrote:
> > I don't think we have suggested that GSS-EAP is the "lower -layer", nor
is
> > it the "application".    GSS-EAP states that the "application" is
> > responsible for doing in order delivery for during the initialization.
> 
> This simply means that application is part of EAP lower-layer, as oppose
to
> your previous statement you made in Nov 19, 2012: "However this does not
> change my opinion that application protocol that is using GSS-API is not
part
> of the EAP lower-level."

No - I think the EAP lower-level is part of the application.

Jim

> 
> We need to first mention in EAP applicability is that a GSS-EAP
application is
> part of EAP lower-layer and needs to follow the EAP lower-layer
> requirements.
> 
> Then, we can further have detailed text on retransmission and message
> discarding behavior as suggested by Sam, but I still suggest replacing
> "application" with "lower-layer" in there, because technically there is
nothing
> specific to applications.
> 
> Regards,
> Yoshihiro Ohba
> 
> > Let us consider the case of SSH using GSS-EAP for authentication.  One
> > could run SSH over UDP, TCP, DTLS/UDP, TLS/TCP.  In these cases SSH,
> > the "application", would need to have code to deal with in order
> > delivery with UDP, however TCP, DTLS/UDP and TLS/TCP themselves all
> > satisfy the in order requirements.
> >
> > Many of the things that we are talking about however are based on SSH,
> > how does it deal with re-authentication being one of those things.
> > One does not expect TCP to know anything about the process of asking
> > for and dealing with re-authentication, but SSH is the proper layer to
talk
> about this.
> >
> > In this working group we are focused on applications not lower-layers.
> > We need to tell applications what they need to do (one of which is to
> > figure out how to get in order delivery somehow) and not confuse the
> > issue between what is an application as oppose to making them think
> > about lower-layers instead (which are maybe different).
> >
> > Jim
> >
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Yoshihiro Ohba
> >> Sent: Sunday, January 20, 2013 4:54 PM
> >> To: [email-masked]
> >> Subject: Re: [abfab] Eap Applicability: Re-authentication
> >>
> >> Sam,
> >>
> >> I suggested to replace "application" with "lower-layer" in your text
> >> and
> > Jim
> >> was against my suggestion.  To continue the discussion, I asked a
> >> question whether GSS EAP token carries a sequence number but it was
> not
> >> answered yet.   My point is that GSS-EAP solely cannot be considered as
> >> an EAP lower layer unless GSS-EAP itself provides in-order delivery
> >> of EAP message.  For the same reason, IEEE 802.1X can be considered
> >> as an EAP lower-layer only if 802.1X frame is carried over Ethernet
> >> or alike media
> > that
> >> provides in-order delivery of EAP message.
> >>
> >> Yoshihiro Ohba
> >>
> >>
> >> (2013/01/19 4:45), Sam Hartman wrote:
> >>> So, I was wondering what's up with the EAP applicability draft and
> >>> why we've not made more progress. I'm kind of glad I didn't ask the
> >>> question but instead went back to my notes, because I discovered
> >>> that I dropped the ball.
> >>> I already put forward some text on retransmission; Jim and Yoshi
> >>> provided edits and they were happy with that.
> >>> I don't think Alper was happy with the result; the chairs and
> >>> editors of EAP applicability will need to resolve who is in the rough
there.
> >>>
> >>> However, I also promised text on re-authentication.
> >>>
> >>> Proposed text:
> >>>
> >>> EAP lower layers MAY provide a mechanism for re-authentication to
> >>> happen within an existing session [RFC 3748]. Diameter standardizes
> >>> a mechanism fro an AAA server to request re-authentication [RFC 4005].
> >>> Re-authentication permits security associations to be updated
> >>> without establishing a new session. For network access, this can be
> >>> important because interrupting network access can disrupt connections
> and media.
> >>>
> >>> Some applications might not need re-authentication support. For
> >>> example if sessions are relatively short-lived or if sessions can be
> >>> replaced without significant disruption, re-authentication might not
> >>> provide value. Protocols like HypertextTransport Protocol (HTTP) and
> >>> Simple Mail Transport Protocol (SMTP) are examples of protocols
> >>> where establishing a new connection to update security associations
> >>> is likely to be sufficient.
> >>>
> >>> Re-authentication is likely to be valuable if sessions or
> >>> connections are long-lived or if there is a significant cost to
disrupting
> them.
> >>>
> >>> Another factor may make re-authentication important. Some protocols
> >>> only permit one side of a connection (for example the client) to
> >>> establish a new connection. If another party in the protocol MAY
> >>> need the security association refreshed then re-authentication can
> >>> provide a mechanism to do so.
> >>>
> >>> Lower layers SHOULD describe whether re-authentication is provided
> >>> and which parties can initiate it.
> >>> _______________________________________________
> >>> abfab mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/abfab
> >>>
> >>
> >> _______________________________________________
> >> abfab mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/abfab
> >

From [email-masked]  Mon Jan 21 16:51:20 2013
Date: Tue, 22 Jan 2013 09:51:17 +0900
From: Yoshihiro Ohba <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] Eap Applicability:  Re-authentication

I have a few comments on re-authentication text.

Please see below.

(2013/01/19 4:45), Sam Hartman wrote:
>
> Proposed text:
>
> EAP lower layers MAY provide a mechanism for re-authentication to happen
> within an existing session [RFC 3748]. Diameter standardizes a mechanism
> fro an AAA server to request re-authentication [RFC
> 4005]. Re-authentication permits security associations to be updated
> without establishing a new session. For network access, this can be
> important because interrupting network access can disrupt connections
> and media.
>
> Some applications might not need re-authentication support. For example

I suggest: s/Some applications/Some EAP lower layers/.

> if sessions are relatively short-lived or if sessions can be replaced
> without significant disruption, re-authentication might not provide
> value. Protocols like HypertextTransport Protocol (HTTP) and Simple
> Mail Transport Protocol (SMTP) are examples of protocols where
> establishing a new connection to update security associations is likely
> to be sufficient.

Does HTTP support GSS-API?  If not, I suggest to remove HTTP from the 
text as we are discussing EAP re-authentication.   We should also add 
text to mention that SMTP with GSS-EAP is considered as EAP lower-layer.

Yoshihiro Ohba

>
> Re-authentication is likely to be valuable if sessions or connections
> are long-lived or if there is a significant cost to disrupting them.
>
> Another factor may make re-authentication important. Some protocols only
> permit one side of a connection (for example the client) to establish a
> new connection. If another party in the protocol MAY need the security
> association refreshed then re-authentication can provide a mechanism to
> do so.
>
> Lower layers SHOULD describe whether re-authentication is provided and
> which parties can initiate it.
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab
>

From [email-masked]  Mon Jan 21 17:01:10 2013
Date: Tue, 22 Jan 2013 10:00:38 +0900
From: Yoshihiro Ohba <[email-masked]>
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] Eap Applicability:  Re-authentication

(2013/01/22 9:46), Jim Schaad wrote:
> No - I think the EAP lower-level is part of the application.

I don't think it's an accurate description.  In the case where an 
appplication relies on reliable transport (e.g. TCP) for in-order 
message delivery, the EAP lower-layer spans both the application and the 
reliable transport.

Yoshihiro Ohba

> Jim
>
>> We need to first mention in EAP applicability is that a GSS-EAP
> application is
>> part of EAP lower-layer and needs to follow the EAP lower-layer
>> requirements.
>>
>> Then, we can further have detailed text on retransmission and message
>> discarding behavior as suggested by Sam, but I still suggest replacing
>> "application" with "lower-layer" in there, because technically there is
> nothing
>> specific to applications.
>>
>> Regards,
>> Yoshihiro Ohba
>>
>>> Let us consider the case of SSH using GSS-EAP for authentication.  One
>>> could run SSH over UDP, TCP, DTLS/UDP, TLS/TCP.  In these cases SSH,
>>> the "application", would need to have code to deal with in order
>>> delivery with UDP, however TCP, DTLS/UDP and TLS/TCP themselves all
>>> satisfy the in order requirements.
>>>
>>> Many of the things that we are talking about however are based on SSH,
>>> how does it deal with re-authentication being one of those things.
>>> One does not expect TCP to know anything about the process of asking
>>> for and dealing with re-authentication, but SSH is the proper layer to
> talk
>> about this.
>>> In this working group we are focused on applications not lower-layers.
>>> We need to tell applications what they need to do (one of which is to
>>> figure out how to get in order delivery somehow) and not confuse the
>>> issue between what is an application as oppose to making them think
>>> about lower-layers instead (which are maybe different).
>>>
>>> Jim
>>>
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of Yoshihiro Ohba
>>>> Sent: Sunday, January 20, 2013 4:54 PM
>>>> To: [email-masked]
>>>> Subject: Re: [abfab] Eap Applicability: Re-authentication
>>>>
>>>> Sam,
>>>>
>>>> I suggested to replace "application" with "lower-layer" in your text
>>>> and
>>> Jim
>>>> was against my suggestion.  To continue the discussion, I asked a
>>>> question whether GSS EAP token carries a sequence number but it was
>> not
>>>> answered yet.   My point is that GSS-EAP solely cannot be considered as
>>>> an EAP lower layer unless GSS-EAP itself provides in-order delivery
>>>> of EAP message.  For the same reason, IEEE 802.1X can be considered
>>>> as an EAP lower-layer only if 802.1X frame is carried over Ethernet
>>>> or alike media
>>> that
>>>> provides in-order delivery of EAP message.
>>>>
>>>> Yoshihiro Ohba
>>>>
>>>>
>>>> (2013/01/19 4:45), Sam Hartman wrote:
>>>>> So, I was wondering what's up with the EAP applicability draft and
>>>>> why we've not made more progress. I'm kind of glad I didn't ask the
>>>>> question but instead went back to my notes, because I discovered
>>>>> that I dropped the ball.
>>>>> I already put forward some text on retransmission; Jim and Yoshi
>>>>> provided edits and they were happy with that.
>>>>> I don't think Alper was happy with the result; the chairs and
>>>>> editors of EAP applicability will need to resolve who is in the rough
> there.
>>>>> However, I also promised text on re-authentication.
>>>>>
>>>>> Proposed text:
>>>>>
>>>>> EAP lower layers MAY provide a mechanism for re-authentication to
>>>>> happen within an existing session [RFC 3748]. Diameter standardizes
>>>>> a mechanism fro an AAA server to request re-authentication [RFC 4005].
>>>>> Re-authentication permits security associations to be updated
>>>>> without establishing a new session. For network access, this can be
>>>>> important because interrupting network access can disrupt connections
>> and media.
>>>>> Some applications might not need re-authentication support. For
>>>>> example if sessions are relatively short-lived or if sessions can be
>>>>> replaced without significant disruption, re-authentication might not
>>>>> provide value. Protocols like HypertextTransport Protocol (HTTP) and
>>>>> Simple Mail Transport Protocol (SMTP) are examples of protocols
>>>>> where establishing a new connection to update security associations
>>>>> is likely to be sufficient.
>>>>>
>>>>> Re-authentication is likely to be valuable if sessions or
>>>>> connections are long-lived or if there is a significant cost to
> disrupting
>> them.
>>>>> Another factor may make re-authentication important. Some protocols
>>>>> only permit one side of a connection (for example the client) to
>>>>> establish a new connection. If another party in the protocol MAY
>>>>> need the security association refreshed then re-authentication can
>>>>> provide a mechanism to do so.
>>>>>
>>>>> Lower layers SHOULD describe whether re-authentication is provided
>>>>> and which parties can initiate it.
>>>>> _______________________________________________
>>>>> abfab mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/abfab
>>>>>
>>>> _______________________________________________
>>>> abfab mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/abfab
>
>

From [email-masked]  Thu Jan 24 01:53:05 2013
Date: Thu, 24 Jan 2013 10:53:01 +0100
From: Alejandro Perez Mendez <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-04.txt

This is a multi-part message in MIME format.
--------------000103030703090803090109
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

we have uploaded a new version of our RADIUS fragmentation draft. This 
version introduces some relevant changes:

  * Improved description of fragmentation of Access-Accept packets.
  * Use of Additional-Authorization service type instead of Authorize-Only
  * Improved description of CHUNK size calculation.
  * New section describing how to deal with Proxy-State attributes,
    including the mechanism used by the RADIUS client to discover the
    amount of space required for them along the path (also includes the
    description of a new RADIUS Attribute for that purpose).
  * Improved description of the management of State attributes.
  * New section about the interaction with RADIUS-EAP.
  * New section describing in detail how to rebuild a received
    fragmented packet.

Regards,
Alejandro

-------- Mensaje original --------
Asunto: 	New Version Notification for 
draft-perez-radext-radius-fragmentation-04.txt
Fecha: 	Thu, 24 Jan 2013 01:49:03 -0800
De: 	[email-masked]
Para: 	[email-masked]
CC: 	[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked]

A new version of I-D, draft-perez-radext-radius-fragmentation-04.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 04
Title:		 Support of fragmentation of RADIUS packets
Creation date:	 2013-01-24
WG ID:		 Individual Submission
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-04.txt
Status:          http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation
Htmlized:        http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-04

Abstract:
    This document describes a mechanism providing fragmentation support
    of RADIUS packets that exceed the 4 KB limit.

The IETF Secretariat

--------------000103030703090803090109
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    we have uploaded a new version of our RADIUS fragmentation draft.
    This version introduces some relevant changes:<br>
    <ul>
      <li>Improved description of fragmentation of Access-Accept
        packets.</li>
      <li>Use of Additional-Authorization service type instead of
        Authorize-Only</li>
      <li>Improved description of CHUNK size calculation.</li>
      <li>New section describing how to deal with Proxy-State
        attributes, including the mechanism used by the RADIUS client to
        discover the amount of space required for them along the path
        (also includes the description of a new RADIUS Attribute for
        that purpose).<br>
      </li>
      <li>Improved description of the management of State attributes.</li>
      <li>New section about the interaction with RADIUS-EAP.</li>
      <li>New section describing in detail how to rebuild a received
        fragmented packet.</li>
    </ul>
    Regards,<br>
    Alejandro<br>
    <br>
    <div class="moz-forward-container"><br>
      -------- Mensaje original --------
      <table class="moz-email-headers-table" border="0" cellpadding="0"
        cellspacing="0">
        <tbody>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Asunto:
            </th>
            <td>New Version Notification for
              draft-perez-radext-radius-fragmentation-04.txt</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Fecha: </th>
            <td>Thu, 24 Jan 2013 01:49:03 -0800</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">De: </th>
            <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Para: </th>
            <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC: </th>
            <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>, <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>, <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>,
              <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>, <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      <pre>A new version of I-D, draft-perez-radext-radius-fragmentation-04.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 04
Title:		 Support of fragmentation of RADIUS packets
Creation date:	 2013-01-24
WG ID:		 Individual Submission
Number of pages: 21
URL:             <a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-04.txt">http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-04.txt</a>
Status:          <a class="moz-txt-link-freetext" href="http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation">http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation</a>
Htmlized:        <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-04">http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-04</a>
Diff:            <a class="moz-txt-link-freetext" href="http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-04">http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-04</a>

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS packets that exceed the 4 KB limit.

The IETF Secretariat

</pre>
      <br>
    </div>
    <br>
  </body>
</html>

--------------000103030703090803090109--

From [email-masked]  Thu Jan 24 07:40:30 2013
From: Sam Hartman <[email-masked]>
To: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 24 Jan 2013 10:40:27 -0500
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-04.txt

This sounds great.
What's the state within radext?
I know it's now chartered; how can we help get this adopted?

From [email-masked]  Thu Jan 24 07:51:40 2013
Date: Thu, 24 Jan 2013 10:50:49 -0500
From: Alan DeKok <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] Fwd: New Version Notification for	draft-perez-radext-radius-fragmentation-04.txt

Sam Hartman wrote:
> This sounds great.
> What's the state within radext?
> I know it's now chartered; how can we help get this adopted?

  Pipe up in radext.  It's on the RADEXT charter now.  So we'll need
reviewers, and a call for WG adoption.

  Alan DeKok.

From [email-masked]  Thu Jan 24 15:37:34 2013
Date: Thu, 24 Jan 2013 23:37:24 +0000
From: "Diego R. Lopez" <[email-masked]>
To: Alan DeKok <[email-masked]>
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] Fwd: New Version Notification	for	draft-perez-radext-radius-fragmentation-04.txt

From [email-masked]  Tue Jan 29 08:05:31 2013
From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 29 Jan 2013 17:05:19 +0100
To: [email-masked], [email-masked]
Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.txt

Dear all,

we have received additional comments from Yoshihiro Ohba (many thanks) =
that we share with you.=20

Please, see some comments inline.

"Here is my review of draft-perez-radext-radius-fragmentation-04.

Section 1:

"Each RADIUS packet can transport several RADIUS attributes, to convey
the necessary information to the other peer, up to a maximum size of 4
KB of total data (including RADIUS packet headers)."

[YO] I suggest to replace "4 KB" with "4096 bytes" throughout the
document since "KB" can mean 4000 bytes in some cases.

[Rafa] OK.

"A reference-based mechanism is also proposed in [RFC6158], where
attributes can be obtained through an out-of-band protocol."

[YO} Meaning of this sentence is unclear. Does this mean RADIUS
attributes are obtained through some other protocol instead of RADIUS?
Or does this mean the actual format of the Value field of a RADIUS
Attribute is defined in other protocol specification? In the latter
case, it should be also mentioned that RADIUS-EAP is categorized as the
mechanism defined in RFC 6158.

[Rafa] It is referring the value of the attributes can be obtained by =
other protocol instead of RADIUS. This is coming from a previous comment =
related with SAML transport. Instead of transporting the real SAML =
messages an URL is set as attribute value. We can try to clarify a =
little bit more.

"However, there are no proposals to deal with fragmentation at a packet
level, when the total size exceeds the 4 KB limit imposed by the RADIUS
specification."

[YO] Meaning of "at a packet level" is unclear. Suggested change:
"However, there are no proposals to fragement a large-sized RADIUS
packet into multiple small-sized RADIUS packets, where the length of the
original (unfragmented) RADIUS packet exceeds the 4096-octet limit
imposed by the RADIUS specification."

[Rafa] This sounds good.

Section 2:

[YO] I am not sure if "T" flag is needed. In other words, it should be
possible to change [I-D.ietf-radext-radius-extensions] to simply allow a
fragment with the M-flag cleared not to be included in a non-last chunk.

[Rafa]=20

Yes, that may be possible. It is worth noting that we wanted to keep =
unmodified any existing I-D by the time being. Moreover, =
[I-D.ietf-radext-radius-extensions] has not considered that =
fragmentation at packet level may occur for obvious reasons. Moreover, =
that I-D is in a mature state now.

In any case, we may ask authors of [I-D.ietf-radext-radius-extensions].

Section 3.3:

[YO] Access-Accept fragmentation scheme looks odd compared to
Access-Request and Access-Challenge fragmentation schemes. There are
several questions related to this: (1) Why multiple chunks of
Access-Accept cannot be sent without having an Access-Challange to be
sent in between? (2) Why an Access-Accept cannot contain a
More-Data-Pending attribute instead of using a new service type value?
(3) How can a large attributue that is allowed to appear in an
Access-Accept but not allowed to appear in Access-Challenge be =
fragmented?

[Rafa]

1) We wanted to be symmetric in the design, where =
Access-Request/Access-Challenge exchange is used somehow for =
fragmentation support. In any case, we have also considered the usage of =
Access-Accept with Service-Type[AddAuth] so until all the attributes in =
the whole RADIUS Access-Accept are finally sent the exchange will be =
Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one =
is simply Access-Request/Access-Accept. This mode of operation would =
solve your question 3).

2) I think that may be also possible. In any case, I think Alan or Alex =
can elaborate a little bit a more about the usage of =
Service-Type[AddAuth].

3) Precisely, trying to answer this question we just came up with the =
solution in 1). What do you think? =20

Section 8:

[YO] Security Considerations section is too short. Security mechansims
that are needed for secure operation of the proposed fragmentation
mechanism needs to be described in this section.

[Rafa] Yes this section will be improved. Jim also raised comments about =
it.

Section 9:

[YO] I don't think the following statement is true: "This document has
no actions for IANA." because Section 6 defines new attributes.

[Rafa] Correct. This needs to be fixed.

Best Regards,
Yoshihiro Ohba
"

Best regards.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

From [email-masked]  Wed Jan 30 00:45:34 2013
Date: Wed, 30 Jan 2013 09:45:30 +0100
From: Alejandro Perez Mendez <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-04.txt

This is a multi-part message in MIME format.
--------------090409010301090200040308
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Yoshi, Rafa,

see some comments inline:

> Dear all,
>
> we have received additional comments from Yoshihiro Ohba (many thanks) that we share with you.
>
> Please, see some comments inline.
>
> "Here is my review of draft-perez-radext-radius-fragmentation-04.
>
> Section 1:
>
> "Each RADIUS packet can transport several RADIUS attributes, to convey
> the necessary information to the other peer, up to a maximum size of 4
> KB of total data (including RADIUS packet headers)."
>
> [YO] I suggest to replace "4 KB" with "4096 bytes" throughout the
> document since "KB" can mean 4000 bytes in some cases.
>
> [Rafa] OK.
>
>
> "A reference-based mechanism is also proposed in [RFC6158], where
> attributes can be obtained through an out-of-band protocol."
>
> [YO} Meaning of this sentence is unclear. Does this mean RADIUS
> attributes are obtained through some other protocol instead of RADIUS?
> Or does this mean the actual format of the Value field of a RADIUS
> Attribute is defined in other protocol specification? In the latter
> case, it should be also mentioned that RADIUS-EAP is categorized as the
> mechanism defined in RFC 6158.
>
> [Rafa] It is referring the value of the attributes can be obtained by other protocol instead of RADIUS. This is coming from a previous comment related with SAML transport. Instead of transporting the real SAML messages an URL is set as attribute value. We can try to clarify a little bit more.
>
> "However, there are no proposals to deal with fragmentation at a packet
> level, when the total size exceeds the 4 KB limit imposed by the RADIUS
> specification."
>
> [YO] Meaning of "at a packet level" is unclear. Suggested change:
> "However, there are no proposals to fragement a large-sized RADIUS
> packet into multiple small-sized RADIUS packets, where the length of the
> original (unfragmented) RADIUS packet exceeds the 4096-octet limit
> imposed by the RADIUS specification."
>
> [Rafa] This sounds good.
>
>
> Section 2:
>
> [YO] I am not sure if "T" flag is needed. In other words, it should be
> possible to change [I-D.ietf-radext-radius-extensions] to simply allow a
> fragment with the M-flag cleared not to be included in a non-last chunk.
>
> [Rafa]
>
> Yes, that may be possible. It is worth noting that we wanted to keep unmodified any existing I-D by the time being. Moreover, [I-D.ietf-radext-radius-extensions] has not considered that fragmentation at packet level may occur for obvious reasons. Moreover, that I-D is in a mature state now.
>
> In any case, we may ask authors of [I-D.ietf-radext-radius-extensions].
>
> Section 3.3:
>
> [YO] Access-Accept fragmentation scheme looks odd compared to
> Access-Request and Access-Challenge fragmentation schemes. There are
> several questions related to this: (1) Why multiple chunks of
> Access-Accept cannot be sent without having an Access-Challange to be
> sent in between? (2) Why an Access-Accept cannot contain a
> More-Data-Pending attribute instead of using a new service type value?
> (3) How can a large attributue that is allowed to appear in an
> Access-Accept but not allowed to appear in Access-Challenge be fragmented?
>
> [Rafa]
>
> 1) We wanted to be symmetric in the design, where Access-Request/Access-Challenge exchange is used somehow for fragmentation support. In any case, we have also considered the usage of Access-Accept with Service-Type[AddAuth] so until all the attributes in the whole RADIUS Access-Accept are finally sent the exchange will be Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one is simply Access-Request/Access-Accept. This mode of operation would solve your question 3).
>
> 2) I think that may be also possible. In any case, I think Alan or Alex can elaborate a little bit a more about the usage of Service-Type[AddAuth].
>
> 3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think?

This alternative sounds good to me. However, I think there may be still 
some advantages of using Service-Type instead of (or in addition to) 
More-Data-Pending for Access-Accept packets.

If the NAS/RP does not know anything about fragmentation (i.e. does not 
support this draft), it may take the first Access-Accept chunk, ignore 
the More-Data-Pending attribute (it is unknown for it), and process it 
as a complete packet. As no additional round-trip is mandatory after an 
Access-Accept packet, it may be problematic as it is possible that part 
of the obligations from the AS to the NAS (e.g. FW policies) are not 
enforced.

However, RFC 2865 says that (in relation to Access-Accept packets):

    A NAS is not
           required to implement all of these service types, and MUST treat
           unknown or unsupported Service-Types as though an Access-Reject
           had been received instead

Therefore, if the NAS does not understand 
Service-Type=AdditionalAuthorization, the Access-Accept packet will be 
interpreted as an Access-Reject one, which seems to be the most 
reasonable approach.

This sort of problems seem to not be critical with Access-Challenge 
packets, as the NAS is expected to generate a new Access-Request packet 
afterwards, and the AS can detect whether fragmentation was supported.

Regards,
Alejandro

> Section 8:
>
> [YO] Security Considerations section is too short. Security mechansims
> that are needed for secure operation of the proposed fragmentation
> mechanism needs to be described in this section.
>
> [Rafa] Yes this section will be improved. Jim also raised comments about it.
>
> Section 9:
>
> [YO] I don't think the following statement is true: "This document has
> no actions for IANA." because Section 6 defines new attributes.
>
> [Rafa] Correct. This needs to be fixed.
>
> Best Regards,
> Yoshihiro Ohba
> "
>
> Best regards.
>
> -------------------------------------------------------
> Rafael Marin Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: +34868888501 Fax: +34868884151 e-mail:[email-masked]
> -------------------------------------------------------
>
>
>
>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

--------------090409010301090200040308
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello Yoshi, Rafa, <br>
    <br>
    see some comments inline:<br>
    <br>
    <div class="moz-cite-prefix"><br>
    </div>
    <blockquote cite="mid:[email-masked]"
      type="cite">
      <pre wrap="">Dear all,

we have received additional comments from Yoshihiro Ohba (many thanks) that we share with you. 

Please, see some comments inline.

"Here is my review of draft-perez-radext-radius-fragmentation-04.

Section 1:

"Each RADIUS packet can transport several RADIUS attributes, to convey
the necessary information to the other peer, up to a maximum size of 4
KB of total data (including RADIUS packet headers)."

[YO] I suggest to replace "4 KB" with "4096 bytes" throughout the
document since "KB" can mean 4000 bytes in some cases.

[Rafa] OK.

"A reference-based mechanism is also proposed in [RFC6158], where
attributes can be obtained through an out-of-band protocol."

[YO} Meaning of this sentence is unclear. Does this mean RADIUS
attributes are obtained through some other protocol instead of RADIUS?
Or does this mean the actual format of the Value field of a RADIUS
Attribute is defined in other protocol specification? In the latter
case, it should be also mentioned that RADIUS-EAP is categorized as the
mechanism defined in RFC 6158.

[Rafa] It is referring the value of the attributes can be obtained by other protocol instead of RADIUS. This is coming from a previous comment related with SAML transport. Instead of transporting the real SAML messages an URL is set as attribute value. We can try to clarify a little bit more.

"However, there are no proposals to deal with fragmentation at a packet
level, when the total size exceeds the 4 KB limit imposed by the RADIUS
specification."

[YO] Meaning of "at a packet level" is unclear. Suggested change:
"However, there are no proposals to fragement a large-sized RADIUS
packet into multiple small-sized RADIUS packets, where the length of the
original (unfragmented) RADIUS packet exceeds the 4096-octet limit
imposed by the RADIUS specification."

[Rafa] This sounds good.

Section 2:

[YO] I am not sure if "T" flag is needed. In other words, it should be
possible to change [I-D.ietf-radext-radius-extensions] to simply allow a
fragment with the M-flag cleared not to be included in a non-last chunk.

[Rafa] 

Yes, that may be possible. It is worth noting that we wanted to keep unmodified any existing I-D by the time being. Moreover, [I-D.ietf-radext-radius-extensions] has not considered that fragmentation at packet level may occur for obvious reasons. Moreover, that I-D is in a mature state now.

In any case, we may ask authors of [I-D.ietf-radext-radius-extensions].

Section 3.3:

[YO] Access-Accept fragmentation scheme looks odd compared to
Access-Request and Access-Challenge fragmentation schemes. There are
several questions related to this: (1) Why multiple chunks of
Access-Accept cannot be sent without having an Access-Challange to be
sent in between? (2) Why an Access-Accept cannot contain a
More-Data-Pending attribute instead of using a new service type value?
(3) How can a large attributue that is allowed to appear in an
Access-Accept but not allowed to appear in Access-Challenge be fragmented?

[Rafa]

1) We wanted to be symmetric in the design, where Access-Request/Access-Challenge exchange is used somehow for fragmentation support. In any case, we have also considered the usage of Access-Accept with Service-Type[AddAuth] so until all the attributes in the whole RADIUS Access-Accept are finally sent the exchange will be Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one is simply Access-Request/Access-Accept. This mode of operation would solve your question 3).

2) I think that may be also possible. In any case, I think Alan or Alex can elaborate a little bit a more about the usage of Service-Type[AddAuth].

3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think?  </pre>
    </blockquote>
    <br>
    This alternative sounds good to me. However, I think there may be
    still some advantages of using Service-Type instead of (or in
    addition to) More-Data-Pending for Access-Accept packets.<br>
    <br>
    If the NAS/RP does not know anything about fragmentation (i.e. does
    not support this draft), it may take the first Access-Accept chunk,
    ignore the More-Data-Pending attribute (it is unknown for it), and
    process it as a complete packet. As no additional round-trip is
    mandatory after an Access-Accept packet, it may be problematic as it
    is possible that part of the obligations from the AS to the NAS
    (e.g. FW policies) are not enforced.<br>
    <br>
    However, RFC 2865 says that (in relation to Access-Accept packets):<br>
    <blockquote>
      <pre class="newpage">A NAS is not
      required to implement all of these service types, and MUST treat
      unknown or unsupported Service-Types as though an Access-Reject
      had been received instead</pre>
    </blockquote>
    <br>
    Therefore, if the NAS does not understand
    Service-Type=AdditionalAuthorization, the Access-Accept packet will
    be interpreted as an Access-Reject one, which seems to be the most
    reasonable approach.<br>
    <br>
    This sort of problems seem to not be critical with Access-Challenge
    packets, as the NAS is expected to generate a new Access-Request
    packet afterwards, and the AS can detect whether fragmentation was
    supported.<br>
    <br>
    Regards,<br>
    Alejandro<br>
    <br>
    <blockquote cite="mid:[email-masked]"
      type="cite">
      <pre wrap="">Section 8:

[YO] Security Considerations section is too short. Security mechansims
that are needed for secure operation of the proposed fragmentation
mechanism needs to be described in this section.

[Rafa] Yes this section will be improved. Jim also raised comments about it.

Section 9:

[YO] I don't think the following statement is true: "This document has
no actions for IANA." because Section 6 defines new attributes.

[Rafa] Correct. This needs to be fixed.

Best Regards,
Yoshihiro Ohba
"

Best regards.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
-------------------------------------------------------

_______________________________________________
radext mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/radext">https://www.ietf.org/mailman/listinfo/radext</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------090409010301090200040308--