Subject: [IPsec] PAD and IKEv2

From: Joy Latten <[email-masked]>
Date: Tue, 09 Oct 2007 14:28:37 -0500

RFC 4301 specifies a Peer Authentication Database.
In section 4.4.3.4, it even talks about how IKE
is to use the PAD.

I see no reference to PAD in RFC 4306 - IKEv2.

Is PAD mandatory for 4301 and 4306 conformance?

Joy

_______________________________________________
IPsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Dan McDonald <[email-masked]>
Date: Tue, 9 Oct 2007 16:03:26 -0400

> RFC 4301 specifies a Peer Authentication Database.

s/Authentication/Authorization/

>From my readings, I get the impression that PAD is an IPsec policy (SPD) -->
Key Management Policy (configuration + basic acceptance tests) mapping.  For
example, if you look in ike.config(4) on Solaris or OpenSolaris with the
OpenSolaris binary extras, that's a sort of PAD (though not as well mapped as
4301 says).  Our ike.config answers questions like, "Which type of IKE
authentication should I use or accept?" and, "Do I accept any IKE from
addresses in prefix <foo>/N?"  A more 4301-like PAD would also answer
questions like, "Is this IKE request from x.y.z.N authenticated with a
certificate that's qualified to speak for x.y.z.N?"

Dan

---

From: ns srinivasa murthy <[email-masked]>
Date: Wed, 10 Oct 2007 10:58:31 +0530

PAD is not mandatory as per the following paragraph from RFC4301

"4.4.  Major IPsec Databases

Many of the details associated with processing IP traffic in an IPsec
    implementation are largely a local matter, not subject to
    standardization.  However, some external aspects of the processing
    must be standardized to ensure interoperability and to provide a
    minimum management capability that is essential for productive use of
    IPsec.  This section describes a general model for processing IP
    traffic relative to IPsec functionality, in support of these
    interoperability and functionality goals.  The model described below
    is nominal; implementations need not match details of this model as
    presented, but the external behavior of implementations MUST
    correspond to the externally observable characteristics of this model
    in order to be compliant.

-nsmurthy

>certificate that's qualified to speak for x.y.z.N?"

********************************************************************************
This email message (including any attachments) is for the sole use of the intended recipient(s) 
and may contain confidential, proprietary and privileged information. Any unauthorized review, 
use, disclosure or distribution is prohibited. If you are not the intended recipient, 
please immediately notify the sender by reply email and destroy all copies of the original message. 
Thank you.
 
Intoto Inc.

---

From: <[email-masked]>
Date: Wed, 10 Oct 2007 09:15:23 +0200

As I understand it, somewhere the local node should store which
IKE peers it may talk to.  Each IKE session negotiates CHILD SAs.
The local node can negotiate only CHILD SAs / traffic selectors
found in its SPD.  The PAD is a table to relate which 
traffic selectors can be negotiated by which IKE peers.  In
case all IKE peers are allowed to negotiate all traffic selectors,
there is no need for the PAD.
 
Christian

________________________________

Fra: ns srinivasa murthy [mailto:[email-masked]]
Sendt: on 10-10-2007 07:28
Til: Dan McDonald; Joy Latten
Cc: [email-masked]
Emne: Re: [IPsec] PAD and IKEv2

Many of the details associated with processing IP traffic in an IPsec
   implementation are largely a local matter, not subject to
   standardization.  However, some external aspects of the
processing
   must be standardized to ensure interoperability and to
provide a
   minimum management capability that is essential for
productive use of
   IPsec.  This section describes a general model for
processing IP
   traffic relative to IPsec functionality, in support of
these
   interoperability and functionality goals.  The model
described below
   is nominal; implementations need not match details of this
model as
   presented, but the external behavior of implementations
MUST
   correspond to the externally observable characteristics of
this model
   in order to be compliant.

-nsmurthy

	

	
	Dan

---

From: <[email-masked]>
Date: Wed, 10 Oct 2007 10:40:07 +0300

Traffic selector authorization is not the only piece of information
stored in PAD.

My understanding is that the RFC 4301 PAD is a purely logical
(documentation) concept, not an implementation concept.  In 
other words, a real implementation does not necessarily have a 
data structure called PAD, but it does have some information 
that enables IKEv2 to work (e.g. how to authenticate peers, 
what SAs different peers can create, etc.) and RFC 4301 calls 
this information "PAD". Existing implementations might call
it "isakmpd.conf" or something like that...

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked]
> Sent: 10 October, 2007 10:15
> To: [email-masked]
> Cc: [email-masked]
> Subject: SV: [IPsec] PAD and IKEv2
>

---

From: Karen Seo <[email-masked]>
Date: Wed, 10 Oct 2007 12:13:12 -0400

I think we're in agreement, but just to be sure ... the PAD defines 
which peers are authorized to communicate with the IPsec entity in 
question, how to authenticate each peer, and which entities each peer 
is authorized to represent (for child SA creation). If all peers were 
allowed to communicate with the IPsec entity and any peer could 
represent any entity (ID), then yes, I suppose one would not need a 
PAD for these functions.  4.5.3 mentions that the PAD could be the 
place where one stores information about locating security gateways, 
in which case, one would need a PAD.

Karen

---

From: Joy Latten <[email-masked]>
Date: Wed, 10 Oct 2007 13:32:31 -0500

> in which case, one would need a PAD.

Yes, that makes sense to me. I was under the impression that the
PAD was an actual database or data structure such as the SPD.
Thanks for the clarification.

Regards,
Joy

---

From: <[email-masked]>
Date: Wed, 10 Oct 2007 21:31:07 +0200

The PAD gives a mapping/relation/binding between
certain pieces of information.  It's a local matter
how this mapping/relation/binding is realized.  I'm
aware of at least one implementation, where the PAD
is implemented as a table/database.
 
Christian

Fra: Joy Latten [mailto:[email-masked]]
Sendt: on 10-10-2007 20:32
Til: Karen Seo
Cc: Kaas-Petersen Christian; [email-masked]
Emne: Re: SV: [IPsec] PAD and IKEv2

Regards,
Joy

---

From: Sean Shuo Shen <[email-masked]>
Date: Fri, 12 Oct 2007 10:28:30 +0800

Thanks a lot, Chris and all,
These talks are also very helpful to me. Chris, can you point me to the
implementation with real PAD files so that I can take a lot?

Sean 

-----邮件原件-----
发件人: [email-masked]
[mailto:[email-masked]] 
发送时间: 2007年10月11日 3:31
收件人: [email-masked]
主题: SV: [IPsec] PAD and IKEv2

Christian

Regards,
Joy

---

From: <[email-masked]>
Date: Fri, 12 Oct 2007 08:47:56 +0200

As consultant I see things for which I cannot disclose the details,
only disclose some high-level abstractions.

Christian 

> From: Sean Shuo Shen [mailto:[email-masked]] 
> Sent: 12. oktober 2007 04:29
> To: [email-masked]
> Subject: 答复: [IPsec] PAD and IKEv2
>

---

From: Joy Latten <[email-masked]>
Date: Fri, 12 Oct 2007 09:19:11 -0500

> is implemented as a table/database.
I am curious to know if this was implemented in userspace
or kernel?

Joy

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Oct 2007 10:52:04 -0500

> I am curious to know if this was implemented in userspace

That depends on where you implement IKE.  Typically IKE is implemented
in user-space, so that's where the PAD (or local equivalent) would be
used.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 19 Oct 2007 17:41:18 -0400

>Is PAD mandatory for 4301 and 4306 conformance?

PAD functionality is required for 4301 conformance.  The PAD format is nominal.

Steve