To: [email-masked]
Date: Fri, 12 Feb 2010 23:12:52 -0000

> There we're in complete agreement. However, I view the need=20
> to support this sort of trust path discovery as very much a=20
> next stage issue. The rest of the project seems squarely in=20
> the category of engineering work.

Agreed. It would be nice to have a story for 3 to 5 years hence, but as
you say it is important that we focus on engineering solutions to
demonstrable problems of today. I will try to control my enthusiasm for
fixing tomorrow's poorly-defined problems :-)

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

Date: Fri, 12 Feb 2010 22:10:50 -0000
To: [email-masked]
> I think we're on the same page regarding actors. I didn't=20
> see anything new in your definition of actors.

That's good. What followed that is the brain dump, and so I'm not too
surprised that you raise a number of issues with that.

I understand, in particular, your skepticism concerning trust path
discovery. I guess this boils down to personal opinion about the likely
future scale of federated systems. You're probably right that we could
live without trust path discovery purely within the European Higher
Education community over the next 2 or 3 years. However - on the
evidence of the adoption of federated identity within the HE community -
I believe that we're in the early stages of exponential growth. While
the absolute numbers are nowhere near Internet-scale at the moment, I
believe that it's only a matter of time. It will escape the petri dishes
of .gov, .edu, large .com, etc, and it I think it would be prudent to be
prepared.

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  4 01:14:54 2012
Date: Wed, 04 Jan 2012 10:14:48 +0100
From: Alejandro Perez Mendez <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [abfab] Fwd: [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted

This is a multi-part message in MIME format.
--------------040203070409080707090405
Content-Type: multipart/alternative;
 boundary="------------000606070000080507080005"

--------------000606070000080507080005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

FYI

-------- Mensaje original --------
Asunto: 	[Ietf-krb-wg] FYI: New version of 
draft-perez-krb-wg-gss-preauth submitted
Fecha: 	Wed, 04 Jan 2012 10:13:42 +0100
De: 	Alejandro Perez Mendez <[email-masked]>
Para: 	[email-masked] <[email-masked]>

Dear all,

We have submitted a new version of draft-perez-krb-wg-gss-preauth 
(pre-authentication mechanism for Kerberos based on the GSS-API). The 
abstract of the document is the following:

    This document describes a pre-authentication mechanism for Kerberos
    based on the Generic Security Service Application Program Interface
    (GSS-API), which allows a Key Distribution Center (KDC) to
    authenticate clients by using any GSS mechanism.

Changes include:

  * Added motivation section indicating why this is required.
  * Added summary of the dicussion about statefull vs. stateless of the
    KDC when using the GSS-API.

You can access the document following this link:
http://www.ietf.org/id/draft-perez-krb-wg-gss-preauth-01.txt

Best regards,
Alejandro

--------------000606070000080507080005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    FYI<br>
    <br>
    -------- Mensaje original --------
    <table class="moz-email-headers-table" border="0" cellpadding="0"
      cellspacing="0">
      <tbody>
        <tr>
          <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Asunto: </th>
          <td>[Ietf-krb-wg] FYI: New version of
            draft-perez-krb-wg-gss-preauth submitted</td>
        </tr>
        <tr>
          <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Fecha: </th>
          <td>Wed, 04 Jan 2012 10:13:42 +0100</td>
        </tr>
        <tr>
          <th nowrap="nowrap" valign="BASELINE" align="RIGHT">De: </th>
          <td>Alejandro Perez Mendez <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
        </tr>
        <tr>
          <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Para: </th>
          <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
            <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
        </tr>
      </tbody>
    </table>
    <br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    Dear all, <br>
    <br>
    We have submitted a new version of draft-perez-krb-wg-gss-preauth
    (pre-authentication mechanism for Kerberos based on the GSS-API).
    The abstract of the document is the following: <br>
    <br>
    &nbsp;&nbsp; This document describes a pre-authentication mechanism for
    Kerberos <br>
    &nbsp;&nbsp; based on the Generic Security Service Application Program
    Interface <br>
    &nbsp;&nbsp; (GSS-API), which allows a Key Distribution Center (KDC) to <br>
    &nbsp;&nbsp; authenticate clients by using any GSS mechanism. <br>
    <br>
    Changes include:<br>
    <ul>
      <li>Added motivation section indicating why this is required.</li>
      <li>Added summary of the dicussion about statefull vs. stateless
        of the KDC when using the GSS-API.<br>
      </li>
    </ul>
    <br>
    You can access the document following this link:<br>
    <a moz-do-not-send="true" class="moz-txt-link-freetext"
      href="http://www.ietf.org/id/draft-perez-krb-wg-gss-preauth-01.txt">http://www.ietf.org/id/draft-perez-krb-wg-gss-preauth-01.txt</a>
    <br>
    <br>
    Best regards, <br>
    Alejandro <br>
    <br>
  </body>
</html>

--------------000606070000080507080005--

--------------040203070409080707090405
Content-Type: text/plain;
 name="Parte del mensaje adjunto"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Parte del mensaje adjunto"

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

--------------040203070409080707090405--

From [email-masked]  Wed Jan  4 01:42:56 2012
From: Josh Howlett <[email-masked]>
To: Alejandro Perez Mendez <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 4 Jan 2012 09:42:53 +0000
Accept-Language: en-GB, en-US
Subject: Re: [abfab] Fwd: [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted

Hi Alex,

Thanks for the update.

>    Changes include:
>=20=20=20=20
>=20=20=20=20=20=20
>* Added motivation section indicating why this is required.

This is a definitely a good addition; however, I don't believe that it is
complete. Ideally I think it needs to consider the questions that I raised
previously in the context of the previous discussion that Sam initiated
about generic gss pre-auth versus gss-eap pre-auth:

> What are the practical benefits of a generic gss pre-auth mechanism when
> Kerberos pre-auth itself provides an extensible framework? I can see that
> there is value in the re-using deployed gss mechanisms if this avoids
> having to create functionally-equivalent but redundant pre-auth
>mechanisms
> in the case where an equivalent gss mechanism already exists, but are
> there really so many of these that this is a compelling argument? It
> sounds as though there is potentially a trade-off that we could make
> between complexity and generality.

FWIW I haven't developed an opinion on these yet, but I would be
interested to hear if you have any...

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Wed Jan  4 01:43:30 2012
Date: Wed, 04 Jan 2012 10:43:25 +0100
From: Alejandro Perez Mendez <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt

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

FYI.

We have submitted this draft to RADEXT WG. It aims to overcome the 4K 
limit per packet in RADIUS. It enables the fragmentation of any RADIUS 
attribute across several RADIUS packets.

http://www.ietf.org/id/draft-perez-radext-radius-fragmentation-00.txt

Regards,
Alejandro

-------- Mensaje original --------
Asunto: 	New Version Notification for 
draft-perez-radext-radius-fragmentation-00.txt
Fecha: 	Wed, 04 Jan 2012 01:21:53 -0800
De: 	[email-masked]
Para: 	[email-masked]

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

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 00
Title:		 Fragmentation support across RADIUS packets
Creation date:	 2012-01-04
WG ID:		 Individual Submission
Number of pages: 10

Abstract:
    This document describes a mechanism providing fragmentation support
    of RADIUS attributes across several RADIUS packets.  This is intended
    to support attributes that exceed the 4 KB limit per RADIUS packet.

The IETF Secretariat

--------------020902050405090409000109
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">
    FYI.<br>
    <br>
    We have submitted this draft to RADEXT WG. It aims to overcome the
    4K limit per packet in RADIUS. It enables the fragmentation of any
    RADIUS attribute across several RADIUS packets.<br>
    <br>
<a class="moz-txt-link-freetext" href="http://www.ietf.org/id/draft-perez-radext-radius-fragmentation-00.txt">http://www.ietf.org/id/draft-perez-radext-radius-fragmentation-00.txt</a><br>
    <br>
    Regards,<br>
    Alejandro<br>
    <br>
    -------- Mensaje original --------
    <table class="moz-email-headers-table" border="0" cellpadding="0"
      cellspacing="0">
      <tbody>
        <tr>
          <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Asunto: </th>
          <td>New Version Notification for
            draft-perez-radext-radius-fragmentation-00.txt</td>
        </tr>
        <tr>
          <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Fecha: </th>
          <td>Wed, 04 Jan 2012 01:21:53 -0800</td>
        </tr>
        <tr>
          <th nowrap="nowrap" valign="BASELINE" align="RIGHT">De: </th>
          <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
        </tr>
        <tr>
          <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Para: </th>
          <td><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-00.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 00
Title:		 Fragmentation support across RADIUS packets
Creation date:	 2012-01-04
WG ID:		 Individual Submission
Number of pages: 10

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS attributes across several RADIUS packets.  This is intended
   to support attributes that exceed the 4 KB limit per RADIUS packet.

The IETF Secretariat
</pre>
  </body>
</html>

--------------020902050405090409000109--

From [email-masked]  Wed Jan  4 01:56:47 2012
Date: Wed, 04 Jan 2012 10:56:38 +0100
From: Alejandro Perez Mendez <[email-masked]>
To: Josh Howlett <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Fwd: [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted

Hi Josh,

> Hi Alex,
>
> Thanks for the update.
>
>
>>     Changes include:
>>
>>
>> * Added motivation section indicating why this is required.
> This is a definitely a good addition; however, I don't believe that it is
> complete. Ideally I think it needs to consider the questions that I raised
> previously in the context of the previous discussion that Sam initiated
> about generic gss pre-auth versus gss-eap pre-auth:
>
>> What are the practical benefits of a generic gss pre-auth mechanism when
>> Kerberos pre-auth itself provides an extensible framework? I can see that
>> there is value in the re-using deployed gss mechanisms if this avoids
>> having to create functionally-equivalent but redundant pre-auth
>> mechanisms
>> in the case where an equivalent gss mechanism already exists, but are
>> there really so many of these that this is a compelling argument? It
>> sounds as though there is potentially a trade-off that we could make
>> between complexity and generality.
>
> FWIW I haven't developed an opinion on these yet, but I would be
> interested to hear if you have any...

since the principal final purpose of this draft (in conjunction with the 
other one submitted to the ABFAB WG) is to enable the KDC to 
authenticate users based on the GSS-EAP mechanism, I don't see any 
advantage in transporting GSS tokens on top of FAST. It adds an 
additional an unnecessary layer, since nor GSS-API nor EAP assume any 
kind of secure transport.

Said that, the draft specifies that you can use it on top of FAST if 
that is more convenient for your requirements, nothing precludes it. 
Though, of course, that is not mandatory.

Besides, as I see it, this draft does follow the indications of the 
pre-authentication framework to define new pre-authentication mechanism. 
What it does not do is to define a FAST factor, but IMO those are 
different things.

Hope this clarifies something.

Best regards,
Alejandro

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

From [email-masked]  Wed Jan  4 06:19:46 2012
Date: Wed, 04 Jan 2012 09:19:14 -0500
From: Alan DeKok <[email-masked]>
To: Alejandro Perez Mendez <[email-masked]>
Cc: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] Fwd: New Version Notification for	draft-perez-radext-radius-fragmentation-00.txt

Alejandro Perez Mendez wrote:
> This motivation of this document comes from the necessity in the ABFAB
> WG of sending SAML Messages transported into RADIUS attributes. These
> SAML Messages can potentially be bigger than 4 KB, thus a mechanism to
> fragment them is required.

  My $0.02 after a quick read, this stood out:

---
Chunked-Attribute attribute.

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type (TBA)  |  Length       |      Ext-Type                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Total-Attribute-Length      |     Start-Position            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          End-Position         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
   Ext-Type

      Type of the attribute that is being chunked.  This field is
      encoded as an Ext-Type value, as described in
      [I-D.ietf-radext-extended-attributes], to be compatible with
      extended attributes.
----

  That won't work.  The type/ext-type is used to uniquely identify an
attribute.  As the RFC6158 says, the interpretation of the attribute is
based solely on the type code(s).  What you're doing above is changing
the meaning of the attribute based on its length.

  That's difficult, if not impossible, to do correctly.

  Attributes can also occur multiple times in a packet, with different
values.  e.g. Proxy-State.  The chunked encoding method should support
that, too.

  Perhaps another solution would be to leverage the "flags" field.  If a
particular bit is 1, then the attribute contains 4 32-bit fields
immediately after the "flags" field:

	identifier	for this attribute.  Allows multi-values
	total length	of the fragments with "identifier"
	start		as per above
	end		as per above

  If this document is published soon after the extensions document, then
it has a better likelihood of being implemented.

  Alan DeKok.

From [email-masked]  Wed Jan  4 10:21:09 2012
Date: Wed, 04 Jan 2012 19:21:02 +0100
From: DIEGO LOPEZ GARCIA <[email-masked]>
To: Alan DeKok <[email-masked]>
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New Version Notification	for	draft-perez-radext-radius-fragmentation-00.txt

From [email-masked]  Thu Jan  5 00:29:02 2012
Date: Thu, 05 Jan 2012 09:28:52 +0100
From: Alejandro Perez Mendez <[email-masked]>
To: DIEGO LOPEZ GARCIA <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New Version Notification	for draft-perez-radext-radius-fragmentation-00.txt

Hi Alan, Diego,

> Hi Alan,
>
> On 4 Jan 2012, at 15:19 , Alan DeKok wrote:
>>   That won't work.  The type/ext-type is used to uniquely identify an
>> attribute.  As the RFC6158 says, the interpretation of the attribute is
>> based solely on the type code(s).  What you're doing above is changing
>> the meaning of the attribute based on its length.
>>
>>   That's difficult, if not impossible, to do correctly.
> I'm afraid there is a misunderstanding. The Chunked-Atrribute is an attribute on its own that contains only a reference to the attribute being chunked. It has to appear in all the packets containing chunks of attributes, as many as attributes they refer to. Chunks are intended to be encoded following the usual encoding methods.
>
> It is true that the layout and the field names used in it are misleading (instead of "Ext-Type" we should call it "Type-ID" or "Attribute-ID" or something similar), and you are right in that the way of specifying this identifier should be better aligned with the way of coding types and extended types.

You are right. Maybe the name was not the best. We gave it 2 bytes in 
order to be able to refer  not only to "standard" RADIUS attributes, but 
also to extended attributes. But after your explanation, I think that we 
could either include both references (Type/Ext-Type, 3 bytes in total) 
or just refer only to the Type (1 byte). From the point of view of 
fragmentation, it could be enough to know that the attribute (e.g. 
Vendor-Specific) is fragmented, no matter the kind of Vendor Specific 
attribute we are dealing with.

>
>>   Attributes can also occur multiple times in a packet, with different
>> values.  e.g. Proxy-State.
> You are right. That should be addressed. A simple proposal could follow these rules:
>
> * Chunked-Attribute must appear before the attribute it refers to in the packet
Right.

>
> * If an attribute occurs multiple times in a request/response (we cannot speak here of "a packet") chunks for only one of the occurrences, associated to the corresponding Chunked-Attribute, are allowed in a given packet

I don't see why. If you find something line (CHUNKED, X, X, X, CHUNCKED, 
X, X) you can easily assumed that the first [X,X,X] is one attribute 
(X1) and the second [X,X] a different one (X2), as the five Xs do not 
appear in sequence.

Note that this situation can only occur in the packet where the last 
CHUNK of the first attribute coincide with the first CHUNK of the second 
attribute.
In the example, X1 and X2 are different attributes of type X.

PACKET1: CHUNCKED, X1, X1, X1, X1, X1, X1, X1, X1, X1
PACKET2: CHUNCKED, X1, X1, CHUNCKED, X2, X2, X2, X2
PACKET3: CHUNCKED, X2, X2

>
> * Non-fragmented values for this attribute can appear in any packet, but always before the Chunked-Attribute that refers to it

I kinda don't like this one. We could force the inclusion of the 
CHUNCKED attribute in these situations, even when no needed. Example: 
CHUNCKED(type=X, total_length=200, start_pos=0, end_pos=199). As 
explained above, this would insert an attribute (the CHUNCKED attribute) 
between both occurrences of attribute X, thus breaking the misleading 
sequence.

>
> * As many Chunked-Attribute (and referred attributes) may appear in a given packet as necessary.

Right, as depicted in the examples above.

Best regards,
Alejandro

>
>>   If this document is published soon after the extensions document, then
>> it has a better likelihood of being implemented.
> Good point!
>
> Be goode,
>
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
> Telefonica I+D
>
> e-mail: [email-masked]
> Tel:      +34 913 129 041
> Mobile: +34 682 051 091
> -----------------------------------------
>
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx

From [email-masked]  Thu Jan  5 08:06:10 2012
Date: Thu, 05 Jan 2012 17:05:46 +0100
From: Alan DeKok <[email-masked]>
To: DIEGO LOPEZ GARCIA <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New Version Notification	for	draft-perez-radext-radius-fragmentation-00.txt

DIEGO LOPEZ GARCIA wrote:
> I'm afraid there is a misunderstanding. The Chunked-Atrribute is an attribute on its own that contains only a reference to the attribute being chunked. It has to appear in all the packets containing chunks of attributes, as many as attributes they refer to. Chunks are intended to be encoded following the usual encoding methods.

  IMHO, that kind of solution should be avoided.

> * Chunked-Attribute must appear before the attribute it refers to in the packet

  RADIUS doesn't impose ordering on attributes of different type.
That's a strong reason to integrate chunking inside of the attribute format.

> * If an attribute occurs multiple times in a request/response (we cannot speak here of "a packet") chunks for only one of the occurrences, associated to the corresponding Chunked-Attribute, are allowed in a given packet

  Why?  RADIUS allows for multiple attributes of the same type, with
different value.

> * Non-fragmented values for this attribute can appear in any packet, but always before the Chunked-Attribute that refers to it

  See comment about attribute ordering.

> * As many Chunked-Attribute (and referred attributes) may appear in a given packet as necessary.

  I think this document is intended to solve one *very* limited
use-case.  It doesn't address any more general case.  It relies on fixed
attribute ordering, which is explicitly not required.

  I gave comments on your approach.  Do you have any comments on my
proposed alternative?  It would seem to (a) solve the same problem, and
(b) have none of the limitations.

  Alan DeKok.

From [email-masked]  Thu Jan  5 08:10:31 2012
Date: Thu, 05 Jan 2012 17:09:51 +0100
From: Alan DeKok <[email-masked]>
To: Alejandro Perez Mendez <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New Version Notification	for draft-perez-radext-radius-fragmentation-00.txt

Alejandro Perez Mendez wrote:
> But after your explanation, I think that we
> could either include both references (Type/Ext-Type, 3 bytes in total)
> or just refer only to the Type (1 byte). From the point of view of
> fragmentation, it could be enough to know that the attribute (e.g.
> Vendor-Specific) is fragmented, no matter the kind of Vendor Specific
> attribute we are dealing with.

  I don't understand how that would work.  My previous proposal to use a
flag field could potentially work for the new extended VSA format, too.

> I don't see why. If you find something line (CHUNKED, X, X, X, CHUNCKED,
> X, X) you can easily assumed that the first [X,X,X] is one attribute
> (X1) and the second [X,X] a different one (X2), as the five Xs do not
> appear in sequence.

  Which relies on attribute ordering.  That's a fatal flaw for any proposal.

  Alan DeKok.

From [email-masked]  Mon Jan  9 00:55:09 2012
Date: Mon, 09 Jan 2012 09:55:05 +0100
From: DIEGO LOPEZ GARCIA <[email-masked]>
To: Alan DeKok <[email-masked]>
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New Version Notification	for	draft-perez-radext-radius-fragmentation-00.txt

On 5 Jan 2012, at 17:05 , Alan DeKok wrote:
>> * Chunked-Attribute must appear before the attribute it refers to in the=
 packet
>
>  RADIUS doesn't impose ordering on attributes of different type.
> That's a strong reason to integrate chunking inside of the attribute form=
at.

Ordering constraints here are applied to related attributes. I don't see wh=
y this would go beyond the requirements imposed by the current document on =
extended attributes, as the recent discussion on it shows.

>> * If an attribute occurs multiple times in a request/response (we cannot=
 speak here of "a packet") chunks for only one of the occurrences, associat=
ed to the corresponding Chunked-Attribute, are allowed in a given packet
>
>  Why?  RADIUS allows for multiple attributes of the same type, with
> different value.
>
>> * Non-fragmented values for this attribute can appear in any packet, but=
 always before the Chunked-Attribute that refers to it
>
>  See comment about attribute ordering.

On these issues, I agree with the latest proposal from Alejandro, that rath=
er simplifies ordering constraints.

>> * As many Chunked-Attribute (and referred attributes) may appear in a gi=
ven packet as necessary.
>
>  I think this document is intended to solve one *very* limited
> use-case.  It doesn't address any more general case.

The use case is that of an AuthN/AuthZ infrastructure that requires the exc=
hange of data longer that the one that fits in a RADIUS packet, and intende=
d to rely on a single trust infrastructure. I do think it is general enough=
.

>  It relies on fixed attribute ordering, which is explicitly not required.

It relies in the usage of an specific attribute that defines the interpreta=
tion of the values of another attribute. Ordering rules probably could be r=
elaxed, but at the price of more complicated processing rules.

> I gave comments on your approach.  Do you have any comments on my
> proposed alternative?  It would seem to (a) solve the same problem, and
> (b) have none of the limitations.

One of the main goals of the proposal was to be compatible with current mec=
hanisms for attribute encoding inside the packet (EAP-style, extended attri=
butes=85) and deal only with values spanning more than one packet. Using yo=
ur alternative would break this compatibility.

Be goode,
--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

From [email-masked]  Mon Jan  9 01:59:30 2012
Date: Mon, 09 Jan 2012 10:58:58 +0100
From: Alan DeKok <[email-masked]>
To: DIEGO LOPEZ GARCIA <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New Version	Notification	for	draft-perez-radext-radius-fragmentation-00.txt

DIEGO LOPEZ GARCIA wrote:
> Ordering constraints here are applied to related attributes.

  RADIUS doesn't work that way.

  There are hundreds of thousands of deployments which assume that
ordering constraints do NOT apply to related attributes.  Changing such
a fundamental part of the protocol is impossible.

> I don't see why this would go beyond the requirements imposed by the current document on extended attributes, as the recent discussion on it shows.

  I pointed you to RFC 2865, and explained why that restriction is
impossible.  Please go read those messages again.

> It relies in the usage of an specific attribute that defines the interpretation of the values of another attribute. Ordering rules probably could be relaxed, but at the price of more complicated processing rules.

  It relies on behavior which is mandated as NOT being part of RADIUS.

>> I gave comments on your approach.  Do you have any comments on my
>> proposed alternative?  It would seem to (a) solve the same problem, and
>> (b) have none of the limitations.
> 
> One of the main goals of the proposal was to be compatible with current mechanisms for attribute encoding inside the packet (EAP-style, extended attributes�) and deal only with values spanning more than one packet. Using your alternative would break this compatibility.

  Nonsense.

  It is incompatible with existing methods like EAP-Message.  Those
*already* have semantics defined.  Changing them by adding a "Chunked
Attribute" is impossible.  The extended format hasn't been deployed, so
compatibility with it is impossible.

  My proposal was to allow *new* attributes to span multiple packets.

  Changing the rules on attribute ordering is impossible.  Don't even try.

  Changing the meaning of existing attributes to allow more than 253
octets of data is impossible.  Don't even try.

  Alan DeKok.

From [email-masked]  Mon Jan  9 02:03:28 2012
Date: Mon, 09 Jan 2012 11:03:00 +0100
From: Alan DeKok <[email-masked]>
To: DIEGO LOPEZ GARCIA <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New	Version	Notification	for	draft-perez-radext-radius-fragmentation-00.txt

Alan DeKok wrote:
>   There are hundreds of thousands of deployments which assume that
> ordering constraints do NOT apply to related attributes.

  Make that "UNrelated attributes"

  Alan DeKok.

From [email-masked]  Mon Jan  9 03:05:19 2012
Date: Mon, 09 Jan 2012 12:05:11 +0100
From: DIEGO LOPEZ GARCIA <[email-masked]>
To: Alan DeKok <[email-masked]>
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New Version	Notification	for	draft-perez-radext-radius-fragmentation-00.txt

On 9 Jan 2012, at 10:58 , Alan DeKok wrote:
>   Changing the rules on attribute ordering is impossible.  Don't even try=
.

Nodoby is trying to do so. We've probably not explained well the rules for =
CHUNKED and the related attribute. Let us get back to it with a (hopefully)=
 clearer proposal.

>  Changing the meaning of existing attributes to allow more than 253
> octets of data is impossible.  Don't even try.

Nobody is trying to do so either, but to achieve the goal of allowing attri=
butes to span several packets in the simplest and cleanest way possible.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

From [email-masked]  Mon Jan  9 03:21:10 2012
Date: Mon, 09 Jan 2012 12:20:58 +0100
From: Alejandro Perez Mendez <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New Version	Notification	for	draft-perez-radext-radius-fragmentation-00.txt

Hi Alan,

thanks for the clarifications and hints. We will think about them and 
their implications, and try to modify the proposal to make it address 
all the requirements.

Regards,
Alejandro

El 09/01/12 10:58, Alan DeKok escribió:
> DIEGO LOPEZ GARCIA wrote:
>> Ordering constraints here are applied to related attributes.
>    RADIUS doesn't work that way.
>
>    There are hundreds of thousands of deployments which assume that
> ordering constraints do NOT apply to related attributes.  Changing such
> a fundamental part of the protocol is impossible.
>
>> I don't see why this would go beyond the requirements imposed by the current document on extended attributes, as the recent discussion on it shows.
>    I pointed you to RFC 2865, and explained why that restriction is
> impossible.  Please go read those messages again.
>
>> It relies in the usage of an specific attribute that defines the interpretation of the values of another attribute. Ordering rules probably could be relaxed, but at the price of more complicated processing rules.
>    It relies on behavior which is mandated as NOT being part of RADIUS.
>
>>> I gave comments on your approach.  Do you have any comments on my
>>> proposed alternative?  It would seem to (a) solve the same problem, and
>>> (b) have none of the limitations.
>> One of the main goals of the proposal was to be compatible with current mechanisms for attribute encoding inside the packet (EAP-style, extended attributes…) and deal only with values spanning more than one packet. Using your alternative would break this compatibility.
>    Nonsense.
>
>    It is incompatible with existing methods like EAP-Message.  Those
> *already* have semantics defined.  Changing them by adding a "Chunked
> Attribute" is impossible.  The extended format hasn't been deployed, so
> compatibility with it is impossible.
>
>    My proposal was to allow *new* attributes to span multiple packets.
>
>    Changing the rules on attribute ordering is impossible.  Don't even try.
>
>    Changing the meaning of existing attributes to allow more than 253
> octets of data is impossible.  Don't even try.
>
>    Alan DeKok.

From [email-masked]  Mon Jan 16 05:43:46 2012
Date: Mon, 16 Jan 2012 14:43:28 +0100
From: Alejandro Perez Mendez <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New Version	Notification	for	draft-perez-radext-radius-fragmentation-00.txt

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

Hi Alan, all,

we have been thinking on this topic and we realized that a different 
approach could be more convenient to handle inter-packet fragmentation 
than our first proposal.

Taking draft-ietf-radext-radius-extensions as a base, we can assume that 
intra-packet fragmentation is already handled via the M flag. We can 
also assume that order between fragments is preserved when following 
draft-ietf-radext-radius-extensions. This may not be true now with the 
current spec (as Peter pointed out), but we can assume this will be 
solved somehow in the future (e.g. including offset field).

We propose the following:
1) Extended flag attributes are used to fragment big RADIUS attributes, 
as specified in draft-ietf-radext-radius-extensions.
2) If a fragmented attribute cannot be completely included into the 
remaining space of a 4KB RADIUS packet, it is truncated, that is, only 
the fragments that fit into the free space of the packet to be sent are 
included. It is also included a new RADIUS attribute, called 
"More-Data-Pending". The presence of this attribute indicates to the 
receiver that the RADIUS packet is not complete, and more data MUST be 
received from the sender before processing any of the received attributes.

Note that it is possible (and very likely), that the last fragment of a 
truncated attribute in a RADIUS packet has the M flag set. This case 
would be against what it is stated in 
draft-ietf-radext-radius-extensions. Nevertheless, we think this 
restriction can be easily relaxed when using the more-data-pending 
attribute. If it is present, it is allowed that the last fragment have 
the bit M set, which means the attribute is truncated. A good side 
effect of this is that if a  server does not understand 
more-data-pending and its semantics, a truncated attribute will be shown 
as an invalid attribute, and not taking the truncated portion as the whole.

The rest of the attribute fragments will be sent in successive packets, 
following the same procedure, using as many RADIUS packets as needed to 
transmit the required information.

Let me illustrate this with an example, where a RADIUS client sends a 
packet with a size > 4 KB (to make it simpler, we assume each RADIUS 
packet can include 8 RADIUS attributes/fragments, instead of using 
bytes). Flag M is indicated as [M]. Data1, Data2, Data3... indicate 
successive fragments of the attribute Data.

The RADIUS client wants to send the following RADIUS packet:

Access-Request = User-Name, Calling-Station-Id, Data1[M], Data2[M], 
Data3[M], Data4[M], Data5[M], Data6[M], Data7[M], Data8[M], Data9[M], 
Data10, Other1[M], Other2[M], Other3

As only 8 attributes can be included in the packet, the RADIUS client 
truncates "Data" to fit into the packet, and includes the 
More-Data-Pending attribute:

Acess-Request1 = User-Name, Calling-Station-Id, Data1[M], Data2[M], 
Data3[M], Data4[M], Data5[M], More-Data-Pending

When the server receives the RADIUS packet containing the 
More-Data-Pending attribute, the processing of the packet is left until 
all the pending data is received. The pending data is requested by means 
of an Access-Challenge packet, using the State attribute to tie together 
this response with the subsequent request from the client.

Access-Challenge1 = State1

The client continues sending the data until another RADIUS packet is 
completed, including again the attribute More-Data-Pending

Acess-Request2 = State1, Data6[M], Data7[M], Data8[M], Data9[M], Data10, 
Other1[M], More-Data-Pending

The server stores the attributes into the state associated to State1 and 
replies:

Access-Challenge1 = State2

Finally, the client sends the last fragments of the original packet:

Access-Request3 = State2, Other2[M], Other3

The server now can process the totality of the received attributes as if 
they all had been received into a single RADIUS packet of more than 4 KB

The case where the server sends a fragmented packet to the client is 
very similar and makes no sense to expli

Best regards,
Alejandro

El 09/01/12 12:20, Alejandro Perez Mendez escribió:
> Hi Alan,
>
> thanks for the clarifications and hints. We will think about them and 
> their implications, and try to modify the proposal to make it address 
> all the requirements.
>
> Regards,
> Alejandro
>
> El 09/01/12 10:58, Alan DeKok escribió:
>> DIEGO LOPEZ GARCIA wrote:
>>> Ordering constraints here are applied to related attributes.
>>    RADIUS doesn't work that way.
>>
>>    There are hundreds of thousands of deployments which assume that
>> ordering constraints do NOT apply to related attributes.  Changing such
>> a fundamental part of the protocol is impossible.
>>
>>> I don't see why this would go beyond the requirements imposed by the 
>>> current document on extended attributes, as the recent discussion on 
>>> it shows.
>>    I pointed you to RFC 2865, and explained why that restriction is
>> impossible.  Please go read those messages again.
>>
>>> It relies in the usage of an specific attribute that defines the 
>>> interpretation of the values of another attribute. Ordering rules 
>>> probably could be relaxed, but at the price of more complicated 
>>> processing rules.
>>    It relies on behavior which is mandated as NOT being part of RADIUS.
>>
>>>> I gave comments on your approach.  Do you have any comments on my
>>>> proposed alternative?  It would seem to (a) solve the same problem, 
>>>> and
>>>> (b) have none of the limitations.
>>> One of the main goals of the proposal was to be compatible with 
>>> current mechanisms for attribute encoding inside the packet 
>>> (EAP-style, extended attributes…) and deal only with values spanning 
>>> more than one packet. Using your alternative would break this 
>>> compatibility.
>>    Nonsense.
>>
>>    It is incompatible with existing methods like EAP-Message.  Those
>> *already* have semantics defined.  Changing them by adding a "Chunked
>> Attribute" is impossible.  The extended format hasn't been deployed, so
>> compatibility with it is impossible.
>>
>>    My proposal was to allow *new* attributes to span multiple packets.
>>
>>    Changing the rules on attribute ordering is impossible.  Don't 
>> even try.
>>
>>    Changing the meaning of existing attributes to allow more than 253
>> octets of data is impossible.  Don't even try.
>>
>>    Alan DeKok.
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

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

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Alan, all,<br>
    <br>
    we have been thinking on this topic and we realized that a different
    approach could be more convenient to handle inter-packet
    fragmentation than our first proposal.<br>
    <br>
    Taking draft-ietf-radext-radius-extensions as a base, we can assume
    that intra-packet fragmentation is already handled via the M flag.
    We can also assume that order between fragments is preserved when
    following draft-ietf-radext-radius-extensions. This may not be true
    now with the current spec (as Peter pointed out), but we can assume
    this will be solved somehow in the future (e.g. including offset
    field).<br>
    <br>
    We propose the following:<br>
    1) Extended flag attributes are used to fragment big RADIUS
    attributes, as specified in draft-ietf-radext-radius-extensions.<br>
    2) If a fragmented attribute cannot be completely included into the
    remaining space of a 4KB RADIUS packet, it is truncated, that is,
    only the fragments that fit into the free space of the packet to be
    sent are included. It is also included a new RADIUS attribute,
    called "More-Data-Pending". The presence of this attribute indicates
    to the receiver that the RADIUS packet is not complete, and more
    data MUST be received from the sender before processing any of the
    received attributes.<br>
    <br>
    Note that it is possible (and very likely), that the last fragment
    of a truncated attribute in a RADIUS packet has the M flag set. This
    case would be against what it is stated in
    draft-ietf-radext-radius-extensions. Nevertheless, we think this
    restriction can be easily relaxed when using the more-data-pending
    attribute. If it is present, it is allowed that the last fragment
    have the bit M set, which means the attribute is truncated. A good
    side effect of this is that if a  server does not understand
    more-data-pending and its semantics, a truncated attribute will be
    shown as an invalid attribute, and not taking the truncated portion
    as the whole.<br>
    <br>
    The rest of the attribute fragments will be sent in successive
    packets, following the same procedure, using as many RADIUS packets
    as needed to transmit the required information.<br>
    <br>
    Let me illustrate this with an example, where a RADIUS client sends
    a packet with a size &gt; 4 KB (to make it simpler, we assume each
    RADIUS packet can include 8 RADIUS attributes/fragments, instead of
    using bytes). Flag M is indicated as [M]. Data1, Data2, Data3...
    indicate successive fragments of the attribute Data.<br>
    <br>
    The RADIUS client wants to send the following RADIUS packet:<br>
    <br>
    Access-Request = User-Name, Calling-Station-Id, Data1[M], Data2[M],
    Data3[M], Data4[M], Data5[M], Data6[M], Data7[M], Data8[M],
    Data9[M], Data10, Other1[M], Other2[M], Other3<br>
    <br>
    <br>
    As only 8 attributes can be included in the packet, the RADIUS
    client truncates "Data" to fit into the packet, and includes the
    More-Data-Pending attribute:<br>
    <br>
    Acess-Request1 = User-Name, Calling-Station-Id, Data1[M], Data2[M],
    Data3[M], Data4[M], Data5[M], More-Data-Pending<br>
    <blockquote> <br>
    </blockquote>
    When the server receives the RADIUS packet containing the
    More-Data-Pending attribute, the processing of the packet is left
    until all the pending data is received. The pending data is
    requested by means of an Access-Challenge packet, using the State
    attribute to tie together this response with the subsequent request
    from the client.<br>
    <br>
    Access-Challenge1 = State1<br>
    <blockquote> <br>
    </blockquote>
    The client continues sending the data until another RADIUS packet is
    completed, including again the attribute More-Data-Pending<br>
    <br>
    Acess-Request2 = State1, Data6[M], Data7[M], Data8[M], Data9[M],
    Data10, Other1[M], More-Data-Pending<br>
    <blockquote> <br>
      <br>
    </blockquote>
    The server stores the attributes into the state associated to State1
    and replies:<br>
    <br>
    Access-Challenge1 = State2<br>
    <blockquote> <br>
    </blockquote>
    Finally, the client sends the last fragments of the original packet:<br>
    <br>
    Access-Request3 = State2, Other2[M], Other3<br>
    <blockquote> <br>
    </blockquote>
    The server now can process the totality of the received attributes
    as if they all had been received into a single RADIUS packet of more
    than 4 KB<br>
    <br>
    The case where the server sends a fragmented packet to the client is
    very similar and makes no sense to expli<br>
    <br>
    Best regards,<br>
    Alejandro<br>
    <br>
    El 09/01/12 12:20, Alejandro Perez Mendez escribió:
    <blockquote cite="mid:[email-masked]" type="cite">Hi Alan, <br>
      <br>
      thanks for the clarifications and hints. We will think about them
      and their implications, and try to modify the proposal to make it
      address all the requirements. <br>
      <br>
      Regards, <br>
      Alejandro <br>
      <br>
      El 09/01/12 10:58, Alan DeKok escribió: <br>
      <blockquote type="cite">DIEGO LOPEZ GARCIA wrote: <br>
        <blockquote type="cite">Ordering constraints here are applied to
          related attributes. <br>
        </blockquote>
           RADIUS doesn't work that way. <br>
        <br>
           There are hundreds of thousands of deployments which assume
        that <br>
        ordering constraints do NOT apply to related attributes. 
        Changing such <br>
        a fundamental part of the protocol is impossible. <br>
        <br>
        <blockquote type="cite">I don't see why this would go beyond the
          requirements imposed by the current document on extended
          attributes, as the recent discussion on it shows. <br>
        </blockquote>
           I pointed you to RFC 2865, and explained why that restriction
        is <br>
        impossible.  Please go read those messages again. <br>
        <br>
        <blockquote type="cite">It relies in the usage of an specific
          attribute that defines the interpretation of the values of
          another attribute. Ordering rules probably could be relaxed,
          but at the price of more complicated processing rules. <br>
        </blockquote>
           It relies on behavior which is mandated as NOT being part of
        RADIUS. <br>
        <br>
        <blockquote type="cite">
          <blockquote type="cite">I gave comments on your approach.  Do
            you have any comments on my <br>
            proposed alternative?  It would seem to (a) solve the same
            problem, and <br>
            (b) have none of the limitations. <br>
          </blockquote>
          One of the main goals of the proposal was to be compatible
          with current mechanisms for attribute encoding inside the
          packet (EAP-style, extended attributes…) and deal only with
          values spanning more than one packet. Using your alternative
          would break this compatibility. <br>
        </blockquote>
           Nonsense. <br>
        <br>
           It is incompatible with existing methods like EAP-Message. 
        Those <br>
        *already* have semantics defined.  Changing them by adding a
        "Chunked <br>
        Attribute" is impossible.  The extended format hasn't been
        deployed, so <br>
        compatibility with it is impossible. <br>
        <br>
           My proposal was to allow *new* attributes to span multiple
        packets. <br>
        <br>
           Changing the rules on attribute ordering is impossible. 
        Don't even try. <br>
        <br>
           Changing the meaning of existing attributes to allow more
        than 253 <br>
        octets of data is impossible.  Don't even try. <br>
        <br>
           Alan DeKok. <br>
      </blockquote>
      _______________________________________________ <br>
      abfab mailing list <br>
      <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
      <br>
      <a class="moz-txt-link-freetext"
        href="https://www.ietf.org/mailman/listinfo/abfab">https://www.ietf.org/mailman/listinfo/abfab</a>
      <br>
    </blockquote>
  </body>
</html>

--------------060904040002090608040905--

From [email-masked]  Mon Jan 16 06:24:55 2012
Date: Mon, 16 Jan 2012 15:24:23 +0100
From: Alan DeKok <[email-masked]>
To: Alejandro Perez Mendez <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New	Version	Notification	for	draft-perez-radext-radius-fragmentation-00.txt

Alejandro Perez Mendez wrote:
> We propose the following:
> 1) Extended flag attributes are used to fragment big RADIUS attributes,
> as specified in draft-ietf-radext-radius-extensions.

  That should be possible.

> 2) If a fragmented attribute cannot be completely included into the
> remaining space of a 4KB RADIUS packet, it is truncated, that is, only
> the fragments that fit into the free space of the packet to be sent are
> included. It is also included a new RADIUS attribute, called
> "More-Data-Pending". The presence of this attribute indicates to the
> receiver that the RADIUS packet is not complete, and more data MUST be
> received from the sender before processing any of the received attributes.

  I've had similar discussions with people off-list.

> Note that it is possible (and very likely), that the last fragment of a
> truncated attribute in a RADIUS packet has the M flag set. This case
> would be against what it is stated in
> draft-ietf-radext-radius-extensions. Nevertheless, we think this
> restriction can be easily relaxed when using the more-data-pending
> attribute. If it is present, it is allowed that the last fragment have
> the bit M set, which means the attribute is truncated. A good side
> effect of this is that if a  server does not understand
> more-data-pending and its semantics, a truncated attribute will be shown
> as an invalid attribute, and not taking the truncated portion as the whole.

  I'm wary of that, but it's a good start.  There may be additional
minor fixes which could make the fragmentation explicit rather than
implicit.

  I think this proposal would require a new document at minimum.  The
document would discuss how to implement the above proposal.  That means
that others could use this specification, even if they don't need
attributes longer than 4K.

  A separate document could document the >4K attributes.

  I'll see if I can write a short proposal to the radext list.  If it's
acceptable to the WG, I can put a draft together.

  Alan DeKok.

From [email-masked]  Mon Jan 16 07:30:31 2012
Date: Mon, 16 Jan 2012 16:30:15 +0100
From: Alejandro Perez Mendez <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New	Version	Notification	for	draft-perez-radext-radius-fragmentation-00.txt

Hi Alan,

> Alejandro Perez Mendez wrote:
>> We propose the following:
>> 1) Extended flag attributes are used to fragment big RADIUS attributes,
>> as specified in draft-ietf-radext-radius-extensions.
>    That should be possible.
>
>> 2) If a fragmented attribute cannot be completely included into the
>> remaining space of a 4KB RADIUS packet, it is truncated, that is, only
>> the fragments that fit into the free space of the packet to be sent are
>> included. It is also included a new RADIUS attribute, called
>> "More-Data-Pending". The presence of this attribute indicates to the
>> receiver that the RADIUS packet is not complete, and more data MUST be
>> received from the sender before processing any of the received attributes.
>    I've had similar discussions with people off-list.

that's good

>> Note that it is possible (and very likely), that the last fragment of a
>> truncated attribute in a RADIUS packet has the M flag set. This case
>> would be against what it is stated in
>> draft-ietf-radext-radius-extensions. Nevertheless, we think this
>> restriction can be easily relaxed when using the more-data-pending
>> attribute. If it is present, it is allowed that the last fragment have
>> the bit M set, which means the attribute is truncated. A good side
>> effect of this is that if a  server does not understand
>> more-data-pending and its semantics, a truncated attribute will be shown
>> as an invalid attribute, and not taking the truncated portion as the whole.
>    I'm wary of that, but it's a good start.  There may be additional
> minor fixes which could make the fragmentation explicit rather than
> implicit.

We also thought that a new flag "T" could indicate the attribute is 
truncated across several packets.

>    I think this proposal would require a new document at minimum.  The
> document would discuss how to implement the above proposal.  That means
> that others could use this specification, even if they don't need
> attributes longer than 4K.

Indeed, this proposal is not only for attributes longer than 4K, but to 
support that an attribute is fragmented across different packets, 
because the total length of the packet is longer than 4K.

That could happen even when the attribute is not very long, but it is 
placed at the end of the package.

>    A separate document could document the>4K attributes.

IMO support for attributes > 4K is a logic consequence of the 
fragmentation support given by our proposal.

>    I'll see if I can write a short proposal to the radext list.  If it's
> acceptable to the WG, I can put a draft together.

Precisely we were about to modify our document to reflect this, if the 
idea was reasonable. That was the intention of sending it first to the 
list, to see if there were objections before starting writing a new draft.

Regards,
Alejandro

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

From [email-masked]  Mon Jan 16 07:40:38 2012
Date: Mon, 16 Jan 2012 16:39:51 +0100
From: Alan DeKok <[email-masked]>
To: Alejandro Perez Mendez <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New	Version	Notification	for	draft-perez-radext-radius-fragmentation-00.txt

Alejandro Perez Mendez wrote:
> We also thought that a new flag "T" could indicate the attribute is
> truncated across several packets.

  That sounds good.

> Precisely we were about to modify our document to reflect this, if the
> idea was reasonable. That was the intention of sending it first to the
> list, to see if there were objections before starting writing a new draft.

  My notes about this are:

- the first Access-Accept must contain Service-Type = Authorize-Only
  *or* a new Servicer-Type = Additional-Authorization

  This means that the user is not given network access when the
  implementation does not support the new method.

- the first Access-Accept must contain a State attribute
  for is already required for use of Authorize-Only

- additional authorization attributes are received via a series
  of Access-Request / Access-Challenge

  - each Access-Request MUST contain Service-Type = Authorize-Only
    and a State

  - the State MUST change for each Access-Challenge response
    I can get into that later

- the final Access-Accept contains the real Service-Type
  for the user

  Alan DeKok.

From [email-masked]  Mon Jan 16 07:38:59 2012
Date: Mon, 16 Jan 2012 10:38:40 -0500
From: Dave Nelson <[email-masked]>
To: Alejandro Perez Mendez <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt

--20cf307f39ac42986204b6a702a3
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez <[email-masked]> wrote:

>
> We also thought that a new flag "T" could indicate the attribute is
> truncated across several packets.

Yeah.  I would favor the definition of another flag bit, rather than mixing
flags and "signal" attributes to accomplished related purposes.  It's just
more symmetrical.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

--20cf307f39ac42986204b6a702a3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez <span dir=3D"ltr">=
&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br></div>
We also thought that a new flag &quot;T&quot; could indicate the attribute =
is truncated across several packets.</blockquote><div><br></div><div>Yeah. =
=A0I would favor the definition of another flag bit, rather than mixing fla=
gs and &quot;signal&quot; attributes to accomplished related purposes. =A0I=
t&#39;s just more symmetrical.=A0</div>
</div><br>Regards,<br><br>Dave<br><br>David B. Nelson<br>Sr. Software Archi=
tect<br>Elbrys Networks, Inc.<br><a href=3D"http://www.elbrys.com" target=
=3D"_blank">www.elbrys.com</a><br>+1.603.570.2636<br>

--20cf307f39ac42986204b6a702a3--

From [email-masked]  Mon Jan 16 08:02:17 2012
Date: Mon, 16 Jan 2012 17:02:13 +0100
From: DIEGO LOPEZ GARCIA <[email-masked]>
To: Alan DeKok <[email-masked]>
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext]		New	Version	Notification	for	draft-perez-radext-radius-fragmentation-00.txt

From [email-masked]  Mon Jan 16 08:11:43 2012
Date: Mon, 16 Jan 2012 17:11:14 +0100
From: Alan DeKok <[email-masked]>
To: DIEGO LOPEZ GARCIA <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext]		New	Version	Notification	for	draft-perez-radext-radius-fragmentation-00.txt

DIEGO LOPEZ GARCIA wrote:>
> In the same spirit of keeping clarity, I'd say that Additional-Authorization would be more correct choice, unless adding a new Service-Type would somehow complicate adoption...

  I agree.

>>  - each Access-Request MUST contain Service-Type = Authorize-Only
>>    and a State
> 
> Or, respectively, Additional-Authorization, isn't it?

  The Access-Challenge should contain Additional-Authorization.  The
request should probably contain Authorize-Only.

>>  - the State MUST change for each Access-Challenge response
>>    I can get into that later
> 
> I can imagine this is with the intention of guaranteeing order and avoiding (or alleviating) MITM attacks, right?

  It's a way to guarantee ordering.  I'm not sure if MITM attacks are
anything we care about.  Every entity in the AAA system is trusted, and
the packets are signed to prevent non-AAA systems from modifying them..

  Alan DeKok.

From [email-masked]  Mon Jan 16 11:04:29 2012
From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 16 Jan 2012 20:04:19 +0100
To: Dave Nelson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt

--Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi Dave:

El 16/01/2012, a las 16:38, Dave Nelson escribi=F3:

> On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez <[email-masked]> =
wrote:
>=20
> We also thought that a new flag "T" could indicate the attribute is =
truncated across several packets.
>=20
> Yeah.  I would favor the definition of another flag bit, rather than =
mixing flags and "signal" attributes to accomplished related purposes.  =
It's just more symmetrical.=20

Just a clarification here. Our goal (authors of =
draft-perez-radext-radius-fragmentation-00.txt) is to enable a mechanism =
for fragmentation between RADIUS packets when they exceed 4K =
(inter-packet fragmentation). If we remove the signal attribute (e.g. =
"More-Data-Pending"), the flag T should mean that the RADIUS packet is =
truncated (and not necessarily the attribute where the flag T is =
activated). For example:=20

A,B,C,... ,Y are attributes of different types in one RADIUS packet. =
Adding attribute Z exceeds 4K, so we should signal that. We could decide =
to activate the bit T in the last attribute Y[T], but, actually, it does =
not mean anything in the context of extended attribute Y[T], since we =
want to signal that more attributes (perhaps, of any other type as, for =
example, Z) are coming after this list in a different RADIUS packet.

In this sense, we believe that the presence of some kind of attribute =
"More-Data-Pending" (or any other type of signaling at packet level) can =
inform about this situation within the context of the RADIUS packet.=20

Best regards.

>=20
> Regards,
>=20
> Dave
>=20
> David B. Nelson
> Sr. Software Architect
> Elbrys Networks, Inc.
> www.elbrys.com
> +1.603.570.2636
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

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

--Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi =
Dave:<div><br><div><div>El 16/01/2012, a las 16:38, Dave Nelson =
escribi=F3:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez =
<span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, =
204, 204); border-left-style: solid; padding-left: 1ex; position: =
static; z-index: auto; ">
<div class=3D"im"><br></div>
We also thought that a new flag "T" could indicate the attribute is =
truncated across several packets.</blockquote><div><br></div><div>Yeah. =
&nbsp;I would favor the definition of another flag bit, rather than =
mixing flags and "signal" attributes to accomplished related purposes. =
&nbsp;It's just more =
symmetrical.&nbsp;</div></div></blockquote><div><br></div><div>Just a =
clarification here. Our goal (authors of =
draft-perez-radext-radius-fragmentation-00.txt) is to enable a mechanism =
for fragmentation between RADIUS packets when they exceed 4K =
(inter-packet fragmentation). If we remove the signal attribute =
(e.g.&nbsp;"More-Data-Pending"), the flag T should mean that the RADIUS =
packet is truncated (and not necessarily the attribute where the flag T =
is activated).&nbsp;For =
example:&nbsp;</div><div><br></div><div>A,B,C,... ,Y are attributes of =
different types in one RADIUS packet. Adding attribute Z exceeds 4K, so =
we should signal that. We could decide to activate the bit T in the last =
attribute Y[T], but, actually, it does not mean anything in the context =
of extended attribute Y[T], since we want to signal that more attributes =
(perhaps, of any other type as, for example, Z) are coming after this =
list in a different RADIUS packet.</div><div><br></div><div>In this =
sense, we believe that the presence of some kind of attribute =
"More-Data-Pending" (or any other type of signaling at packet level) can =
inform about this situation within the context of the RADIUS =
packet.&nbsp;</div><div><br></div><div>Best =
regards.</div><div><br></div><blockquote type=3D"cite"><div =
class=3D"gmail_quote">
</div><br>Regards,<br><br>Dave<br><br>David B. Nelson<br>Sr. Software =
Architect<br>Elbrys Networks, Inc.<br><a href=3D"http://www.elbrys.com/" =
target=3D"_blank">www.elbrys.com</a><br>+1.603.570.2636<br>
_______________________________________________<br>abfab mailing =
list<br><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/=
mailman/listinfo/abfab<br></blockquote></div><br><div =
apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
color: rgb(0, 0, 0); font-family: Courier; font-size: medium; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
auto; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; =
"><div><div>-------------------------------------------------------</div><=
div>Rafael Marin Lopez, PhD</div><div>Dept. Information and =
Communications Engineering (DIIC)</div><div>Faculty of Computer =
Science-University of Murcia</div><div>30100 Murcia - =
Spain</div><div>Telf: +34868888501 Fax: +34868884151 e-mail: <a =
href=3D"mailto:[email-masked]">[email-masked]</a></div><div>----------------------=
---------------------------------</div><div><br></div></div></div><br =
class=3D"Apple-interchange-newline"></div></span><br =
class=3D"Apple-interchange-newline">
</div>
<br></div></body></html>=

--Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F--

From [email-masked]  Mon Jan 16 08:23:17 2012
From: Arran Cudbard-Bell <[email-masked]>
Date: Mon, 16 Jan 2012 17:23:13 +0100
To: DIEGO LOPEZ GARCIA <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [radext] New	Version	Notification	for	draft-perez-radext-radius-fragmentation-00.txt

> In the same spirit of keeping clarity, I'd say that =
Additional-Authorization would be more correct choice, unless adding a =
new Service-Type would somehow complicate adoption...

Agreed.

>=20
>> - the first Access-Accept must contain a State attribute
>> for is already required for use of Authorize-Only
>>=20
>> - additional authorization attributes are received via a series
>> of Access-Request / Access-Challenge
>>=20
>> - each Access-Request MUST contain Service-Type =3D Authorize-Only
>>   and a State
>=20
> Or, respectively, Additional-Authorization, isn't it?

No it's an extension/reworking of the concept described in RFC 3576 3.1, =
but the trigger is an Access-Accept packet with the =
Service-Type/Additional-Authorization attribute.

>=20
>> - the State MUST change for each Access-Challenge response
>>   I can get into that later
>=20
> I can imagine this is with the intention of guaranteeing order and =
avoiding (or alleviating) MITM attacks, right?

Yes, correct. The packets don't contain any explicit ordering =
information, so the attributes are just concatenated together in the =
order they're received.

-Arran=

From [email-masked]  Wed Jan 18 05:33:14 2012
From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Wed, 18 Jan 2012 08:33:00 -0500
Subject: [abfab] [#31] need help with errors for draft-ietf-abfab-gss-eap

Folks, one of the big  stumbling blocks in being done with the core
mechanism spec is handling of errors.

To remind you, the current error token format is as follows;

   The acceptor may always end the exchange by generating an error
   subtoken.  The error subtoken has the following format:

   +--------+----------------------------------------------------------+
   | Pos    | Description                                              |
   +--------+----------------------------------------------------------+
   | 0..3   | 0x80 00 00 01                                            |
   |        |                                                          |
   | 4..7   | length of error token                                    |
   |        |                                                          |
   | 8..11  | major status from RFC 2744 as 32-bit network byte order  |
   |        |                                                          |
   | 12..15 | GSS EAP error code as 32-bit network byte order; see     |
   |        | Section 8.4                                              |
   +--------+----------------------------------------------------------+

   Initiators MUST ignore octets beyond the GSS EAP error code for
   future extensibility.  As indicated, the error token is always marked
   critical.

Here are the error codes we can currently send back.

I'd appreciate comments on whether these are reasonable and on whether
we need more.
error_code GSSEAP_WRONG_SIZE,                   "Buffer is incorrect size"
error_code GSSEAP_WRONG_MECH,                   "Mechanism OID is incorrect"
error_code GSSEAP_BAD_TOK_HEADER,               "Token header is malformed or corrupt"
error_code GSSEAP_TOK_TRUNC,                    "Token is missing data"
error_code GSSEAP_BAD_DIRECTION,                "Packet was replayed in wrong direction"
error_code GSSEAP_WRONG_TOK_ID,                 "Received token ID does not match expected token ID"
error_code GSSEAP_CRIT_ITOK_UNAVAILABLE,        "Critical inner token type unavailable"
error_code GSSEAP_MISSING_REQUIRED_ITOK,        "Missing required inner token"
error_code GSSEAP_DUPLICATE_ITOK,               "Duplicate inner token received"
error_code GSSEAP_WRONG_ITOK,                   "Recieved invalid inner token for current state"
error_code GSSEAP_KEY_UNAVAILABLE,              "EAP key unavailable"
error_code GSSEAP_KEY_TOO_SHORT,                "EAP key too short"
error_code GSSEAP_RADIUS_AUTH_FAILURE,          "Authentication rejected by RADIUS server"
error_code GSSEAP_UNKNOWN_RADIUS_CODE,          "Received unknown response code from RADIUS server"
error_code GSSEAP_MISSING_EAP_REQUEST,          "RADIUS response is missing EAP request"
error_code GSSEAP_RADIUS_PROT_FAILURE,          "Generic RADIUS failure"

From [email-masked]  Fri Jan 20 02:01:52 2012
From: Klaas Wierenga <[email-masked]>
Date: Fri, 20 Jan 2012 11:01:46 +0100
To: [email-masked]
Cc: [email-masked]
Subject: [abfab] call for agenda items abfab@ietf83

Hi,

We have requested a 1,5 hour slot for IETF83 and at this time would like =
to solicit presentations. If you want to present can you please let us =
know?

Cheers,

Klaas & Leif=

From [email-masked]  Wed Jan 25 10:50:14 2012
From: Sam Hartman <[email-masked]>
To: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 25 Jan 2012 13:50:11 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Fwd: [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted

>>>>> "Alejandro" == Alejandro Perez Mendez <[email-masked]> writes:

    >>> * Added motivation section indicating why this is required.
    >> This is a definitely a good addition; however, I don't believe
    >> that it is complete. Ideally I think it needs to consider the
    >> questions that I raised previously in the context of the previous
    >> discussion that Sam initiated about generic gss pre-auth versus
    >> gss-eap pre-auth:
    >> 
    >>> What are the practical benefits of a generic gss pre-auth
    >>> mechanism when Kerberos pre-auth itself provides an extensible
    >>> framework? I can see that there is value in the re-using
    >>> deployed gss mechanisms if this avoids having to create
    >>> functionally-equivalent but redundant pre-auth mechanisms in the
    >>> case where an equivalent gss mechanism already exists, but are
    >>> there really so many of these that this is a compelling
    >>> argument? It sounds as though there is potentially a trade-off
    >>> that we could make between complexity and generality.
    >> 
    >> FWIW I haven't developed an opinion on these yet, but I would be
    >> interested to hear if you have any...

    Alejandro> since the principal final purpose of this draft (in
    Alejandro> conjunction with the other one submitted to the ABFAB WG)
    Alejandro> is to enable the KDC to authenticate users based on the
    Alejandro> GSS-EAP mechanism, I don't see any advantage in
    Alejandro> transporting GSS tokens on top of FAST. It adds an
    Alejandro> additional an unnecessary layer, since nor GSS-API nor
    Alejandro> EAP assume any kind of secure transport.

Josh and I are not asking about FAST.
We're asking about whether GSS-API is the right layer for this.

To me this is the big open question in whether I personally thing this
draft should be advanced and any discussion you can provide of the
issues I brought up buth in general and with regard to the use case of a
service wanting to obtain a service ticket regardless of client support
would be valuable in making my own determination about this draft.

--Sam

From [email-masked]  Wed Jan 25 23:31:21 2012
Date: Thu, 26 Jan 2012 08:31:15 +0100
From: Alejandro Perez Mendez <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Fwd: [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted

El 25/01/12 19:50, Sam Hartman escribió:
>>>>>> "Alejandro" == Alejandro Perez Mendez<[email-masked]>  writes:
>      >>>  * Added motivation section indicating why this is required.
>      >>  This is a definitely a good addition; however, I don't believe
>      >>  that it is complete. Ideally I think it needs to consider the
>      >>  questions that I raised previously in the context of the previous
>      >>  discussion that Sam initiated about generic gss pre-auth versus
>      >>  gss-eap pre-auth:
>      >>
>      >>>  What are the practical benefits of a generic gss pre-auth
>      >>>  mechanism when Kerberos pre-auth itself provides an extensible
>      >>>  framework? I can see that there is value in the re-using
>      >>>  deployed gss mechanisms if this avoids having to create
>      >>>  functionally-equivalent but redundant pre-auth mechanisms in the
>      >>>  case where an equivalent gss mechanism already exists, but are
>      >>>  there really so many of these that this is a compelling
>      >>>  argument? It sounds as though there is potentially a trade-off
>      >>>  that we could make between complexity and generality.
>      >>
>      >>  FWIW I haven't developed an opinion on these yet, but I would be
>      >>  interested to hear if you have any...
>
>
>      Alejandro>  since the principal final purpose of this draft (in
>      Alejandro>  conjunction with the other one submitted to the ABFAB WG)
>      Alejandro>  is to enable the KDC to authenticate users based on the
>      Alejandro>  GSS-EAP mechanism, I don't see any advantage in
>      Alejandro>  transporting GSS tokens on top of FAST. It adds an
>      Alejandro>  additional an unnecessary layer, since nor GSS-API nor
>      Alejandro>  EAP assume any kind of secure transport.
>
> Josh and I are not asking about FAST.
> We're asking about whether GSS-API is the right layer for this.
>
> To me this is the big open question in whether I personally thing this
> draft should be advanced and any discussion you can provide of the
> issues I brought up buth in general and with regard to the use case of a
> service wanting to obtain a service ticket regardless of client support
> would be valuable in making my own determination about this draft.

Hi Sam,

I don't see why the applicability of this proposal to a very specific 
use case should influence on its adoption.
The draft proposes a pre-authentication mechanism based on GSS-API. It 
may be useful for many use cases other than the one you proposed. 
Specifically, it is required for the use case proposed in 
draft-perez-abfab-eap-gss-preauth.

If it does not correctly address the requirements of the use case you 
have in mind, I can agree it may not be the most adequate selection for 
that specific use case. But as I see it, it does not directly convert it 
into unusable, as other use cases can still be satisfied using it.

Best regards,
Alejandro

>
> --Sam

From [email-masked]  Thu Jan 26 04:14:25 2012
From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 26 Jan 2012 13:14:22 +0100
To: Sam Hartman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] [Ietf-krb-wg] FYI: New version of draft-perez-krb-wg-gss-preauth submitted

Hi Sam:

Besides Alex's comments, I believe I had provided some clarifications to =
these questions in:

http://www.ietf.org/mail-archive/web/abfab/current/msg01098.html

Since there was no answer back, I thought it was clarified. Otherwise, I =
would suggest to read it to see if there is agreement on the comments.

Having said that, we already sketched/discussed =
(http://www.ietf.org/mail-archive/web/abfab/current/msg00040.html)=20
an EAP pre-authentication over KRB solution without using GSS-API, with =
the same goal: to define a flexible pre-authentication mechanism for =
Kerberos.
If the WG considers more interesting to re-take this line of work =
providing an EAP pre-authentication in Kerberos, we can collaborate in =
defining it.

Regarding your use case, our intention has not been to define any =
transport for EAP in the backend. Again, if the WG believes
this should be considered as well (I hope we all agree that they are =
completely different goals), then people interested on it (maybe Josh =
and you)
may contribute in defining it.=20

Best regards. =20

El 25/01/2012, a las 19:50, Sam Hartman escribi=F3:

>>>>>> "Alejandro" =3D=3D Alejandro Perez Mendez <[email-masked]> writes:
>=20
>>>> * Added motivation section indicating why this is required.
>>> This is a definitely a good addition; however, I don't believe
>>> that it is complete. Ideally I think it needs to consider the
>>> questions that I raised previously in the context of the previous
>>> discussion that Sam initiated about generic gss pre-auth versus
>>> gss-eap pre-auth:
>>>=20
>>>> What are the practical benefits of a generic gss pre-auth
>>>> mechanism when Kerberos pre-auth itself provides an extensible
>>>> framework? I can see that there is value in the re-using
>>>> deployed gss mechanisms if this avoids having to create
>>>> functionally-equivalent but redundant pre-auth mechanisms in the
>>>> case where an equivalent gss mechanism already exists, but are
>>>> there really so many of these that this is a compelling
>>>> argument? It sounds as though there is potentially a trade-off
>>>> that we could make between complexity and generality.
>>>=20
>>> FWIW I haven't developed an opinion on these yet, but I would be
>>> interested to hear if you have any...
>=20
>=20
>    Alejandro> since the principal final purpose of this draft (in
>    Alejandro> conjunction with the other one submitted to the ABFAB =
WG)
>    Alejandro> is to enable the KDC to authenticate users based on the
>    Alejandro> GSS-EAP mechanism, I don't see any advantage in
>    Alejandro> transporting GSS tokens on top of FAST. It adds an
>    Alejandro> additional an unnecessary layer, since nor GSS-API nor
>    Alejandro> EAP assume any kind of secure transport.
>=20
> Josh and I are not asking about FAST.
> We're asking about whether GSS-API is the right layer for this.
>=20
> To me this is the big open question in whether I personally thing this
> draft should be advanced and any discussion you can provide of the
> issues I brought up buth in general and with regard to the use case of =
a
> service wanting to obtain a service ticket regardless of client =
support
> would be valuable in making my own determination about this draft.
>=20
> --Sam
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

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