[KAML] Chicago bar-BOF summary

Leif Johansson <leifj@it.su.se> Wed, 22 August 2007 20:10 UTC

Return-path: <kaml-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INwWt-0001Fq-So; Wed, 22 Aug 2007 16:10:15 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INwWs-0001Fl-N2 for kaml@ietf.org; Wed, 22 Aug 2007 16:10:14 -0400
Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INwWr-00015X-Os for kaml@ietf.org; Wed, 22 Aug 2007 16:10:14 -0400
Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 786CD3BFC3 for <kaml@ietf.org>; Wed, 22 Aug 2007 22:10:12 +0200 (CEST)
Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15390-03-47 for <kaml@ietf.org>; Wed, 22 Aug 2007 22:10:12 +0200 (CEST)
Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 05D5F3BF47 for <kaml@ietf.org>; Wed, 22 Aug 2007 22:10:11 +0200 (CEST)
Message-ID: <46CC9837.5090305@it.su.se>
Date: Wed, 22 Aug 2007 22:10:31 +0200
From: Leif Johansson <leifj@it.su.se>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: kaml@ietf.org
X-Enigmail-Version: 0.94.2.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-2.268 tagged_above=-99 required=7 tests=[AWL=0.044, BAYES_00=-2.312]
X-Spam-Level:
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Subject: [KAML] Chicago bar-BOF summary
X-BeenThere: kaml@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about SAML and Kerberos intersections <kaml.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/kaml>, <mailto:kaml-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/kaml>
List-Post: <mailto:kaml@ietf.org>
List-Help: <mailto:kaml-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/kaml>, <mailto:kaml-request@ietf.org?subject=subscribe>
Errors-To: kaml-bounces@ietf.org

Hello and welcome to the kaml list. This list is the result of a bar-BOF
at the last IETF meeting in Chicago were a few SAMListas and well-
known members of the kerberos wg met and tried to come up with a
list of use-cases which might involve both SAML and kerberos.

Let me first say that we are clearly talking about several rather
loosely connected use-cases. This is probably not a complete
list of things we discussed in Chicago and I hope everyone will
contribute stuff of their own.

The use-cases:

1. Was a smart-card used?

This is my interpretation of problems posed by Douglas Engert
of ANL and Henry Hotz of Nasa.

The problem is to determine exactly how authentication was done
at a relying party, for instance if pkinit with a smart-card was used.
In general the RP may be at the end of a chain of (say) clients using
a gssapi-based protocol with credentials delegation, for instance a
SOAP-based service  sitting behind a web-application, both using
NTLM/Negotiate for authentication. In this case the RP has no way
to make decisions about how the initial authentication was done.

In SAML parlance this may be framed both in terms of the concept
of Level of Assurance and the SAML Authentication Context.

It seems clear that any analysis of this use-case would need to span
both Kerberos and GSS-API. In kitten there has been discussion
about how to represent authz-data. This would clearly be related.

2. The standarized PAC

An AD domain controller includes data about the groups a user is
a member of in the PA-DATA field of the KDC-REP. A generalization
of this concept might be to include a SAML authentication response
in the PA-DATA. This could be used together with anonymous
kerberos to control which identity information is made available
to the RP.

3. WebSSO kerberos n-tier.

A web-application using the SAML Web SSO profile needs a kerberos
ticket for accessing kerberized backend services. This kerberos ticket
needs to be produced by the Identity Provider and made available to
the Relying Party (or Service Provider).

Hope this is enough to get things started. I know the smart-card use-
case was discussed on the heimdal list (although possibly not in the
generality I presented above). Other use-cases have been discussed
on other lists.

       Cheers Leif

_______________________________________________
KAML mailing list
KAML@ietf.org
https://www1.ietf.org/mailman/listinfo/kaml