Re: [KAML] latest status

"Henry B. Hotz" <hotz@jpl.nasa.gov> Fri, 18 September 2009 18:40 UTC

Return-Path: <hotz@jpl.nasa.gov>
X-Original-To: kaml@core3.amsl.com
Delivered-To: kaml@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 686163A6864 for <kaml@core3.amsl.com>; Fri, 18 Sep 2009 11:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.421
X-Spam-Level:
X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=1.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdpKLhx5pcxH for <kaml@core3.amsl.com>; Fri, 18 Sep 2009 11:40:13 -0700 (PDT)
Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id 1F9053A67E3 for <kaml@ietf.org>; Fri, 18 Sep 2009 11:40:13 -0700 (PDT)
Received: from mprox1.jpl.nasa.gov (mprox1.jpl.nasa.gov [137.78.160.140]) by mail.jpl.nasa.gov (Switch-3.4.1/Switch-3.3.2mp) with ESMTP id n8IIf26o011362; Fri, 18 Sep 2009 18:41:06 GMT
Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) by mprox1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id n8IIf0RO008836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Sep 2009 11:41:00 -0700
Message-Id: <0AC447C8-C281-4432-BC43-93FD295B8FDC@jpl.nasa.gov>
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
To: James Ryan <james@litmuslogic.com>
In-Reply-To: <46fc8a10909180713x3116deb5l2cfade36f6b85a2e@mail.gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 18 Sep 2009 11:41:00 -0700
References: <46fc8a10909180713x3116deb5l2cfade36f6b85a2e@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44]
X-Source-Sender: hotz@jpl.nasa.gov
X-AUTH: Authorized
Cc: kaml@ietf.org
Subject: Re: [KAML] latest status
X-BeenThere: kaml@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussions about SAML and Kerberos intersections <kaml.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kaml>, <mailto:kaml-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kaml>
List-Post: <mailto:kaml@ietf.org>
List-Help: <mailto:kaml-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kaml>, <mailto:kaml-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2009 18:40:14 -0000

On Sep 18, 2009, at 7:13 AM, James Ryan wrote:

> I have been unplugged on this topic for a few years.  Could someone  
> give the latest status?
>
> thanks!!


The short answer is that we failed to reach consensus and petered  
out.  Of course that doesn't mean the issues have gone away.  I'm not  
sure I recall all the solutions people were proposing any more.  There  
were some reasonable attempts at summaries near the end of what  
exchanges did happen on-list.

The concept that defined the name of this list was to include a SAML  
token in a ticket.  I personally opposed that because I thought it  
undesirable to mix ASN.1 and XML in the same thing.  (It's possible my  
objections are Quixotic.)

Many (most) of us wanted a way to pass on information from or about  
the original cert used in a PKINIT exchange.  Probably the simplest  
proposal of that type was Doug Engert's that the cert itself just be  
included, but people apparently felt that was excessive, and/or  
excessively distant from the information desired.

My own desire was for a way to label a ticket according to the US  
Government level of assurance that was used to acquire it.  A standard  
mechanism ought to be more general than a US standard of course.   
Unfortunately, that created unwanted complexities in defining what  
ought to be in the ticket, if it wasn't necessarily a US LOA.

The Microsoft PAC was not considered a good basis for a solution, but  
everyone wanted to remain compatible with it if it was present.

Off-list I have second- or third-hand information (unreliable  
information in other words) that NASA asked Microsoft to include the  
US LOA in the PAC as a dynamic group membership, and they agreed.  I  
also have possibly-contradictory information that Microsoft told NASA  
to work through the IETF and the Kerberos Consortium to define how the  
LOA information should be handled and they would conform to and  
implement whatever was agreed on.

Absent a better consensus, I proposed that we create a framework  
document covering how multiple representations of authorization data  
should coexist and their degree of consistency.  There did not seem to  
be any interest.

I think there is interest in solving the authorization problem in a  
way that scales better than the MS PAC.  There's interest on  
Microsoft's part as well.  Nobody's come up with a solution that  
enough people find attractive though.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu