Re: [KAML] LoA proposal

"Henry B. Hotz" <hotz@jpl.nasa.gov> Wed, 19 September 2007 19:04 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 1IY4r3-0002zh-1h; Wed, 19 Sep 2007 15:04:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY4r1-0002zX-BI for kaml@ietf.org; Wed, 19 Sep 2007 15:04:55 -0400
Received: from nmta1.jpl.nasa.gov ([137.78.160.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY4qv-0002tR-Pu for kaml@ietf.org; Wed, 19 Sep 2007 15:04:55 -0400
Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l8JJ4LOG028941; Wed, 19 Sep 2007 12:04:22 -0700
Received: from [137.78.61.96] (laphotz.jpl.nasa.gov [137.78.61.96]) by xmta1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id l8JJ4IfT018340; Wed, 19 Sep 2007 12:04:20 -0700
In-Reply-To: <0E2D64FCAEB5C5458A494DC28270548E06DA08E5@Netmail1.exostar.com>
References: <0E2D64FCAEB5C5458A494DC28270548E06DA08E5@Netmail1.exostar.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed
Message-Id: <72C8E441-0D92-45A6-ABBB-C113130D9125@jpl.nasa.gov>
Content-Transfer-Encoding: quoted-printable
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Subject: Re: [KAML] LoA proposal
Date: Wed, 19 Sep 2007 12:04:08 -0700
To: Paul Rabinovich <Paul.Rabinovich@exostar.com>
X-Mailer: Apple Mail (2.752.3)
X-Source-IP: laphotz.jpl.nasa.gov [137.78.61.96]
X-Source-Sender: hotz@jpl.nasa.gov
X-AUTH: Authorized
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: kaml@ietf.org
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

Not sure there isn't a bit of scope creep in the proposal.  Seems to  
me the scope is providing authorization information based on how the  
original authentication was done, not to define new authentication  
mechanisms per-se.  We need to be careful what we say about OTP and  
SAML authentication in the absence of approved RFC's or other standards.

I think we can "agree to disagree" on what what kind of authorization  
information is needed/appropriate based on prior discussion.  Let me  
suggest a different organization;  we should define two kinds of  
information:

1) RAW information, which provides details about how the original  
authentication was done.

2) EVALUATED information, which provides a policy judgement about the  
quality/strength/implications of the authentication method.

Examples of RAW information would be the kind of OTP token used, or  
the cert (and/or cert path) for a PKINIT authentication.  If a SAML  
token caused the ticket to be issued then that SAML token might be  
included.

Examples of EVALUATED information would be a SAML token asserting the  
SP800-63 LoA of the authentication, or the PAC data defined by  
Microsoft.  DCE authorization info probably also qualifies (just to  
keep an ASN1-encoded type in the mix).

All of the above are optional, based on local policy requirements.   
Any/all of the above examples MUST be includable without conflict.   
Not that it would have been a problem, but the above clearly  
distinguishes whether a SAML token generated the authentication, or  
the authentication generated the SAML token, and both SAML tokens  
might be included.

I'd propose that the EVALUATED information gets included/excluded  
based on the same mechanism used by Microsoft to include/exclude the  
PAC.  I'd propose the RAW data is excluded by default, but included  
if requested by some other mechanism.

On Sep 19, 2007, at 7:55 AM, Paul Rabinovich wrote:

>
> 	Hello,
>
> 	In the attached document I attempted to summarize LoA-related  
> traffic in this and krb lists and to sketch a proposal. From Sam's  
> e-mail it looks like we need to produce an I-D by Oct 1. I'll start  
> right away on putting the proposal in the attached document into  
> the I-D format, and will send it out in the next couple of days.

----

> 11. The “simple” profile will support forwarding of authentication  
> info defined as a CHOICE:
>
> -       User ID/password: an ENUM or OCTET STRING saying “user ID/ 
> password”.
> -       X.509 certification path: an ENUM or OCTET STRING saying “X. 
> 509 path” plus a SEQUENCE/SET of certificates.
> -       X.509 end-entity certificate only: an ENUM or OCTET STRING  
> saying “X.509 single cert” plus the certificate.I'd vote for an  
> ENUM on space efficiency grounds.

I'd vote for ENUM on space efficiency grounds.
> -       OTP: an ENUM or OCTET STRING saying “OTP” (QUESTION: are  
> there any important flavors/subdivisions?)
Take a look at section 5.1.1 of draft-ietf-krb-wg-kerberos-sam-03.txt.
> -       QUESTION: Is multifactor authentication of interest?
Absolutely.  If nothing else the use of multifactor authentication is  
needed for the higher levels in SP800-63, so it's already implied.   
Do we need to explicitly define a way to carry the number of factors  
used in the original authentication?  I don't think so, but I may be  
wrong.
------------------------------------------------------------------------
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



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